<SOLVED>UCM6100 terminates in/out going calls at abt 30 seconds (Freephoneline)

#1

UCM6102 running Firmware:1.0.10.39

I am setting up a new UCM6102 unit . I am using Freephoneline and VoipMS as Trunks. Both incoming and out going calls are being cut off at 31 seconds every time. I have done a trace using the builtin capture tool. It looks to me that the UCM is sending a “BYE”. Of course I have looked eveywhere in the settings to find where it has been misconfigured without any success. Have I missed anything obvious where the calls can be terminated at the same time? I have NOT set any “Call Duration Limit” on the extensions.

Partial trace: Freephoneline Trunk

[code]v=0
o=- 82665424 2 IN IP4 172.16.240.3
s=Asterisk
c=IN IP4 45.3.XXX.XXX
b=CT:384
t=0 0
m=audio 11568 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
…BYE sip:208.65.240.44:5060 SIP/2.0
Via: SIP/2.0/UDP 45.3.20.48:5060;rport;branch=z9hG4bKPjac83e48c-aa1c-463a-84f4-3b779177810b
From: sip:15145551212@208.65.240.165;tag=2379eb0a-c1dd-453b-96f4-0a7bfa04f041
To: sip:514321XXXX@208.65.240.165;tag=2th7mygi3rdfrqzl.o
Call-ID: DC609A32@208.72.120.66~o~o
CSeq: 20557 BYE
Route: sip:15145551212@208.65.240.44;lr
Route: sip:208.65.240.165:5060;transport=UDP;lr
Max-Forwards: 70
User-Agent: Grandstream UCM6102V1.5B 1.0.10.39
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 45.3.20.48:5060;received=45.3.20.236;rport=5061;branch=z9hG4bKPjac83e48c-aa1c-463a-84f4-3b779177810b
Record-Route: sip:208.65.240.44;lr
Record-Route: sip:208.65.240.44;lr=on
To: sip:514321XXXX@208.65.240.165;tag=2th7mygi3rdfrqzl.o
From: sip:15145551212@208.65.240.165;tag=2379eb0a-c1dd-453b-96f4-0a7bfa04f041
Call-ID: DC609A32@208.72.120.66~o~o
CSeq: 20557 BYE
Server: Sippy
Content-Length: 0
[/code]

#2

Your 30 second timeout is the key here; if you had said 8~16 seconds, I would have said there is a mismatch to the Codec being used, as the systems negotiate to use a shared Codec, if one cannot be agreed upon, the call will terminate.

At 30 seconds, I’d look more toward an ‘Additional SIP Setting’ to be applied (provided this is a SIP trunk)…as I’ve had a similar situation on a FreePBX system, where the engineer from Support told me to add an Additional SIP Setting such as ‘rtptimeout=none’ (I’m using that loosely as an example…this is NOT the correct statement; I’ll try to look that up and post it when I find it) but for now hoping one of these 2 ideas will spark something in your testing.

-phoneguy

#3

I think I found what I was looking for- it’s a statement in the ‘Other SIP Settings fields’:

session-timers=refuse

This helped me with my SIP carrier that was timing out at 14:29 seconds

-phoneguy

#4

31 to 32 seconds is typically firewall related. Check to ensure that you have the correct ports forwarded and that SIP ALG is off in your router.

#5

I just had a similar issue when I upgraded my test box.

This is how I resolved my issue:

My test box is behind a firewall and I needed to send my NAT address.
Normally: In SIP Settings–>PBX–>NAT I had set the IP I want my sip provider to see and then on the VoIP Trunk I checked the NAT box to apply that setting.
after upgrading: In SIP Settings–>PBX–>NAT There is a check box for “Use IP address in SDP” which is checked by default.

I believe these two things were conflicting in some way. As soon as I unchecked NAT on the VoIP trunk everything worked again and calls didn’t die after 30 sec.

#6

I have NAT and SDP checked and I don’t experience the problem. My provider requires registration.
Are you using registration or you have a fixed IP address ?

#7

[quote=“phoneguy797, post:3, topic:13805”]‘Other SIP Settings fields’:

