Subject: [MMUSIC] ICE updated offer summary

From: Ari Keränen <[email-masked]>
Date: Thu, 23 Oct 2014 21:23:08 +0000

All,

To make sure we're on the same page, here's my summary on the ICE updated offer discussion from and since the Toronto meeting, listing arguments for and against doing the updated offer. Please chime in if there are major errors or some relevant point is missing.

There are also couple of open questions (see below) for which more input would be good.

Cheers,
Ari

For doing updated offer
-----------------------

* SDP aware intermediaries may need to enforce policies and/or perform configuration for the media path (latching, SDN, etc.):
https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM
https://mailarchive.ietf.org/arch/msg/mmusic/IdZykrtyeTBfIt0Hac3uN5nn5DA
https://mailarchive.ietf.org/arch/msg/mmusic/nKPIit139XRwOhC6yl-WhcChYLU
https://mailarchive.ietf.org/arch/msg/mmusic/mYbRdoeBN35ESVEeZaCCWnYpa_Q
and [1]

 - Information from SDP ICE candidates and STUN messages is not sufficient (can't be sure which candidate was selected e.g., with aggressive nomination) 

* Could also help with releasing TURN candidates without need to wait for timeout [1]

* Helps with error case debugging and diagnostics [1]

* OK if answerer can communicate need for updated offer
https://mailarchive.ietf.org/arch/msg/mmusic/LswG6GJykmTZ5PzBvcMjPrl9sdM

* With WebRTC, updated offer could be done with the JS application (no need for API changes)
 - However, is selected candidate information available for JS apps?
 https://mailarchive.ietf.org/arch/msg/mmusic/_3DO5QkBbWgMIV_2uJE9wvhxC1M)

For not doing updated offer
---------------------------

* Some 3PCC scenarios break with updated offer:
https://mailarchive.ietf.org/arch/msg/mmusic/mMyN9hzyrGOqIVdCpp1N1OllNSg
http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#section-3.1

* Not needed in scenarios without SDP aware intermediaries 

* Complicates call flows and implementations [1]

* Currently updated offer is not implemented for Chrome and Firefox; not clear if needed in practice [1]

* Could we do instead offerless INVITE where updated offer is needed? Is PRACK nowadays supported?
https://mailarchive.ietf.org/arch/msg/mmusic/lORWBcHNqXPlZqdvE2SDbVdAwc4
https://mailarchive.ietf.org/arch/msg/mmusic/s95L-4VagjrTluojSQyFBkM6Zn0

[1] http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 29 Oct 2014 13:57:50 +0000

Ari,

just to elaborate a bit further the pros/cons ... inline

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Ari Keränen
> Sent: Donnerstag, 23. Oktober 2014 23:23
> To: [email-masked]
> Subject: [MMUSIC] ICE updated offer summary
> 
> All,
> 
> To make sure we're on the same page, here's my summary on the ICE updated
> offer discussion from and since the Toronto meeting, listing arguments for and
> against doing the updated offer. Please chime in if there are major errors or
> some relevant point is missing.
> 
> * SDP aware intermediaries may need to enforce policies and/or perform
> configuration for the media path (latching, SDN, etc.):
>  - Information from SDP ICE candidates and STUN messages is not sufficient
> (can't be sure which candidate was selected e.g., with aggressive nomination)
> 

* The above draft also provides some details on another issue with the ICE updated offer.
Fax calls tend to start an offer/answer renegotiation once fax tones are detected at the called side in order to renegotiate for a suitable codec/transport. 
This renegotiation might collide with the ICE updated offer and lead to delay.

* There is yet another issue with call distribution systems, e.g. call centers, key-sets, pick-up groups, using B2BUAs together with SRTP.
Considering that SDP Security Description is used, the offerer's key material is likely to be distributed to various callees.
In order to ensure privacy of the eventually established dialog, the involved B2BUA would use an offerless INVITE to trigger another offer/answer exchange with unique keying material. Again this SDP offer/answer exchange is likely to collide with the ICE updated offer.

Regards
Thomas

> * Could we do instead offerless INVITE where updated offer is needed? 

> Is PRACK nowadays supported?
You can still not assume that PRACK is supported universally. 
Because of this, Trickle ICE again needed some technique that 

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Oct 2014 19:28:50 +0000

Hi,

There are standardized procedures on how to deal with offer collisions - and you have to implement those procedures no matter what.

In addition, there are mechanisms for delaying the alterting of the remote endpoint (e.g. your fax machine) before certain preconditions have been met - and in certain network scenarios you may have to implement those anyway.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Stach, Thomas
Sent: 29 October 2014 15:58
To: Ari Keränen; [email-masked]
Subject: Re: [MMUSIC] ICE updated offer summary

Ari,

> To make sure we're on the same page, here's my summary on the ICE 
> updated offer discussion from and since the Toronto meeting, listing 
> arguments for and against doing the updated offer. Please chime in if 
> there are major errors or some relevant point is missing.
> 
>  - Information from SDP ICE candidates and STUN messages is not 
> sufficient (can't be sure which candidate was selected e.g., with 
> aggressive nomination)
> 
> http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-02#se
> ction-
> 3.1

Regards
Thomas