Hello,
Sorry Ryan, I might have went too fast through the PCAP and did not
initially spot your actual problem.
It seems that your problem is caused by the INVITE retransmission. When
you reject the first INVITE you do it stateless-ly so the message does
not ever reach TM level. When the retransmission comes, it is not
absorbed by TM, so it is actually your retransmission that gets
delivered to the other side.
Please try to add a call to t_newtran() when starting to process the
INVITEs to make sure that the TM is aware of them and can absorb
retransmissions. This should fix your issue.
Regards,
Vlad Paiu
OpenSIPS Developer
On 11/11/2011 04:28 PM, Ryan Revels wrote:
Vlad,
I'm a little confused by your response. I attached a pcap that shows
the ACK being received. I'm trying to understand why OpenSIPS would
continue to process the call after it replies with a 486 and exits the
script.
I would really appreciate any help.
Thanks,
Ryan
On Fri, Nov 4, 2011 at 5:37 AM, Vlad Paiu <[email protected]
<mailto:[email protected]>> wrote:
Hello,
From the output of dlg_list, I can see that the ACK was never
received by OpenSIPS, so seems this is the source of your problem.
You could try to set the dialog timeout to a lower value after the
200 OK is received ( couple of seconds ), and increase it after
the ACK is received to a couple of hours.
Regards,
Vlad Paiu
OpenSIPS Developer
On 11/03/2011 10:36 PM, Ryan Revels wrote:
I've run into an issue where /very/ rarely, dialogs will "hang",
that is, the dialog will continue to exist even though the call
never connected. In the example I managed to track down, the
proxy should reject the call (because a limit of concurrent calls
has been reached) and at first, it seems like it's going to...
but then it sends a 100 Trying and continues to route the call to
the destination. From there, everything spirals and the dialog
doesn't die until it hits the global timeout.
The relevant portion of my script looks like:
# Check gateway calls total
if ($avp(custgwtotal_limit) != "0" && $avp(custgwtotal_limit) !=
NULL && $avp(custgwtotal_limit) != "")
{
get_profile_size("custgwtotal","$rd","$avp(custgwtotal_count)");
if (!$avp(custgwtotal_count) < $avp(custgwtotal_limit))
{
sl_send_reply("486","Endpoint Session Limit");
exit;
}
}
set_dlg_profile("custgwtotal","$rd"); #count total calls to
customer's IP
I've attached a pcap example of what the signaling looks like
when the dialog hangs. For this example, the output in dlg_list
looks like:
dialog:: hash=629:349156783
state:: 3
user_flags:: 0
timestart:: 1320336333
timeout:: 1320357957
callid:: did2.139.1120741
from_uri:: sip:[email protected]
<mailto:sip%[email protected]>
to_uri:: sip:[email protected]
<mailto:sip%[email protected]>
caller_tag:: 1ae26ee84c61df6b84baef371d2bf5e4
caller_contact:: sip:184.106.219.203:5060;transport=udp
callee_cseq:: 0
caller_route_set::
caller_bind_addr:: udp:184.106.218.8:5060 <http://184.106.218.8:5060>
callee_tag:: as58f4e19a
callee_contact:: sip:[email protected]
<mailto:sip%[email protected]>
caller_cseq:: 2
callee_route_set::
callee_bind_addr:: udp:184.106.218.8:5060 <http://184.106.218.8:5060>
Any help would be appreciated.
Thanks,
Ryan
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
