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

[Emil Ivov <[e-mail]>]

Hey Paul,

On 25.07.13, 23:46, Paul Kyzivat wrote:
> 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.

The section that deals with this is 9.1

http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#section-9.1

The intention is exactly what you describe above.

> (As long as you specify how to
> select the subset.)

The subset is an "a=candidate" line. I don't think select is the right 
word here though. You just encode an ICE candidate, as you would encode 
it for an SDP offer or answer.

>>>>> 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.

Great!

> The first decision is:

Did you miss something here?

>>> 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!

Agreed!

> Can an INFO trickle ICE candidates for more than one m-line?

Yes.

> 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.

I think the problem with the above is that you are trying to present it 
as an extract from some pre-existing offer or answer, while it isn't.

When you are trickling you find yourself in a situation where you have 
one or more newly learned candidates. You want to send those to the 
remote agent.

To do this you group them by stream (as in "m=" line). For each group 
you start by creating an "a=mid:x" attribute that matches the one from 
the "m=" line that created the stream. You then create and append 
"a=candidate" lines for every candidate in that group.

That's it.

The receiving peer does the opposite: it parses the "a=mid:x" line, it 
finds the stream object that it refers to, then parses all the 
candidates and adds them there.

Does this make sense?

Emil


>
> 	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
>>>>
>>>
>>> .
>>>
>>
>
>

-- 
https://jitsi.org