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:[email protected] (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
[email protected]
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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
