Page 1 of 1

incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Wed Mar 29, 2017 12:29 am
by hopierre
Phone call is make from sip phone(310HD) to land line. It seems like sipsorcery is sending BYE.

console:
DialPlan 00:25:55:258 sip1(1556): Matching dialogue found for BYE to sip:67.222.131.147:5060 from udp:67.222.131.147:5060.
Registrar 00:25:57:052 sip1(2996): Authentication required for my_acct@sipsorcery.com from udp:my-ip:5080.
Registrar 00:25:57:177 sip1(2996): Binding update request for my_acct@sipsorcery.com from udp:my-ip:5080, expiry requested 600s granted 600s.


wireshark:
Untitled.png
Untitled.png (33.25 KiB) Viewed 327 times
any pointer will be appreciative.

thanks,
Pierre

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Wed Mar 29, 2017 6:48 pm
by rswenton
I am experiencing dropped incoming calls. Have not tested outgoing. I will do more testing.

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Wed Mar 29, 2017 11:55 pm
by hopierre
More detail, this device was working fine before GV made the UI changes.

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Sun Apr 02, 2017 10:49 am
by Aaron
Is this referring to a Google Voice call or a standard SIP call?

The only time the sipsorcery server will generate a BYE request to hangup a call is if the cd dial string parameter is used with a sys.Dial command (http://www.sipsorcery.com/mainsite/Help/DialPlans#Dial).

If it's not a GV call then it could be a SIP problem. Some SIP devices will time out transactions and hang up calls after a period of time, normally 30 to 60s, if the ACK request doesn't get through or is wrong. For higher times, such as the 300s, in this case it's more likely to be that one of the SIP devices doesn't think any audio is being received and therefore hangs up the call. Do you have two way audio?

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Mon Apr 03, 2017 5:25 pm
by rswenton
Hi Aaron,

In my case it is a GV call and it seemed to start after Google changed the user interface. I will explore your suggestion of the device thinking there was audio silence. Yes there is 2-way audio. Thanks! -Rick

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Mon Apr 03, 2017 5:56 pm
by hopierre
Yes, it's a GV call. I was testing with no audio passing. Let me try with some music.
As I mention, my other grandstream ATA is working fine.
Hopping there is some parameters that I can tweak on the device to make it work.
During my testing, I was able get pass 300 secs mark once or twice.

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Mon Apr 03, 2017 11:12 pm
by hopierre
Does my dial-plan look OK?

AREA_CODE = '510'
GV_USER = 'xxxxxxx@gmail.com'
GV_PASS = 'xxxxxxxxxx'
CB_NUMBER = '+1914xxxxxx'


begin
sys.Log "** Call from #{req.Header.From} to #{req.URI.User} **"

if sys.Out # if outbound call
num = req.URI.User.to_s # Get a string copy of the number to dial

case num
when /@/ then sys.Dial num # URI dialing
when /^[2-9]\d{6}$/ # Local call, 7-digit number
num = '1'+ AREA_CODE + num # prefix it with country and area code
when /^[01]?([2-9]\d{9})/ # US number with or without country code
num = '1' + $1 # add country code and truncate number to 10-digit
when /^(011|00|\+)(\d{9,})/ # international number
num = '+' + $2 # GoogleVoiceCall works with '+' prefix only

else sys.Respond 603, 'Wrong number, check & dial again'
end

case num
when /^1777/ then sys.Dial ("#{num}@in.callcentric.com")
else
sys.Log "Calling #{num} via Google Voice"
sys.GoogleVoiceCall GV_USER, GV_PASS, CB_NUMBER, num, '.*', CB_NUMBER =~ /^1777/ ? 7 : 1, 30
end

else # sys.Out
sys.Dial "#{sys.Username}@local"
end

rescue
sys.Log("** Error: " + $!) unless $!.to_s =~ /Thread was being aborted./
end

Re: incoming and outgoing call drop after 300 seconds particular SIP phone

Posted: Wed Apr 05, 2017 1:49 am
by Aaron
Yes your dialplan looks ok. The dialplan is only involved in the call up until the point it's answered so if the call gets set up correctly then it's almost certainly not going to be a dialplan problem. The only exception is if the "cd" dial command option is being used, which will cause the call to be automatically hungup after a set amount of time, and in your case it's not being used.