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

[Paul Kyzivat <[e-mail]>]

Emil,

On 7/25/13 6:32 PM, Emil Ivov wrote:
> 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.

Maybe you intended that. But I don't find sufficient words in the doc to 
determine what you mean. The words that seem to pertain to this are:

    Given that such lines do not provide a relationship between the
    candidate and the m line that it relates to, signalling protocols
    using trickle ICE MUST establish that relation themselves.  This can
    be done in one of two ways: using the m-line index, or an MID
    [RFC3388].  The m-line index is a zero-based index, referring to the
    Nth m-line in the SDP.  The MID uses "media stream identification",
    as defined in [RFC3388], to identify the m-line.

So I'm supposed to infer that you are proposing to use a subset of SDP 
from that???

Also, what does "signalling protocols using trickle ICE MUST establish 
that relation themselves" *mean*? Does it mean that you intend the INFO 
message containing the trickle ice info in its body to specify the 
m-line somewhere other than in the same body???

I would expect that the body you send would include something to do 
this. If you use mid, then the syntax to do so already exists, sort of. 
If you use m-line index, then it doesn't.

>> (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?

I forget. It doesn't matter.

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

I thought that is what you had in mind.

But you have said you want to use application/sdpfrag, which means it 
should be viewed as a subset of a full SDP. And that is especially so if 
you intend to reference m-lines in an SDP, but don't want to include 
them. And you haven't defined any new ordering rules for lines other 
than what exist for SDP. And SDP allows the ordering I show above, which 
doesn't work for you.

I'll also mention that I think you need to explicitly reference the SDP 
offer or answer that this trickle updates. Probably by replicating the 
o-line from that SDP.

So there are some significant syntax rules that need to be followed 
here. I would expect something like:

- must start with o-line of the SDP it is updating
- has one or more "media sections"
- each media section begins with an a:mid line, referencing
   a mid defined in the referenced SDP
- each a:mid line is followed by one or more a:candidate lines
...

If going that way, then I think it is better to define a mime type that 
consists of exactly this syntax, with some extensibility hooks.

	Thanks,
	Paul

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