session-timers=refuse[/quote]

Thanks guys for your help.

@phoneguy797
As per your suggestion I am trying to locate where to configure ‘session-timers=refuse’. I think the ‘Other SIP Settings fields’ has been replaced by SIP Settings>>PBX >> SIP Settings >> Session Timer, because I can not find it in Firmware v1.0.10.39. This is my first look at the UCM6012. I have not had a chance to see what the firmware settings looked like before this version.

Other than above mentioned suggestion which I have not yet been able to find where to add it, I have NOT been able to resolve this. Every Trunk in/out going call still terminates at about the 30 second mark.

#8

My apologies- I guess the ‘session-timers=refuse’ was a field in FreePBX, not in the Grandstream UCM

#9

The refuse is a setting that can be used within the Asterisk environment, but I do not know if that particular setting is valid within the UCM. In the UCM, the default is 1800 seconds (30 minutes). The timers are used to help alleviate orphan calls. This may happen when you have a call in progress and for whatever reason the connection is broken and no BYE is sent or received. The provider does not know this and may keep the port open, but not indefinitely if using timers as they will send a SIP message upon the timer expiration and expect a response back. I have not come across a provider who sets the timers this low, but I guess the possibility exists. In your case, using two providers and both suffering the same fate, I am still inclined to lean towards the router or the wrong IP in the SDP contact header. A more complete ethernet capture might reveal more.

#10

I have looked at a syslog as suggested by Marcin in another tread. I believe I have isolated the moment that the call terminates at 32 seconds. Now all I need is to figure out why???

‘No remote address on RTP instance ‘0x48247a04’ so dropping frame’
‘State changed from Completed to Terminated, event=TIMER’

[code]Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.601] DEBUG[13828] res_rtp_asterisk.c:3882: No remote address on RTP instance ‘0x48247a04’ so dropping frame

Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.622] DEBUG[13828] dsp.c:749: tone 1100, Ew=0.00E+00, Et=0.00E+00, s/n= nan

Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.622] DEBUG[13828] res_rtp_asterisk.c:3882: No remote address on RTP instance ‘0x48247a04’ so dropping frame

Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.635] DEBUG[06939] res_pjsip_log_forwarder.c:94: tsx0x4855dbec Timeout timer event

Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.635] DEBUG[06939] res_pjsip_log_forwarder.c:94: tsx0x4855dbec .State changed from Completed to Terminated, event=TIMER

Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.635] DEBUG[06939] res_pjsip_log_forwarder.c:94: tsx0x4855dbec Timeout timer event

Tue Feb 09 09:14:02 2016;172.16.240.3; <15>Feb 9 09:14:05 asterisk:
[20160209 09:14:05.635] DEBUG[06939] res_pjsip_log_forwarder.c:94: tsx0x4855dbec .State changed from Terminated to Destroyed, event=TIMER[/code]

#11

If one of the systems does not receive RTP packets, which is the voice stream, then it will typically wait for a bit and then if not received, then there is no need to continue the call and will subsequently end it.

As I have said, a capture will most likely show the issue, meaning the cause.

On the SIP Setting tab, under NAT, what do you have as the external host?

#12

I will say it again just in case it wasn’t checked yet:

In SIP Settings–>PBX–>NAT There is a check box for “Use IP address in SDP” which is checked by default.
If this is checked, try unchecking NAT on your trunk and see if that helps.

#13

[quote=“lpneblett, post:11, topic:13805”]As I have said, a capture will most likely show the issue, meaning the cause.

On the SIP Setting tab, under NAT, what do you have as the external host?[/quote]

@lpneblett

  1. I have made a capture. To me it is less informative than the syslog record. I have not been able to determine the reason from that output yet.

  2. I don’t have a static ip. I have tried serveral ways in populating the ‘external host’ setting. I have used the actual numerical ip, also DNS name using both Dynamic DNS services, no-ip and freedns.afraid.org. Checked and unchecked NAT in the Trunk setting. Any possible combination that I could think of without getting rid of that 32 second timeout on the Freephoneline Trunk when receiving an incoming call.

@lstutesman

