Hi Nick,
In a similar way you can use the set_advertised_address() function
(http://www.opensips.org/Resources/DocsCoreFcn18#toc145) only for calls
that really go outside your net (on public side) ; this is instead of
global option of advertise_address.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 03/20/2013 06:04 PM, Nick Khamis wrote:
Hello Bogdan,
The think is with advertise_address is that I find local traffic
behind the same NAT goes outside of the network and back into the
network. If I can insert record_route_preset in the correct spots
within our configuration and (1) differentiate between internet and
intranet src, and (2) form a RR that suffice, it would be a smoother
approach?
I will post my solution for others to see.
N.
On 3/20/13, Bogdan-Andrei Iancu<[email protected]> wrote:
HI Nick,
Using the advertise_address will also do the trick for you, no need to
do the record_route_preset().
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 03/19/2013 05:52 PM, Nick Khamis wrote:
Hello Bogdan,
Thank you so much for your response. We did have an RR problem that
did not allow for an "ACK" to our "200 OK". Our solution was to change
"advertised_address" to use the public IP instead of the local net,
which seemed to get the RR problem solved. The server related global
parameters we are using are as follow:
alias=<public ip>
auto_aliases=no
disable_dns_failover=yes
sip_warning=no
port=5060
listen=udp:192.168.2.5:5060
advertised_address=<public ip>
This got the external ACK responses to our 200, but only one way audio
(probably RTP proxy related, and started a new message for that
issue).
The question is, Should I change "advertised_address" back to private
IP, and use "record_route_preset" instead? In the meanwhile, I will
try it.
Nick.
On 3/19/13, Bogdan-Andrei Iancu<[email protected]> wrote:
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
