Hi Nick,
As I suspect that your opensips is not an end-point in the call (but
simply a proxy), I guess the right approach is to reflect the network
changing in the RR headers, and not in Contact (contact reflects the end
points in dialog).
I suggest using the record_route_preset() and pushing all the time the
public IP of opensips in the RR header.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 03/19/2013 04:43 PM, Nick Khamis wrote:
Hello Muhammad, thanks again for your response. On our test
environment, our opensips+rtpproxy server is behind NAT, and the
reason we are modifying the contact header is to point to
1001@<opensips-public-ip> instead of 1001@<opensips-private-ip>. UA
1001 is also behind the same NAT.
My first question, do I need to modify the contact header? Or should I
be paying closer attention to the SDP payload. Making sure c=, and o=
are pointing to the right locations?
Your help is greatly appreciated.
Nick.
On 3/19/13, Muhammad Shahzad<[email protected]> wrote:
Yup, that's expected to happen. ACK is sent to Contact header of 200 OK.
So, if you mess up with it, then unexpected results will happen, as in your
case you are perhaps setting Contact address of 200 OK pointing to opensips
itself, instead of destination party, so ACK will obviously loop as
expected.
Thank you.
On Mon, Mar 18, 2013 at 5:55 PM, Nick Khamis<[email protected]> wrote:
Hello Everyone,
We are changing the "Contact" header in the on_reply to a public ip
address using:
onreply_route[1] {
xlog("incoming reply\n");
if (has_body("application/sdp")) {
remove_hf("Contact");
append_hf("Contact:
<sip:[email protected]>\r\n");
append_hf("P-hint: Onreply-route -
fixcontact \r\n");
}
}
When doing so, ACK is going into a loop:
U 2013/03/18 13:42:11.021017 75.15.201.2:5060 -> 192.168.2.5:5060
ACK sip:75.15.201.2;lr;did=b03.4af9f8f3 SIP/2.0.
Call-ID: [email protected].
CSeq: 102 ACK.
From: "15178334003"<sip:[email protected]>;tag=91641.
To:<sip:[email protected]>;tag=2643FD58-346926A7.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 75.15.201.2;branch=z9hG4bKcd1e.d68abdc.2.
Via: SIP/2.0/UDP 7
Your help is greatly appreciated,
Nick.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: [email protected]
Email: [email protected]
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