[quote=“lstutesman, post:12, topic:13805”]In SIP Settings–>PBX–>NAT There is a check box for “Use IP address in SDP” which is checked by default.
If this is checked, try unchecking NAT on your trunk and see if that helps.[/quote]

Done that been there. No difference.

Thanks guys for your help. Much appreciated. I will continue looking.

#14

Actually the capture is highly detailed and will show all aspects associated to the call.

I am assuming your are behind a router and that:
a) SIP ALG is off and b) that the ports are forwarded for both SIP and RTP.

In the NAT IP host section, you will want your external public IP or your DDNS name. Using the DDNS name may be an issue as it could be that the provides you have chosen do not support their use. If they do support the use, ,then you may need to check and see if your account is set to register with a normal regsitration process instead of an IP process. Ensure that the IP can be found by pinging to your host name and compare against what you show to be your current public IP. Fi you are not using the standard SIP 5060 port, then put the name:XXXX where XXXX is the port being used.

In your current capture, you should download and install wireshark. Once installed, open the program and proceed to make a call that is currently failing. Once the call has failed, then stop the capture and use the telephony tab and then select Voip Calls. You will then be presented with the legs of the call. Select all and then do a show flow. What you now have is a visual presentaion of how the call was arranged between each leg (phone to UCM to Provider and back). You can then select the INVITE with in the flow and this will take you to the packet capture of that INVITE whereupon you can then explode each line to get the details of how each leg was being established or requested. The INVITE that you will want to see is the one from the UCM to the provider. Look for the line Session Initiation Protocol (INVITE) and then expand the section the section labeled Message Header and then Message Body. Expand all he lines in both areas and then you will see the details of how your system communicated with the provider. In the Message Header portion you will see the Contact, From and To headers and these should have your info in the Contact Fields. In the Message Body area, look for the Session Description Protocol area and then the Creator, which should reflect your info, and then the Connection Information area. This is where the UCm is telling the provider how to reach you and should reflect your DDNS or IP and then just below that will be the media description name and address. You will then see audio followed by numbers. The numbers represent the port that you want the provider to send the voice stream on and will be a port within the router port forwarding range.

Refer back to the flow and look for responses coming back from the provider. if no response, then either the firewall blocked it or the SDP info is incorrect and the provider is sending to an IP that is not yours. If there is a response, look for a 183 or similar as this will SDP info in which the provider is telling you the same info as you told them earlier. There may be more than one entry as it will depend on the authentication process. They may want a proxy authentication to your first Invite.

If needed, do call using the other provider that works. It may reveal some details.

#15

@lpneblett

Thanks for that mini tutorial on wireshark. I’ll have a look tomorrow as it getting late.

#16

Syslog + capture it almost perfect sense what is going. Sometime capture is needed on routers (when PBX do not get any reply).
Syslog -> it show why PBX react this way, capture show you real transmission.

Wireshark is easy,hard part is understand SIP protocol with all RFC :smiley:

Maybe GS could make stick post with syslog + packet capture simple explain. It will save time to explain this in many posts :slight_smile:

#17

I made some effort to find these settings that worked with Freephoneline. I thought I would share with others who might find it usefull. These are the minimum configuration settings need to make incoming/outgoing calls (that worked for me).

