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

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

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: Fri, 17 Nov 2006 12:05:20 -0600

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).

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

> Sent: Friday, November 17, 2006 11:42 AM
> To: Stucker, Brian (RICH1:AR00); Jonathan Rosenberg; Drage, 
> Keith (Keith)
> Cc: IETF SIP List
> 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 
> 
> > > [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
> > > 
> > 
> > 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
> > 
>

---

From: [email-masked]
Date: Sun, 19 Nov 2006 22:28:58 -0500

From: "Brian Stucker" <[email-masked]>

I would assume it's because non-2xx responses are always terminal..
Though the omission of 1xx responses seems to be a mistake.

Dale