[OpenSIPS-Users] ACK Loop when changing contact on_reply: Please Help!!!

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Mar 20 13:36:52 CET 2013


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<bogdan at opensips.org>  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<shaheryarkh at gmail.com>   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<symack at gmail.com>   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 at 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 at 81.201.86.45.
>>>>> CSeq: 102 ACK.
>>>>> From: "15178334003"<sip:15178334003 at voip.ms>;tag=91641.
>>>>> To:<sip:1001 at toronto.symack.com>;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
>>>>> Users at lists.opensips.org
>>>>> 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: shari_786pk at hotmail.com
>>>> Email: shaheryarkh at googlemail.com
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>



More information about the Users mailing list