Subject: RE: [Sip] Re: New work: Option-tag for ICE

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Nov 2006 08:12:51 +0000

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 13 November 2006 16:48
> To: Drage, Keith (Keith)
> Cc: IETF SIP List
> Subject: [Sip] Re: New work: Option-tag for ICE
> 
> The semantics for the option tag are the same as for any other option 
> tag - it means that ICE is supported.
> 
> ICE is normally signaled through SDP attributes, and there is no need 
> for an option tag for the "normal" call flows. However, we 
> ran into some 
> issues with offerless INVITEs. In particular, it would be 
> really, really 
> helpful for a UA to construct an offer in a 18x or 2xx based on 
> knowledge of whether the UA that sent the INVITE supports 
> ICE. If they 
> don't, there is no need to gather candidates in constructing 
> an offer in 
> the response.
[JRE] Of course this doesn't help if the offerless INVITE request came from
a B2BUA that does not handle SDP/media. The B2BUA might not know whether the
UA to which the SDP offer will be sent supports ICE or not. So the absence
of Supported: ice would not necessarily be safe grounds for skipping ICE
stuff.

John

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 17 Nov 2006 09:57:40 -0600

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, November 17, 2006 2:13 AM
> To: Jonathan Rosenberg; Drage, Keith (Keith)
> Cc: IETF SIP List
> Subject: RE: [Sip] Re: New work: Option-tag for ICE
> 
>  
> 
> > for an option tag for the "normal" call flows. However, we ran into 
> > some issues with offerless INVITEs. In particular, it would 
> be really, 
> > really helpful for a UA to construct an offer in a 18x or 
> 2xx based on 
> > don't, there is no need to gather candidates in 
> constructing an offer 
> > in the response.
> [JRE] Of course this doesn't help if the offerless INVITE 
> request came from a B2BUA that does not handle SDP/media. The 
> B2BUA might not know whether the UA to which the SDP offer 
> will be sent supports ICE or not. So the absence of 
> Supported: ice would not necessarily be safe grounds for 
> skipping ICE stuff.
> 
> John
> 

You could make the same case for any options tag. For instance, some
B2BUA's strip out the 100rel tag from the supported header because they
want to muck with the early media being generated, and don't want the
hassle of having to deal with PRACK on one side of the call, and not on
the other side.

Just because there's something in the middle that may strip the options
tag doesn't mean that it is of no utility. There's really no reason for
a B2BUA to strip out the ice option tag given all the backoff logic
built into the draft when the other side appears to not support ICE. If
the B2BUA really didn't want ICE to run, it would also be messing with
the SDP crossing through it too. So where's the harm?

Regards,
Brian