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

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sat, 11 Nov 2006 19:31:42 +0100

(As SIP WG chair)

As part of the ICE discussion in MMUSIC, it has been identified that
there is a need for an option tag. RFC 3427 says that documents
specifying these need to be presented to IESG by SIP. Rather than
transfer the entirety of ICE back to SIP, the proposal is to create a
separate draft that specifies this option tag and pursue this in SIP.

I would appreciate if Jonathan would post to this list a some idea of
the semantics of the new option tag.

The intention of the SIP WG chairs is therefore to request the ADs to
approve a new milestone in this area. 

Therefore does anyone in the SIP WG have an issue with the creation of a
new WG item that specifies such a new option-tag. This is intended to be
a fairly short term activity (as ICE is regarded as pretty much
finished) so please respond quickly.

Regards

Keith

Keith Drage
[email-masked]
tel: +44 1793 776249

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Nov 2006 11:48:11 -0500

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.

Another use case that was suggested was to place the option tag in a 
REGISTER. This would inform the "network" about whether the UA supports 
ICE, and can be helpful in some of the backwards-compatibility 
techniques that people are looking at.

Thanks,
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

---

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

I think the idea of having an option tag in the REGISTER is a good idea.
It may be helpful when the network is trying to initiate a call to the
client.

Regards,
Brian 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, November 13, 2006 10:48 AM
> 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.
> 
> Another use case that was suggested was to place the option 
> tag in a REGISTER. This would inform the "network" about 
> whether the UA supports ICE, and can be helpful in some of 
> the backwards-compatibility techniques that people are looking at.
> 
> Thanks,
> Jonathan R.
> 
> > Therefore does anyone in the SIP WG have an issue with the 
> creation of 
> > a new WG item that specifies such a new option-tag. This is 
> intended 
> > to be a fairly short term activity (as ICE is regarded as 
> pretty much
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 17 Nov 2006 18:15:46 +0100

In that case, how about a callee capability instead / in addition (RFC3840)?
i.e. a UA would form its Contact as:

Contact: <sip:whatever>;+sip.ice

Regards,
Jeroen

Brian Stucker wrote:
> I think the idea of having an option tag in the REGISTER is a good
> idea. It may be helpful when the network is trying to initiate a call
> to the client.
> 
> Regards,
> Brian
> 
>>> a new WG item that specifies such a new option-tag. This is intended

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 17 Nov 2006 11:26:08 -0600

Makes sense to me.

Regards,
Brian 

> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Friday, November 17, 2006 11:16 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
> 
> >> for an option tag for the "normal" call flows.
> 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.
> >> 
> >> REGISTER. This would inform the "network" about whether the UA 
> >> supports ICE, and can be helpful in some of the 
> >> backwards-compatibility techniques that people are looking at.
> >> 
> >> Thanks,
> >> Jonathan R.
> >> 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >> 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 17 Nov 2006 21:37:03 -0500

Yes, I agree - I specifically asked for this in the WG meeting.  I think it
will help for mixed ICE/non-ICE networks. 
-hadriel

> From: Brian Stucker [mailto:[email-masked]]
> Sent: Friday, November 17, 2006 10:59 AM
> To: Jonathan Rosenberg; Drage, Keith (Keith)
> Cc: IETF SIP List
> Subject: RE: [Sip] Re: New work: Option-tag for ICE
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2006 17:07:01 -0500

In the REGISTER case, I think its probably *slightly* more correct to 
use a capability and not an option tag. This is because you could have a 
third party registration, with different ICE support for different 
contacts in the registration.

FWIW I am very sour these days on third party registrations; indeed, 
I've gone as far as to propose deprecating them as part of UA's 
compliant to route-construct:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-02.txt

That said, we do need an option tag in the case of a Require header in 
an INVITE. Per the other thread I think I've concluded its not useful in 
an offerless INVITE. For presence documents, either would work (though 
an option tag is simpler since it doesn't require a prescaps extension).

So, my proposal would be to define both, and use the callee cap in 
registrations. Option tag would just be for Require.

-Jonathan R.

Jeroen van Bemmel wrote:

>>>> As part of the ICE discussion in MMUSIC, it has been
>>>
>>> identified that
>>>
>>>> transfer the entirety of ICE back to SIP, the proposal is
>>>
>>> to create a
>>>
>>>> separate draft that specifies this option tag and pursue
>>>
>>> this in SIP.
>>>
>>>>
>>>> I would appreciate if Jonathan would post to this list a
>>>
>>> some idea of
>>>
>>>> The intention of the SIP WG chairs is therefore to request
>>>
>>> the ADs to
>>>