Re: [Sip-implementors] Reflection of non-registered SDP attributes
On 1/30/19 10:23 PM, Dale R. Worley wrote: It's a fascinating problem. In a way, inserting a unregistered attribute is forbidden, but any recipient is forbidden from objecting to it. OTOH, if the attribute is unregistered, you can't really say that the endpoint using it in its answer is *wrong*, since there's no fixed definition of the semantics of the attribute. Perhaps the endpoint simply means "I received CustomAttribute:GID in the offer." I think the actual answer is to be clever, and to define CustomAttribute in such a way that simply copying it into the answer unchanged can be detected and ignored. The device that copies unknown attributes from the offer to the answer is even more broken than those that use unregistered attributes. It can break valid usage. So I would really lean on it to clean up its act. Many attributes are defined so that mirroring the attribute in the answer explicitly indicates support for it. So defining one so that usage is ignored seems futile. Presumably the offerer including the attribute is hoping for an answerer that has the same understanding of it. But the two devices could have independently chosen to appropriate the same name for two different purposes. I guess they hope that if the name is sufficiently unique then the probability of this happening is small enough to ignore. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
On Wed, Jan 30, 2019 at 10:23:21PM -0500, Dale R. Worley wrote: > Perhaps the endpoint simply means "I received CustomAttribute:GID in > the offer." Yep, that's the interpretive frame in which I was contemplating the problem. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
It's a fascinating problem. In a way, inserting a unregistered attribute is forbidden, but any recipient is forbidden from objecting to it. OTOH, if the attribute is unregistered, you can't really say that the endpoint using it in its answer is *wrong*, since there's no fixed definition of the semantics of the attribute. Perhaps the endpoint simply means "I received CustomAttribute:GID in the offer." I think the actual answer is to be clever, and to define CustomAttribute in such a way that simply copying it into the answer unchanged can be detected and ignored. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
My problem is the opposite: getting carriers to use the available recommendations that enable more efficient and effective media-specific call routing: o RFC6913, Indicating FoIP Capability o RFC 3840, Indicating User-Agent Capabilities in SIP o RFC3841: Caller's routing preferences for SIP o RFC6466: Usage of the "Image" media type to indicate a T.38 session o RFC6466: Usage of the "Image" media type to indicate a T.38 session If anyone on this list is familiar with the decision making by carriers on how to route SIP calls, please e-mail me at supp...@commetrex.com to set up a conversation. It would be a plus for our industry. Mike -Original Message- From: sip-implementors-boun...@lists.cs.columbia.edu On Behalf Of Alex Balashov Sent: Tuesday, January o, 2019 11:29 AM To: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Reflection of non-registered SDP attributes Hello, On Tue, Jan 29, 2019 at 11:21:01AM -0500, Paul Kyzivat wrote: > 5.13 says: "Attributes MUST be registered with IANA", so why do you > say this isn't illegal? Upon reflection, you are certainly correct. I suppose the notion of legality I had in mind was implicitly to do with grammatical validity / request intelligibility rather than policy. So, if the attribute is not registered and if the foregoing applies to unsupported but registered attributes, and is therefore illegal, then, in the context of one of those acrimonious "how dare you say I'm not following the standards?" disputes, does this--in any _reasonable_ way, taking purely political phenomena out of it--open the door to the receiver/answerer vendor arguing that an endpoint making use of an unregistered attribute (that is to say, illegally so) is not justified in expecting predictable or standards-prescribed results in the answer? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
On 1/29/19 11:29 AM, Alex Balashov wrote: Hello, On Tue, Jan 29, 2019 at 11:21:01AM -0500, Paul Kyzivat wrote: 5.13 says: "Attributes MUST be registered with IANA", so why do you say this isn't illegal? Upon reflection, you are certainly correct. I suppose the notion of legality I had in mind was implicitly to do with grammatical validity / request intelligibility rather than policy. So, if the attribute is not registered and if the foregoing applies to unsupported but registered attributes, and is therefore illegal, then, in the context of one of those acrimonious "how dare you say I'm not following the standards?" disputes, does this--in any _reasonable_ way, taking purely political phenomena out of it--open the door to the receiver/answerer vendor arguing that an endpoint making use of an unregistered attribute (that is to say, illegally so) is not justified in expecting predictable or standards-prescribed results in the answer? In this case I think the UAC *should* expect that a conforming recipient will act in a conforming way and *ignore* the attribute - and thus *not* include it in the answer. This is because a conforming recipient cannot distinguish the non-conforming use by the UAC from use of a standard extension not known to the recipient. So the UAC *can* game the system and use this to negotiate with another UA implementing the same unregistered non-conforming extension. But you can still call them out for being non-conforming. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
Hello, On Tue, Jan 29, 2019 at 11:21:01AM -0500, Paul Kyzivat wrote: > 5.13 says: "Attributes MUST be registered with IANA", so why do you > say this isn't illegal? Upon reflection, you are certainly correct. I suppose the notion of legality I had in mind was implicitly to do with grammatical validity / request intelligibility rather than policy. So, if the attribute is not registered and if the foregoing applies to unsupported but registered attributes, and is therefore illegal, then, in the context of one of those acrimonious "how dare you say I'm not following the standards?" disputes, does this--in any _reasonable_ way, taking purely political phenomena out of it--open the door to the receiver/answerer vendor arguing that an endpoint making use of an unregistered attribute (that is to say, illegally so) is not justified in expecting predictable or standards-prescribed results in the answer? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Reflection of non-registered SDP attributes
On 1/29/19 10:21 AM, Alex Balashov wrote: Hi, I am using a media relay which implements some internal loop detection by adding a non-IANA-registered SDP attribute to any offer or answer that passes through it: a=CustomAttribute:GUID From what I understood from RFC 4566 § 5.13, this isn't illegal, but such an attribute must be ignored. 5.13 says: "Attributes MUST be registered with IANA", so why do you say this isn't illegal? The requirement to ignore unknown attributes is intended to cover the case where there has been a legal extension (with registration) that is used by the sender but not implemented by the receiver. Now, there is a particular type of endpoint in use in this environment which takes that attribute from an incoming initial INVITE--which is, by definition, not locally intelligible--and copies it dumbly into its 2xx/SDP answer. Commonsensically, this seems like broken behaviour; if it doesn't understand the attribute, it must be ignored, per § 5.13. Beyond that, is there any specific proscription against doing this in the standard? Again consider this behavior in conjunction with a valid extension. The inclusion of an attribute in an answer after receiving it in an offer is often used as an indication of support for the extension. This depends on answerers ignoring (not mirroring) attributes they don't understand. So an endpoint with this behavior will break any peer using such a legal extension. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
