Re: INFO Framework: Tags
Dean Willis <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
On Nov 20, 2008, at 10:45 PM, Elwell, John wrote: > Dean, > >> -----Original Message----- >> From: Dean Willis [mailto:[email protected]] >> Sent: 20 November 2008 23:16 >> To: DRAGE, Keith (Keith) >> Cc: Christer Holmberg; Paul Kyzivat; SIP List; Elwell, John >> Subject: Re: [Sip] INFO Framework: Tags >> >> >> >> No, you use the options tag with a sip.extensions media feature tag >> ala RFC 3840 in order to get a retargeting proxy to send the request >> only to the subset of UAS that support the extension. > [JRE] RFC 3841 does not compel a proxy to behave in this way, and in > fact the proxy might not even support RFC 3841. RFC 3840/3841 can insure such behavior, and (with Proxy-require) can assure that the proxy either supports the extension or rejects the call. > So you have to be > prepared for your INVITE/Recv-Info to go to any UAS. well, it MIGHT do so, and fail in a predictable way as a consequence due to the Require: info-package. That's not a bad thing. > I don't in general > see a need to specify this as part of the extension in general, but > if a > particular package needs a feature tag, let it define one. Keep the > extension simple. Only standards-track RFCs can define SIP option tags under RFC 3427, and we have no plans to relax this requirement. But we have a much looser policy for INFO packages; most will not be standards-track. So, for those sorts of packages, an info-package option tag is potentially quite useful. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip