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

From: "Elwell, John" <[email-masked]>
Date: Sun, 19 Nov 2006 10:04:28 +0000

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: 17 November 2006 18:05
> To: Elwell, John; Jonathan Rosenberg; Drage, Keith (Keith)
> Cc: IETF SIP List
> Subject: RE: [Sip] Re: New work: Option-tag for ICE
> 
> John,
> 
> Ah, I wasn't thinking about 3PCC in my comment. 
> 
> If there's a tag in the registered contact for the UA that 
> the offerless
> INVITE is for though, then the INVITE going out could have the option
> tag in it (as the B2BUA would know something about the UA it's
> initiating 3PCC for).
[JRE] I don't think this is a reasonable assumption. The B2BUA is initiating
a call from A to B, where A is in its domain, say, but B could be anywhere.
It sends an offerless INVITE to A. It is unlikely to know the capabilities
of B.
Yes, I appreciate that it can also happen the opposite way round, in which
case the option tag could work. The point is, there are so many
circumstances in which an offerless INVITE can be used that I don't think it
is reasonable to assume that the absence of Supported: ice means that ICE is
definitely not supported.

> 
> If we allowed the Supported header to be in responses, then you could
> even let the option-tag flow across the B2BUA as part of the 
> 3PCC setup.
> As an aside, why on earth do we not allow the Supported header in a
> response other than 2xx (looking at 3261)?
> 
> Regards,
> Brian
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Friday, November 17, 2006 11:42 AM
> > To: Stucker, Brian (RICH1:AR00); Jonathan Rosenberg; Drage, 
> > Keith (Keith)
> > Cc: IETF SIP List
> > Subject: RE: [Sip] Re: New work: Option-tag for ICE
> > 
> > Brian,
> > 
> > You miss my point. I am not talking about a B2BUA stripping 
> > an option tag from a received INVITE request before 
> > forwarding the request. I am talking about a B2BUA 
> > originating an INVITE request (during a 3PCC make call 
> > situation). In this case the B2BUA has no grounds on which to 
> > include the option tag.
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Brian Stucker [mailto:[email-masked]]
> > > Sent: 17 November 2006 15:58
> > > To: Elwell, John; Jonathan Rosenberg; Drage, Keith (Keith)
> > > Cc: IETF SIP List
> > > Subject: RE: [Sip] Re: New work: Option-tag for ICE
> > > 
> > > 
> > > > -----Original Message-----
> > > > 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
> > > > 
> > > >  
> > > > 
> > > > > -----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
> > > > 
> > > 
> > > 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
> > > 
> > 
> 

_______________________________________________
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: Mon, 20 Nov 2006 11:02:58 -0600

> > If there's a tag in the registered contact for the UA that the 
> > offerless INVITE is for though, then the INVITE going out 
> could have 
> > the option tag in it (as the B2BUA would know something 
> about the UA 
> > it's initiating 3PCC for).
> [JRE] I don't think this is a reasonable assumption. The 
> B2BUA is initiating a call from A to B, where A is in its 
> domain, say, but B could be anywhere.
> It sends an offerless INVITE to A. It is unlikely to know the 
> capabilities of B.
> Yes, I appreciate that it can also happen the opposite way 
> round, in which case the option tag could work. The point is, 
> there are so many circumstances in which an offerless INVITE 
> can be used that I don't think it is reasonable to assume 
> that the absence of Supported: ice means that ICE is 

True. But it would be nice to be able to optimize the 'opposite way
around' though.

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 20 Nov 2006 11:02:58 -0600

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2006 16:52:28 -0500

inline.

> definitely not supported.

This is an excellent point. I think you are correct; since a UA cannot 
differentiate between a first and third party offerless invite, it would 
need to always construct its offer with ICE attributes, regardless of 
the presence of the option tag. In this case, the option tag is 
pointless since its presence has no bearing on the processing the UA 
will execute. It would be nice to be able to differentiate the third vs. 
first party case, but there is nothing for that right now.

The REGISTER case is definitely useful, and there is a not-so-useful but 
possible application with Require in an INVITE.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com