Subject: Re: [rtcweb] draft-alvestrand-one-rtp ICE usage (and multi-stream interactions)

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Aug 2011 12:26:10 -0700

The ICE offerer needs to be prepared to receive media on the ports indicated in the offer.  After all, it doesn't know whether the answer will indicate support for TOGETHER or not.  As a result, without any a-priori knowledge, it seems to me that normal behavior with respect to gathering candidates and preparing to receive media should apply.  Once an answer is returned that indicates TOGETHER support, then the offerer will know that media won't be received on the ports indicated in the m-lines other than the first.  In general, we'd probably like to conclude the ICE exchange as quickly as possible, so that setting ports to zero in all but the first m-line and then going through another offer-answer exchange is probably non-optimal.    One concern that hasn't been mentioned so far is the interaction of TOGETHER with other multi-stream work now in progress, including CLUE and draft-westerlund-avtcore-multistream-and-simulcast  .  Do we understand how these might interact?   Paul Kyzivat said: 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.)

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Aug 2011 13:54:35 +0200

On 08/25/11 21:26, Bernard Aboba wrote:
> The ICE offerer needs to be prepared to receive media on the ports 
> indicated in the offer.  After all, it doesn't know whether the answer 
> will indicate support for TOGETHER or not.  As a result, without any 
> a-priori knowledge, it seems to me that normal behavior with respect 
> to gathering candidates and preparing to receive media should apply.  
> Once an answer is returned that indicates TOGETHER support, then the 
> offerer will know that media won't be received on the ports indicated 
> in the m-lines other than the first.
>
> In general, we'd probably like to conclude the ICE exchange as quickly 
> as possible, so that setting ports to zero in all but the first 
> m-line and then going through another offer-answer exchange is 
> probably non-optimal.
>
> One concern that hasn't been mentioned so far is the interaction of 
> TOGETHER with other multi-stream work now in progress, including CLUE 
> and draft-westerlund-avtcore-multistream-and-simulcast  .  Do we 
> understand how these might interact?

I do not know, but have sent the draft to both MMUSIC and AVTCORE, 
pointing at MMUSIC (in the absence of other advice) as the place for 
further discussion of the draft.

Magnus has been on vacation for a while, so I don't think he's seen it yet.

>
>
> Paul Kyzivat said:
>
> 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 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb