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

Nick Khamis symack at gmail.com
Mon Mar 25 15:18:11 CET 2013 

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

Ciao,

Nick.

On 3/25/13, Bogdan-Andrei Iancu <bogdan at opensips.org> 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<bogdan at opensips.org>  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<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