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 pre
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 min
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 va
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
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 ignore
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" do
