Hello,
are you using topoh module?
A pcap with all sip messages part of the dialog, from the initial INVITE
to the last BYE transaction would be important to have in order to
investigate how the headers are changed.
Cheers,
Daniel
On 28/12/2016 13:11, Nihar Ranjan Deb wrote:
>
> Hi All,
>
>
Anyone any help on this.
Regards,
Nihar
From: Nihar Ranjan Deb [mailto:nihar.ran...@microtalkgroup.com]
Sent: Wednesday, December 28, 2016 5:42 PM
To: 'sr-users@lists.sip-router.org'
Subject: BYE issue kamailio + rtpproxy "481 call leg transaction doesn't
exists".
Hi All,
Thank you very much for your support,
When you say: "They may be able to disable this for you – otherwise you’ll
need to rewrite the headers yourself."
How can I rewrite the header if I dont have destination IP?, there are four
Asterisk servers and all of them send calls to the bridged Kamailio
ubject: Re: [SR-Users] BYE issue
Handling NAT, perhaps, but not correctly. The RURI doesn't change. But not does
it have to determine where the request is actually sent on the network and
transport layers.
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google
Handling NAT, perhaps, but not correctly. The RURI doesn't change. But not does
it have to determine where the request is actually sent on the network and
transport layers.
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
It sounds like the vendor is handling NAT traversal on their side. They will be
assuming that Asterisk is behind NAT, because of the presence of private IP
addresses – particularly in the contact, and will be rewriting various parts.
They may be able to disable this for you – otherwise you’ll
Nelson,
You are very correct. The request URI of the BYE (and all other
in-dialog requests, such as reinvites) should equal the Contact URI of
the party to which it is being sent, and this should not change even if
the in-dialog request is being sent through Kamailio because of
Record-Route.
