Disconnects after 20 seconds


#1

I have a new setup UCM6304A with 1.0.17.11 firmware and GXP 2135 phones with the latest firmware. It runs on Ubiquiti network on a separate VLAN. SIP and GRE are off. UDP timeout at 660 seconds.

All calls between extensions disconnect at 20 seconds into the call and so do outgoing calls. All incoming calls are fine, also transfer it OK.

Does anyone have an idea what is missing here?


#2

Firewall / routing issue for RTP packets (UDP 10000-20000)


#3

Did you completely populate the PBX Settings, SIP Settings, and NAT page with the external host or IP, check the SDP box, and then fill in the local Lans below?

Does the trunk have NAT checked and if so, disable it?
Does the router and the modem both have SIP ALG disabled?

There may be other settings as well but this is a start.


#4

I don’t have control over the network itself and rely on the IT department. I put this question to them but at the same time changed the range to 12000-16000. That didn’t seem to help.


#5

I checked all these settings and they are all set proper. For the SIP ALG, I asked the IT to make sure to disabled it, which they confirmed to have done.


#6

Then do a packet capture of an internal call between extensions and post.


#7

On the PBX or on the phone or both?


#8

Do both as long as there is the opportunity to do so. Do on both at the same time so we can see what the call looks like from both ends.


#9

captures (4).tar (217.5 KB)
captures (3).tar (218 KB)
capture-C074AD9BCD2C (1).tar (1.0 MB)

Here are the traces for both phones and the PBX


#10

I tested with another PBX which is on firmware 1.0.15.13 on the same network. That works fine. Is there any place that I can still download that version for UCM6304A. I don’t see it anywhere posted anymore.


#11

It looks like ext59 (2135) was calling 58. The call into the UCM is fine. it breaks down when the Invite from the UCM to 58 is sent -

The MTU is being exceeded and the packet is being fragmented as there is too much data in same.

In the UCM you need to eliminate all the codecs other than those needed. As you show to be in Canada, this is PCMu and g729. As a point of practice, you would be well advised to get into the web interface of the phones (in the tests) and then make all of the codecs the same with the exception of the last one, which will also be g729.

As the phones are local, you can also get into the UCM and in the media section of the extensions, enable can direct media. This will allow the phones to handle the audio independently of the UCM.

Start with the above and try it on your test extensions and see.


#12

I would remove any codecs that are not supported in your devices and leave the main codecs being what would be used.

eg in the following order on all sip devices - UCM, Telephones etc

  • G722
  • G711 u
  • G729

That way, only those listed would be used anywhere on the network or communication path. G722 would be used between handset extensions, G711 would be the fall back for every call and G729 when the carrier forces the telephone call down to a compressed audio codec.


#13

I have brought all the codes back to PCMU and g729 on the PBX extensions and in the two test phones. I tested again; still disconnecting after 20 seconds into the call. See the attached files. The MTU does not seem to be exceeded anymore. After the traces were taken, I allowed Direct media. That also didn’t help.captures (6).tar (245 KB)
captures (5).tar (247 KB)
capture-C074AD9BCD2C (3).tar (1.2 MB)


#14

I tried that just now as well. I wouldn’t solve it.


#15

reboot network switch, handset and fritzbox… redo test and verify.


#16

OK, the can direct media has to be set on both extensions in the UCM.

I am going to take a wild couple of guesses -

  1. When I listen to the audio, I hear one-way audio. In the audio stream, I see what might be an slight echo of some type. I hear you saying “hello”, but I do not really hear anything in response, but looking at the graph, there is something, but it always follows you and in a much lesser amplitude -

  2. When looking at the flow, it indicates that the call is being terminated by the PBX (look for the circled BYEs) -

The reason code is 16, which is a normal clearing.

This makes me wonder what happens when the same call is made, if it is answered using the speaker phone function rather than the handset? If that works, then check to see if the handset cord is plugged into the handset port or if in the headset port.

Also, look at the UCM, PBX Settings, SIP Settings and the ToS tab, what is the RTP timeout set to?

Additionally, the UCM is on a somewhat older firmware. You might tale a look at the release notes and then consider if updating is worthwhile.


#17

I had to leave the site but to the PBX and some phones back to the office.

I didn’t set Direct media on the phones. Will do so with the next test.

I have been testing by myself, that why there is only one way audio. Since the phones are sitting almost next to each other, you do hear the background noise.

I figured that the PBX initiates the termination, but why. RTP settings on the PBX are the default values, which I always used without any issue.

The first traces were with the latest firmware on the PBX 1.0.17.11. After that I downgrade to 1.0.15.13.

I probably with continue tomorrow.

Thank you lpneblett and scottsip for your input. Much appreciated!


#18

I’m still not sure why it didn’t work before, however, I reset the PBX and started over. Everything is now working as expected. I wonder if the conversion from version 15 to 17 somehow caused it. Thanks again for the input from lpneblett and scottsip!