ACK Loop when changing contact on_reply: Please Help!!!

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

ACK Loop when changing contact on_reply: Please Help!!!

symack
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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
CSeq: 102 ACK.
From: "15178334003" <sip:[hidden email]>;tag=91641.
To: <sip:[hidden email]>;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

shaheryarkh
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 <[hidden email]> 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:
<[hidden email]>\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: [hidden email].
CSeq: 102 ACK.
From: "15178334003" <[hidden email]>;tag=91641.
To: <[hidden email]>;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
[hidden email]
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: [hidden email]
Email: [hidden email]

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

symack
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 <[hidden email]> 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 <[hidden email]> 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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
>> CSeq: 102 ACK.
>> From: "15178334003" <sip:[hidden email]>;tag=91641.
>> To: <sip:[hidden email]>;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
>> [hidden email]
>> 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: [hidden email]
> Email: [hidden email]
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

Bogdan-Andrei Iancu-2
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<[hidden email]>  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<[hidden email]>  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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
>>> CSeq: 102 ACK.
>>> From: "15178334003"<sip:[hidden email]>;tag=91641.
>>> To:<sip:[hidden email]>;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
>>> [hidden email]
>>> 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: [hidden email]
>> Email: [hidden email]
>>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

symack
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.

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

symack
My approach was covered here:

http://openser.org/pipermail/users/2008-September/000473.html

Will use record_route_preset(public vs. private) in our logic, and
change back the value of advertised address back to the private IP for
local traffic to route logically....

Thanks Again Bogdan!

Nick.

On 3/19/13, Nick Khamis <[hidden email]> 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.
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

Bogdan-Andrei Iancu-2
In reply to this post by Bogdan-Andrei Iancu-2
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<[hidden email]>  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<[hidden email]>   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<[hidden email]>   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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
>>>>> CSeq: 102 ACK.
>>>>> From: "15178334003"<sip:[hidden email]>;tag=91641.
>>>>> To:<sip:[hidden email]>;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
>>>>> [hidden email]
>>>>> 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: [hidden email]
>>>> Email: [hidden email]
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

symack
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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>   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<[hidden email]>
>>>>> 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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
>>>>>> CSeq: 102 ACK.
>>>>>> From: "15178334003"<sip:[hidden email]>;tag=91641.
>>>>>> To:<sip:[hidden email]>;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
>>>>>> [hidden email]
>>>>>> 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: [hidden email]
>>>>> Email: [hidden email]
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

Bogdan-Andrei Iancu-2
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<[hidden email]>  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<[hidden email]>   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<[hidden email]>    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<[hidden email]>
>>>>>> 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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
>>>>>>> CSeq: 102 ACK.
>>>>>>> From: "15178334003"<sip:[hidden email]>;tag=91641.
>>>>>>> To:<sip:[hidden email]>;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
>>>>>>> [hidden email]
>>>>>>> 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: [hidden email]
>>>>>> Email: [hidden email]
>>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [hidden email]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: ACK Loop when changing contact on_reply: Please Help!!!

symack
Amazing!!! Will do that instead. Thanks Bogdan!

Ciao,

Nick.

On 3/25/13, Bogdan-Andrei Iancu <[hidden email]> wrote:

> 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<[hidden email]>  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<[hidden email]>   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<[hidden email]>    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<[hidden email]>
>>>>>>> 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:1001@75.15.201.2>\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: VQUK2UGSQBCPHEW27UN5NBJIQM@81.201.86.45.
>>>>>>>> CSeq: 102 ACK.
>>>>>>>> From: "15178334003"<sip:[hidden email]>;tag=91641.
>>>>>>>> To:<sip:[hidden email]>;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
>>>>>>>> [hidden email]
>>>>>>>> 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: [hidden email]
>>>>>>> Email: [hidden email]
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> [hidden email]
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users