[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] INFO Framework: Tags
The option tag is used in OPTIONS responses (and in Supported header fields in other responses) to inform a correspondent that the node in question supports this extension, potentially leading to a decision as to which behavior to apply to future requests.
It is also used in Require header fields of requests to cause the request to be rejected by any UAS that does not understand the extension. This is potentially critical for applications that find themselves completely dependent on the extension.
One might ask whether this is critical; after all the INVITE exchange will tell us what info packages (if any) the far end is willing to use. What is the difference between not using INFO packages and not supporting them?
The answer is in the fallback to pre-package INFO behavior. A node supporting INFO packages will, IIRC (or at least "if I get my way") , always use packages when sending INFO. A node not supporting INFO packages is likely to send old-style un-negotiated INFO, meaning you might need to be prepared with that behavior. Being informed (by Supported) which state applies might be useful. 

--
Dean



On Nov 20, 2008, at 10:44 AM, DRAGE, Keith (Keith) wrote:


Option-tag:
-----------

I strongly think we should define an option tag for info packages.
I think you need to provide more than this in terms of explanation. What 
interoperability issues do you think is solved by providing an option
tag for the extension itself, as opposed to individual packages?

Give us some valid scenarios.

regards

Keith


-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Thursday, November 20, 2008 1:12 PM
To: DRAGE, Keith (Keith); Elwell, John; Eric Burger; SIP List
Subject: RE: [Sip] INFO Framework: Tags


Hi,

Feature-tags:
-------------


I agree with John here.

I would include an informative reference to RFC 3427 indicating that

any draft that requires option tags for a package

would need to have the status required for option tag registration.


One option would have been to define an info feature tag
which can list package value, and each package could then
specify a value.

E.g sip.info="dtmf-packkage, isup-package"

But, I am ok with John's proposal also, but I think we should
add some text as suggested by Keith.


Option-tag:
-----------

I strongly think we should define an option tag for info packages.

Regards,

Christer







-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On

Behalf Of

Elwell, John
Sent: Thursday, November 20, 2008 1:16 AM
To: Eric Burger; SIP List
Subject: Re: [Sip] INFO Framework: Tags

Eric,

If an individual package requires an option tag, that

option tag could


be defined in the RFC that defines the package, which would

need to be


standards track. I don't think we need to say anything about this.

Similar situation for media tags, except that RFC would not

need to be


standards track.

John


-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On

Behalf Of

Eric Burger
Sent: 20 November 2008 00:48
To: SIP List
Subject: [Sip] INFO Framework: Tags

Do we want to specify media tags to indicate package support?

Do we want to specify SIP option tags to require Info

Package support?


Comments welcome.


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip