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

On 26.07.13, 01:26, Paul Kyzivat wrote:
> 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???

No, you are not. This is the generic trickle ICE draft and it says: when 
using trickle with a specific protocol, make sure you match candidates 
to m= lines through use of MIDs.

It can't say anything more here because XMPP would encode the MID value 
  one way (i.e. using content names attributes), SIP another (using 
a=mid) and WebRTC apps in yet another (likely json).

> Also, what does "signalling protocols using trickle ICE MUST establish
> that relation themselves" *mean*?

I hope the above answers your question.

> 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 don't understand this part. Didn't my previous mail clarify this?

Here's an example:

          INFO sip:alice@example.com SIP/2.0
          ...
          Info-Package: trickle-ice
          Content-type: application/sdp
          Content-Disposition: Info-Package
          Content-length: ...

          a=mid:1
          a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
          a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
          a=mid:2
          a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
          a=end-of-candidates

That's the entire body and there are no m= lines in it.

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

We kind of decided not to use "m=" line index in one of the previous 
meetings so we are only going for MID. The draft hasn't been updated 
since so it still refers to "m=" line index in a few locations but they 
will go.

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

Doesn't this apply to the INFO example that I pasted above? Why could it 
not be viewed as a subset of *some* valid full SDP?

> And that is especially so if
> you intend to reference m-lines in an SDP

No, there's no such intention any more.

> , 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 agree that there's no such definition in the draft. I did provide 
example rules in a couple of paragraphs above though. Do you see a 
problem using this logic as basis for defining the ordering in 
trickle-ice-sip?

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

That's a good point. We do need this for SIP. I'll make sure we add it.

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

Sounds great to me!

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

Are you proposing this because you think this MIME type could be reused 
by someone else?

Personally I don't really mind.

However, if we leave sdpfrag with the current intention (i.e. any SDP 
line or combination of lines work) and then define the specifics in 
trickle-ice-sip, then we have a MIME type for the a=candidate lines that 
come out of WebRTC browsers, should anyone every need this.

Cheers,
Emil

>
> 	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
>>>>>>> mmusic@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>>>
>>>
>>
>
>

-- 
https://jitsi.org