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:[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
--
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
