Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE usage

[Paul Kyzivat <[e-mail]>]

Trimming, and changing subject

On 8/12/11 11:20 AM, Harald Alvestrand wrote:
> On 08/12/11 16:55, Paul Kyzivat wrote:
>> On 8/12/11 2:45 AM, Harald Alvestrand wrote:
>>> On 08/11/11 20:47, Paul Kyzivat wrote:
>>>> On 8/11/11 7:32 AM, Harald Alvestrand wrote:
>>>>> I have taken some of the information I learned from the discussions in
>>>>> Quebec City about the issues of putting video and audio into the same
>>>>> RTP session and created a draft from them outlining a solution to the
>>>>> problem of signalling this configuration using SDP.
>>>>>
>>>>> Comments welcome, including the recommended context for processing the
>>>>> document; in a few days I'll send the same note to AVTCORE and/or
>>>>> MMUSIC.
>>>>
>>>> Harald,
>>>>
>>>> A few questions/comments:
>>>>
>>>> 1) If ICE is being used, how do you expect it to be handled on the 2nd
>>>> m-line? Since one of the goals of multiplexing on a single rtp session
>>>> is to minimize ICE processing, one would hope only to do ICE on the
>>>> first of the grouped m-lines. But if the answerer doesn't support this
>>>> grouping, then the ICE will be needed on the others.
>>> I tried to be explicit that if negotiation is successful, only the ICE
>>> parameters from the first section listed in the A=group:TOGETHER would
>>> be used:
>>
>> Sure. But if the other side *doesn't* support TOGETHER, then ICE will
>> need to be negotiated independently for each m-line. And for that to
>> work, the port for the 2nd m-line but be active, other ICE candidates
>> identified and included for it, etc.
>>
>> ISTM the implications of that need further explanation.
>> (I'm not an expert on ICE. If I were, maybe this would be obvious.)
> There are 2 possible things to do for the offerer:
> - Start ICE procedure on all ports when sending the offer
> - Wait until the answer comes back, and either start ICE procedure on
> one port (if the responder understood TOGETHER), or start the ICE
> procedure on all ports (if the responder did not understand TOGETHER)
>
> The first alternative is a number of milliseconds faster, but others
> should chime in on whether that's significant or not.

(I don't know much about ICE, so just call me on it if I say something 
stupid)

IIUC, there are some aspects of ICE that MUST be done before sending the 
offer. Specifically that involved gathering the candidate list, which 
may involve assignment of multiple local ports, interactions with a TURN 
server, etc. I don't think everything can be deferred until the answer 
is received.

(I suppose one approach would be for the initial offer to set the port 
to zero in all but the first m-line. Then, once the first answer is 
received, indicating whether TOGETHER is supported, another offer can be 
generated, using appropriate ICE based on whether using TOGETHER or not. 
But that does start to get complex.)

	Thanks,
	Paul