Re: [OpenSIPS-Users] Hung dialogs

[Ryan Revels]

Vlad,

Thanks. I will give this a shot.

Ryan

On Fri, Nov 11, 2011 at 9:50 AM, Vlad Paiu  wrote:

> **
> 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  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:16034299966@64.136.174.30
>>  to_uri:: sip:16038869119@184.106.218.8
>>  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
>>  callee_tag:: as58f4e19a
>>  callee_contact:: sip:16038869119@71.168.70.47
>>  caller_cseq:: 2
>>  callee_route_set::
>>  callee_bind_addr:: udp:184.106.218.8:5060
>>
>>  Any help would be appreciated.
>>
>>  Thanks,
>> Ryan
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Hung dialogs

[Vlad Paiu]

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 > 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:16034299966@64.136.174.30

to_uri:: sip:16038869119@184.106.218.8

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 
callee_tag:: as58f4e19a
callee_contact:: sip:16038869119@71.168.70.47

caller_cseq:: 2
callee_route_set::
callee_bind_addr:: udp:184.106.218.8:5060 

Any help would be appreciated.

Thanks,
Ryan


___
Users mailing list
Users@lists.opensips.org  
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Hung dialogs

[Ryan Revels]

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  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:16034299966@64.136.174.30
>  to_uri:: sip:16038869119@184.106.218.8
>  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
>  callee_tag:: as58f4e19a
>  callee_contact:: sip:16038869119@71.168.70.47
>  caller_cseq:: 2
>  callee_route_set::
>  callee_bind_addr:: udp:184.106.218.8:5060
>
>  Any help would be appreciated.
>
>  Thanks,
> Ryan
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Hung dialogs

[Vlad Paiu]

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:16034299966@64.136.174.30 

to_uri:: sip:16038869119@184.106.218.8 


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 
callee_tag:: as58f4e19a
callee_contact:: sip:16038869119@71.168.70.47 


caller_cseq:: 2
callee_route_set::
callee_bind_addr:: udp:184.106.218.8:5060 

Any help would be appreciated.

Thanks,
Ryan


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Hung dialogs

[Duane Larson]

You want to trade concurrent call scripts?  I have one to and sometimes run
into issues where it thinks there is an existing call for a user so it
sends a reached max calls limit.




On Thu, Nov 3, 2011 at 3: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:16034299966@64.136.174.30
>  to_uri:: sip:16038869119@184.106.218.8
>  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
>  callee_tag:: as58f4e19a
> callee_contact:: sip:16038869119@71.168.70.47
>  caller_cseq:: 2
> callee_route_set::
>  callee_bind_addr:: udp:184.106.218.8:5060
>
> Any help would be appreciated.
>
> Thanks,
> Ryan
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 
--
*--*--*--*--*--*
Duane
*--*--*--*--*--*
--
route[ConcurrentCallLimiter]
{

xlog("L_INFO", "Route ConCurrentCall: Call [$rm] du [$du] rd [$rd] td [$td] ds 
[$ds] Ri [$Ri] rU[$rU] fU[$fU] ru[$ru] fu[$fu] tu[$tu] od[$od] fd[$fd]\n");


## have we done our checking on this call?
if(!isflagset(31) && $hdr(User-Agent)!~ "ipcom.at")
{

#This will keep up with concurrent calls for Caller (fu)
#The td != aethercommunications is to keep the internal callee 
from having double concurrent calls due to a hunt group call
#If this wasn't here then if 3...@irock.com called 
huntgro...@irock.com and 444 was the callee from huntgroup then he
#would be considered the caller and callee because of the SIP 
INVITE coming from the asterisk server
if(avp_db_load("$fu/username", "$avp(channels)") && $td != 
"aethercommunications.com" ) {

# user has max channel limit set as preference
if(is_avp_set("$avp(channels)/n") && 
avp_check("$avp(channels)", "gt/i:0"))
{
# get current calls for uuid

get_profile_size("ConcurrentCalls","$fU","$var(CallerCalls)");

# check within limit
if($avp(channels) > $var(CallerCalls))
{
xlog("L_INFO", "Call control: Caller 
'$fU' currently has '$var(CallerCalls)' of '$avp(channels)' active calls before 
this one\n");
$var(setprofileCaller) = 1;
}
else
{
xlog("L_INFO", "Call control: Caller 
channel limit exceeded [$var(CallerCalls)/$avp(channels)]\n");
sl_send_reply("487","Request 
Terminated: Channel limit exceeded");
exit;
}
}
else
{
$var(setprofileCaller) = 0;
}



if($var(setprofileCaller) > 0)
{
if ( !match_dialog() )
{
create_dialog();
}
set_dlg_profile("ConcurrentCalls","$fU");

get_profile_size("ConcurrentCalls","$fU","$var(CallerCalls)");
xlog("L_INFO", "Call control: Caller '$fU' now 
has '$var(CallerCa

Re: [OpenSIPS-Users] Hung dialogs

[duane . larson]

Have you looked at the following
http://www.opensips.org/html/docs/modules/devel/dialog.html#id293895

OpenSIPS will send OPTIONS pings to whoever you want to and if they don't  
answer back because they don't recognize the Dialog then opensips will send  
a BYE to both caller and callee and kill the dialog.


Does that help any?

On , 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)
{




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:16034299966@64.136.174.30




to_uri:: sip:16038869119@184.106.218.8




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




callee_tag:: as58f4e19a
callee_contact:: sip:16038869119@71.168.70.47




caller_cseq:: 2
callee_route_set::




callee_bind_addr:: udp:184.106.218.8:5060







Any help would be appreciated.






Thanks,
Ryan



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Hung dialogs

[Ryan Revels]

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:16034299966@64.136.174.30
 to_uri:: sip:16038869119@184.106.218.8
 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
 callee_tag:: as58f4e19a
callee_contact:: sip:16038869119@71.168.70.47
 caller_cseq:: 2
callee_route_set::
 callee_bind_addr:: udp:184.106.218.8:5060

Any help would be appreciated.

Thanks,
Ryan


hung_call.pcap
Description: Binary data
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users