PBX >> Basic/Call Routes >> VoIP Trunks
Host Name: voip4.freephoneline.ca:6060 (Used this one as per Freephoneline, note use port#) Other domains might work just as well
Basic Settings:
NAT: NOT Checked
Username*: 15145551212
Password*: (Whatever)

Advanced Settings:
Codec Preference: PCMU & G.729 (Only codecs permitted)
Send PPI Header: Checked <<-- NOTE (This is the magic setting which made all the difference!!!) Uncheck it to see what happens.

PBX >> SIP Settings >> Misc
Register Timeout: 120 (As per Freephoneline FAQ)
Register Attempts: 0

PBX >> SIP Settings >> NAT
External Host: "DDNS Name:port# of UCM"
Use IP address in SDP: Checked

I added other settings which made no difference to add or remove the ability to make/receive outbound/inbound calls.

These settings populated or not add no value to above configuration.
Send PAI Header:
Outbound Proxy Support:
Enable Qualify:

Additional Notes:
Router Model: Asus RT-N16 (Firmware TomatoRAF)
No portforwarding on router
No sip ALG in router just in case

I beleive the differnces between these 2 syslogs describe what may have been happening. Domain and port numbers are different. In the failed attempt UCM tries 10 times to connect with Freephoneline and sends BYE to Freephone line (32 Second mark).

FAILED: Incoming always terminating at 32 seconds (Outgoing OK)
event: Event: Registry^M Privilege: system,all^M ChannelType: PJSIP^M Username: sip:15145551212@freephoneline.ca^M Domain: sip:freephoneline.ca^M Status: Registered^M ^M

Success: Incoming/Outgoing OK
event: Event: Registry^M Privilege: system,all^M ChannelType: PJSIP^M Username: sip:15145551212@voip4.freephoneline.ca:6060^M Domain: sip:voip4.freephoneline.ca:6060^M Status: Registered^M ^M

Failed:

[code]Conv.| Time | 162.213.111.21 | 172.16.XXX.79 |
| | | 172.16.XXX.50 | | 208.65.240.165 |
0 |13.005600| INVITE SDP (g711U te | | |SIP INVITE From: <sip:5145551212@208.65.240.142 To:<sip:15145551234@208.65.240.142 Call-ID:402C7567@208.72.120.66~o~o CSeq:806
| |(6060) ------------------> (5080) | | |
0 |13.029175| 100 Trying| | | |SIP Status 100 Trying
| |(6060) <------------------ (5080) | | |

1 |13.779100| | INVITE SDP (g711U g7 | |SIP INVITE From: <sip:5145551212@172.16.XXX.50 To:<sip:100@172.16.XXX.79 Call-ID:a71350b5-7d28-43de-b8ff-df89d26d55fb CSeq:9309
| | |(5080) ------------------> (5092) | |
1 |13.781000| | 100 Trying| | |SIP Status 100 Trying
| | |(5080) <------------------ (5092) | |
1 |13.804975| | 180 Ringing | |SIP Status 180 Ringing
| | |(5080) <------------------ (5092) | |

0 |13.821600| 183 Session Progress | | |SIP Status 183 Session Progress
| |(6060) <------------------ (5080) | | |
0 |13.835575| | RTP (g711U) | |RTP, 2345 packets. Duration: 4294953.461s SSRC: 0x2D072E3
| | |(12744) --------------------------------------> (57082) |
0 |13.915350| | RTP (g711U) | |RTP, 2344 packets. Duration: 4294953.381s SSRC: 0x64D2551C
| | |(12744) <-------------------------------------- (57082) |

1 |28.645250| | 200 OK SDP (g711U g7 | |SIP Status 200 OK
| | |(5080) <------------------ (5092) | |
1 |28.660275| | ACK | | |SIP Request INVITE ACK 200 CSeq:9309
| | |(5080) ------------------> (5092) | |

0 |28.673275| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |

1 |28.714650| | RTP (g711U) | |RTP, 1605 packets. Duration: 4294938.582s SSRC: 0x6168965D
| | |(12310) ------------------> (5008) | |
1 |28.718025| | RTP (g711U) | |RTP, 1604 packets. Duration: 4294938.578s SSRC: 0x4A9A623C
| | |(12310) <------------------ (5008) | |

0 |29.176375| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |30.175325| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |32.175975| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |36.176425| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |40.177000| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |44.178950| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |48.177875| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |52.179275| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |56.179850| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |60.180375| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |
0 |60.677075| BYE | | | |SIP Request BYE CSeq:29607
| |(6060) <------------------ (5080) | | |
0 |60.765100| 200 OK | | | |SIP Status 200 OK
| |(6060) ------------------> (5080) | | |

1 |60.779300| | BYE | | |SIP Request BYE CSeq:9310
| | |(5080) ------------------> (5092) | |
1 |60.780850| | 200 OK | | |SIP Status 200 OK
| | |(5080) <------------------ (5092) | [/code]

Success:

[code]Conv.| Time | 162.213.111.21 | 172.16.XXX.79 |
| | | 172.16.XXX.50 | | 208.65.240.142 |
0 |15.032675| INVITE SDP (g711U te | | |SIP INVITE From: <sip:5145551212@208.65.240.142 To:<sip:15145551234@208.65.240.142 Call-ID:3EE9C7CE@208.72.120.66~o CSeq:161
| |(6060) ------------------> (5080) | | |
0 |15.050450| 100 Trying| | | |SIP Status 100 Trying
| |(6060) <------------------ (5080) | | |

1 |15.736675| | INVITE SDP (g711U g7 | |SIP INVITE From: <sip:5145551212@172.16.XXX.50 To:<sip:100@172.16.XXX.79 Call-ID:6b5c2431-860d-4e40-955e-18d5b1b9f0f8 CSeq:13273
| | |(5080) ------------------> (5092) | |
1 |15.738700| | 100 Trying| | |SIP Status 100 Trying
| | |(5080) <------------------ (5092) | |
1 |15.763725| | 180 Ringing | |SIP Status 180 Ringing
| | |(5080) <------------------ (5092) | |

0 |15.783200| 183 Session Progress | | |SIP Status 183 Session Progress
| |(6060) <------------------ (5080) | | |
0 |15.800550| | RTP (g711U) | |RTP, 3392 packets. Duration: 4294951.496s SSRC: 0x2C6A362D
| | |(12234) --------------------------------------> (39462) |
0 |15.908050| | RTP (g711U) | |RTP, 3393 packets. Duration: 4294951.388s SSRC: 0x7E6A1E0A
| | |(12234) <-------------------------------------- (39462) |

1 |30.596925| | 200 OK SDP (g711U g7 | |SIP Status 200 OK
| | |(5080) <------------------ (5092) | |
1 |30.607500| | ACK | | |SIP Request INVITE ACK 200 CSeq:13273
| | |(5080) ------------------> (5092) | |

0 |30.622475| 200 OK SDP (g711U te | | |SIP Status 200 OK
| |(6060) <------------------ (5080) | | |

1 |30.659700| | RTP (g711U) | |RTP, 2653 packets. Duration: 4294936.637s SSRC: 0x4563A87F
| | |(11776) ------------------> (5008) | |

0 |30.673825| ACK | | | |SIP Request INVITE ACK 200 CSeq:161
| |(6060) ------------------> (5080) | | |

1 |30.692600| | RTP (g711U) | |RTP, 2653 packets. Duration: 4294936.604s SSRC: 0x78CAEEE
| | |(11776) <------------------ (5008) | |
1 |83.689325| | BYE | | |SIP Request BYE CSeq:13274
| | |(5080) <------------------ (5092) | |
1 |83.695375| | 200 OK | | |SIP Status 200 OK
| | |(5080) ------------------> (5092) | |

0 |83.708150| BYE | | | |SIP Request BYE CSeq:23745
| |(6060) <------------------ (5080) | | |
0 |83.748750| 200 OK | | | |SIP Status 200 OK
| |(6060) ------------------> (5080) | | |
[/code]

#18

I had this issue with a 6102 and Flowroute - with a Dynamic IP.
Unchecked NAT under the Trunk settings fixed it.

#19

I just wanted to chime in with my personal experience with this call drops after 30 seconds issue.

After running a packet capture I found that our 6104 was getting flooded with bogus requests from a unrecognized ip. It was so bad that the CPU usage was maxed out to 100% constantly. 8 out of 10 calls were terminating at exactly 30 seconds. (give or take 1 second)

After setting up a firewall rule to drop all traffic on port 5080 that does not originate from our voip provider, the cpu dropped to 15-20% usage and I have not had a call drop at 30 seconds since. My guess is that the overloading traffic caused our pbx to miss the acknowledgement and then terminated the call.

Hopefully this helps someone else who is struggling with the same problem!

#20

Luke’s solution in Reply #4 above solved the problem for me on a brand new UCM6202. Mine was also giving intermittent one-way speech. It’s odd because the config was from another working system.