Outgoing calls are disconnected after 15:07 minutes


#1

Hey folks,

we recently bought a UCM6202 to replace our ISDN PBX. While testing the PBX before using it in real use we discovered that outgoing calls are disconnected after 15:07 minutes - after multiple attempts this time can be as low as 7:38 minutes.

We’ve already searched the forums and tried solutions but nothing seems to change.

What we did so far: changed ports(so we don’t collide with our router), forwarded ports through firewall to pbx, set external fixed ip-address, checked SDP-box, set RTP keep-alive from 0 to 20.

Our provider is Deutsche Telekom (DTAG), we use an AVM FritzBox 7490 as our primary internet gateway (which also handles calls atm) and an Alix Board with OpenWRT as our primary router.

The problem happens with both DECT and desk phones. We use DP722 DECT phones with Firmware 1.0.11.4 and our DECT gateway is DP752 with Firmware 1.0.11.4. Our desk phones are GXP2135 with Firmware 1.0.11.3. Our UCM6202 uses Firmware 1.0.20.17.

We hope you can help us fixing our problem.


#2

Get rid of the Fritzbox, put in a serious router, I 99% believe it solves the problem.

other thing look for RTP timeout on UCM and try to downgrade UCM to version 1.0.19.29


#3

Hey damiano70,

thanks for the fast reply.
Can you tell us more about the problem with the Fritzbox here? Are there any known bugs caused by it?

What has changed with the current UCM-Update? We really would like to use the Announcement feature from it - since we have to tell our callers about our data policy but we don’t want to include it in the IVR.

The RTP timeout under PBX -> Sip - ToS is currently set to 90sec. Are there any known good values?


#4

First of all you can’t put a voip server behind another voip server (Fritzbox).
The rest comes on its own.


#5

Catch packets, then we can see which side close and why.


#6

Hey Marcin,

so you want a full Ethernet-Capture under Network Troubleshooting?


#7

Yes. It is fastest way to determine what is a problem.


#8

Hey guys,

sorry for coming back that late.
After looking over the captured packets we’ve noticed that the SIP-Server did send the Update to port 5070 (we wanted it like that) but the PBX didn’t replied to it. Furthermore the initial connection was established with port 5060 - which was weird.

It seems like we misunderstood what PBX-Settings/SIP-Settings/NAT is doing. When only changing the port there this weird behavior occurred with no way of manipulating it with our firewall - even when remapping the external 5070 port to 5060 it was still talking to 5070 at the PBX. After changing it temporarily to 5060 our problem was gone. If we want to use 5070 we also need to change PBX-Settings/SIP-Settings/General to Port 5070 - otherwise it won’t work.

Maybe someone could explain how it should work when only using 5070 under NAT.


#9

one speech is the SIP listening port and another the SIP registering port


#10

Well, you can’t really use port remapping.

When using SIP, each device or side formulates their respective messaging by understanding where they reside in a network and then comparing the received messaging to understand how to respond to the requesting device.

When sending a message, there are two critical headers and these are the “Contact” and the “Connection” headers. The contact header tells the other end to what IP and port it should use when responding for SIP messages and the connection header does the same thing, but for the RTP stream. With a PBX the connect and connection header will usually be the same, but when messaging to a provider, the contact and connect headers may not be the same IP usually due teh volume of calls and the need to be able to let a different server handle the media (RTP).

So, in the UCM you tell it what its public IP is and then you define the local network LAN. When the UCM sees a message from the LAN it will respond and tell the LAN device to use the UCM’S private IP and if the UCM sees a message from something other than the LAN then it will use the gateway to tell the non-local device to use the UCM’s public IP.

As far as I am aware, if you want to use something other than the default 5060, then you should set both to the desired port. It is my understanding, and I could be wrong as the manual does not discuss both settings, is that the NAT port setting is used formulate the port to be used in the external messaging. The general setting is used to tell the UCM what port to bind the SIP stack to. I am of the impression that the UCM is not capable of binding the SIP stack for a given transport to more than one port. So, it sounds like you were telling the external world to use port 5070 and when the responses came back on 5070, the UCM was bound to 5060. When you tried to re-map 5070 to 5060, the messaging was still set to 5070 and I am guessing that even if it saw the message physically arriving on 5060, the contact header was incorrect and perhaps this caused the issue. I am uncertain about this not seeing it first hand or seeing a pcap, but hey, it’s a guess.

You can’t really remap as the device will expect to see the response on the port in the connect header when it sent the initial query.


#11

Hey lpneblett,

thanks for that explanation. The “Sent by port” was 5070 in the message-header which resulted in this behavior.

About the manual: Yeah that’s a real problem here. The manual also missing the description of UDP as a whole for this setting. So it’s just a guessing game what Grandstream is doing here.


#12

NAT simply change port in packets that go via NAT. So you need forward thi ports to UCM original port (5060).
RTP is 10000-20000 by default and this much you need forward too (or you can make smaller range).
Gs is doing it correctly in latest fw, but NAT on trunk must be off.

Main problem with GS is taht they use same NAME even if function do different.
NAT in general is for changing outgoing packets (to inform receiver when he need reply), but on trunk it DETECT nat.