[OpenSIPS-Users] ACK doesnt get routed to endpoint

[Vlad Paiu]

Hello,

For your case, you could try to fix the ACK using the dialog module 
fix_route_dialog() [1] function, which forces an in dialog SIP message 
to contain the ruri, route headers and dst_uri, as specified by the 
internal data of the dialog it belongs to.

[1] http://www.opensips.org/html/docs/modules/1.7.x/dialog.html#id294012

Regards,

Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com


On 02/28/2012 12:54 PM, Bogdan-Andrei Iancu wrote:
> Hi Arnold,
>
> Yes, that is totally correct !
>
> Regards,
> Bogdan
>
> On 02/28/2012 12:46 PM, Arnold Vriezekolk NETZOZEKER B.V. wrote:
>> Hey Bogdan,
>>
>> You're right about that. My idea was that i could fix this problem with
>> scripting. This is obviously wrong. I had no idea of how to get the 
>> correct
>> contact information into the sip packet, so i tried to solve it this 
>> way.
>>
>> What i'm seeing in the sip trace is that the 200 OK from our opensips 
>> proxy
>> has the correct contact information in it, but our sip provider sends 
>> back the
>> ACK without this contact information. So the problem is not on our 
>> opensips
>> side, but on the provider side. Would you say this is correct?
>>
>> Thanks for the clarification on the dialog variables.
>>
>> Best Regards,
>>
>> Arnold Vriezekolk
>>
>>
>> On Tue, 28 Feb 2012, Bogdan-Andrei Iancu wrote:
>>
>>> Hi Arnold,
>>>
>>> If I understand you right, instead on focusing on fixing the root 
>>> error, you are trying to cope with it in your script.
>>>
>>> As I said, the ACK you receive on .90 (from the previous hops) is 
>>> bogus as it has incomplete route set (the contact info of callee is 
>>> missing). So, it is not a problem in your script, but a problem with 
>>> the previous SIP hops.
>>>
>>> Also, to answer to your questions - yes the ACK is part of the same 
>>> dialog. But note that the dialog variables will be available (for 
>>> ACK) only after doing the loose_route() - here is where the ACK is 
>>> matched against the dialog. To check if the ACK matched the dialog 
>>> (after loose_route), check the $DLG_status variable - if it is NULL, 
>>> your ACK did not matched.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> On 02/28/2012 12:01 PM, Arnold Vriezekolk NETZOZEKER B.V. wrote:
>>>> Thanks for the reply Bogdan,
>>>>
>>>> If the ACK has the same tag in the From header as the initial 
>>>> INVITE, isnt
>>>> that considered the same dialog?
>>>>
>>>> What i'm trying to achieve is set an AVP variable that has some 
>>>> information
>>>> about this call. Whenever i try to reach the variable at the point 
>>>> the ACK
>>>> message comes in from our sip provider the variable is empty.
>>>>
>>>> How can i make sure that when i set a variable at the initial 
>>>> INVITE i can
>>>> reach it when the ACK comes in? Script variables also dont seem to 
>>>> work for
>>>> me because they get overwritten. I might be able to set a variable 
>>>> based on a
>>>> unique descriptor based on the call.
>>>>
>>>> Best Regards,
>>>>
>>>> Arnold Vriezekolk
>>>>
>>>> On Fri, 24 Feb 2012, Bogdan-Andrei Iancu wrote:
>>>>
>>>>> Hi Arnold,
>>>>>
>>>>> The ACK you get in .90 is bogus, as it should have in RURI the 
>>>>> .130 IP from the
>>>>> 200 OK Contact. Actually the end-point info from 200 OK (the .130) 
>>>>> is not present
>>>>> at all in the ACK, so basically the ACK cannot end up to that end 
>>>>> point at all.
>>>>>
>>>>> Regards,
>>>>> Bogdan
>>>>>
>>>>> On 02/24/2012 04:47 PM, Arnold Vriezekolk NETZOZEKER B.V. wrote:
>>>>>       Hi,
>>>>>
>>>>>       In our setup we have a connection to a sip provider for 
>>>>> incoming
>>>>>       lines. We use
>>>>>       opensips with the uac_registrant module to connect to this sip
>>>>>       provider.
>>>>>
>>>>>       Whenever a call comes in, i use rewriteuri() and t_relay() 
>>>>> to send it
>>>>>       to an
>>>>>       endpoint. When i pick up the call on my endpoint the ACK 
>>>>> message from
>>>>>       the sip
>>>>>       provider doesn't get routed back to my endpoint, but somehow 
>>>>> gets
>>>>>       stuck in
>>>>>       opensips. Thus failing the call after 3 seconds.
>>>>>
>>>>>       The ACK should be routed by the default sequential request 
>>>>> block in
>>>>>       the
>>>>>       request route[0] afaik but it doesnt.
>>>>>
>>>>>       Can anyone point me as to where i can fix this problem?
>>>>>
>>>>>       I attached a pcap dump of the call for debugging purposes.
>>>>>       Endpoint: sip:EEEEEEEE at netzozeker.tel.netzozeker.nl 
>>>>> (95.97.29.130)
>>>>>       SIP provider: 89.184.172.54
>>>>>       OpenSIPS: 195.60.212.90
>>>>>
>>>>>       If you need more information please let me know, i can 
>>>>> attach the
>>>>>       opensips.cfg
>>>>>       and the log of opensips for more debugging purposes.
>>>>>
>>>>>       Best Regards,
>>>>>
>>>>>       Arnold Vriezekolk
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Bogdan-Andrei Iancu
>>>>> OpenSIPS Founder and Developer
>>>>> http://www.opensips-solutions.com
>>>>>
>>>>>
>>>
>>>
>>> -- 
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>
>