Re: [MMUSIC] draft-ivov-mmusic-trickle-ice-sip-00

[Paul Kyzivat <[e-mail]>]

On 7/25/13 4:42 PM, Emil Ivov wrote:

>>>> On 25.07.13, 19:09, Paul Kyzivat wrote:
>>>>
>>>> Section 4 says that trickled candidates are transported as INFO
>>>> payloads
>>>> containing SDP formatted according to ivov-mmusic-trickle-ice. But
>>>> AFAICT that draft doesn't specify this.
>>>
>>> Well, it just borrows the format from 5245 and says that this is how you
>>> represent trickled candidates.
>>
>> But all of that assumes a full SDP body.
>
> I don't see how the syntax of an "a=candidate" line depends on the full
> SDP body, so I don't see the problem with just pointing there. Again, I
> mean this only about syntax.

My point is that 5245 never suggests that ICE will be represented in SDP 
in anything but a full SDP body.

If you said that you were proposing to send subsets of SDP as described 
in 5245, that would make some sense. (As long as you specify how to 
select the subset.)

>>>> Also the example in this section
>>>> shows an info payload that contains only a subset of SDP, and doesn't
>>>> conform to mime type application/sdp.
>>>
>>> Yup, should be application/sdpfrag.
>>
>> Well, AFAIK there is currently no such mime type. So its necessary to
>> define it.
>
> This is the point of the draft I pasted above:
> http://tools.ietf.org/html/draft-ivov-dispatch-sdpfrag-00
>
> Of course, it does need more work (by the way, help there is more than
> welcome so if you want to join just let me know).

Oh, duh. That slipped right by me. But of course it is incomplete.

I could help, once I understand what it needs to say. The first decision is:

>> And while you could define a generic one, you have some specific
>> requirements about what this needs to contain, so you might want to
>> define application/trickle-ice-sdp with all the requisite rules.
>
> The original idea (which I believe came from Adam) was that this could
> be avoided in a way similar to how application/sipfrag does it. I
> basically specifies syntax (as a SIP subset) and leaves semantics to
> specs that are using it, like for example 3515
>
> Do you see any reason why this couldn't work here?

Its a choice. In the case of sipfrag, IIRC it was defined for use with 
3515. In that it isn't crucial what is in it. So it works there.

In your case what goes in it is more critical. It can still be defined 
this way. But it will take some care to get it right.

The main thing is that it be done somewhere!

Can an INFO trickle ICE candidates for more than one m-line?
If so, it gets messy. Consider a full SDP:

...
m=...
a=mid:1
a=candidate:...
...
m=...
a=candidate:...
a=mid:2
a=candidate:...

(AFAIK the above is entirely legal.)

Now consider a sipfrag for trickle from the above:

a=mid:1
a=candidate:...
a=candidate:...
a=mid:2
a=candidate:...

Now, which candidates go with which m-line? So, I think your sdpfrag 
needs special constraints that don't apply to ICE in full SDP.


	Thanks,
	Paul

> Emil
>
>>>> Section 5.6 again references the trickle-ice draft (section 4) for
>>>> definition of the body of the info message, but that section of that
>>>> draft doesn't contain any such definition.
>>>
>>> Will need to fix.
>>>
>>>> Aside from that, it occurs to me that trickle-ice, and for that matter
>>>> ice in sip even without trickle, is a good candidate for preconditions.
>>>> The use of preconditions could eliminate the need for half trickle.
>>>> This
>>>> would of course require a new precondition type, but that is doable.
>>>
>>> Hmmm ... that's a good point!
>>>
>>>> By using preconditions, you can establish the dialog without alerting
>>>> the callee. Then the alert can be deferred until at least one workable
>>>> path has been detected.
>>>>
>>>> (But I suppose the hate for preconditions is so great that this is not
>>>> to be considered.)
>>>
>>> Well, it doesn't have to be mandatory ...
>>>
>>> Emil
>>>
>>>>
>>>>           Thanks,
>>>>           Paul
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> .
>>
>