Re: [Sip-implementors] Reflection of non-registered SDP attributes

2019-01-29 Thread Mike Coffee
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

Re: [Sip-implementors] Reflection of non-registered SDP attributes

2019-01-29 Thread Paul Kyzivat
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

Re: [Sip-implementors] Reflection of non-registered SDP attributes

2019-01-29 Thread Alex Balashov
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

Re: [Sip-implementors] Reflection of non-registered SDP attributes

2019-01-29 Thread Paul Kyzivat
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

[Sip-implementors] Reflection of non-registered SDP attributes

2019-01-29 Thread Alex Balashov
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

[Sip-implementors] image in initial INVITE

2019-01-29 Thread royj
Hi everyone Wondering if some of you have seen in the wild working sessions when originator (fax machine as a rule) sends media=image (and other corresponding options) in its initial INVITE and remote takes it without answering immediately SIP/501. If I'm not mistaken this "image in initial"