UCM 6116 firmware 1.0.18.12 DISASTER, calls dropping, need help from grandstream


#21

Under maintenance there is a packet capture feature. You should be able to use that.

Maintenance > Network Troubleshooting > Ethernet Capture


#22

Change the local network address to 192.168.1.1 (or whatever the gateway is,) instead of 192.168.1.0

That should do it.

Here’s a snippet from my handwritten notes two or three system installs ago:

image


#23

Mike - the LAN segment of .0 with the /24 means all addresses within the range. It makes no difference, it covers the entire segment. If he had /32 then it would only point to a single address.


#24

Turn off NAT on trunk.
Also add this:


#25

I stand corrected, thanks. Not sure what fixed my problem on that install - it seemed like the problem went away when I changed it from .0 to .1.


#26

A packet capture is needed to understand how the messaging is being formulated and returned to the various devices and providers.

The areas of interest are the contact in the message body and the connect in the SDP section of the INVITE. When you initiate a call using the Callcentric trunk the INVITE should show the public IP of the UCM in both sections (message header and message body) as well as port 5060 source (meesage header) and a valid port in the SDP section (message body) that falls within your established RTP range.

image

While the above shows a capture snippet of a phone to UCM, the format is the same, only yours should show the public IP and ports used in your case rather than the private IP as shown here for a phone.

You will need to expand the headers to get to the relevant details. Following is the SDP section:

Again, yours should show the public IP and the port used (10000-20000?) for your RTP.

As you can only see what the UCM is sending, it may not be what the provider is seeing, If your router is rewriting any of the headers, as is often the case when a SIP ALG is enabled, it will look fine to you, but the provider will see and may respond to what they see in the messaging.

So, for example, if the UCM is sending a SIP message from 88.88.88.88 and the router rewrites the packet to show a private IP instead, The provider will return some of their responses to the private, which of course, the UCM will never see and as a result the t1 timer will expire and the call will drop.

So, if the packets being sent look fine, call the provider and ask them what they see. BTW, when looking at the capture for an INVITE sent to the provider, the source will be the private IP of the UCM as it is indeed the source, but it is the Contact and Connect headers that are key.

I do not suggest a DMZ. This effectively exposes the UCM to the Internet for all ports and only invites other issues as you try and protect the UCM from scanners/hackers. If the router is unable to do the job, get one that does. dd/wrt, tomato and the others are generally used on routers that are more in the residential class routers and may not have the needed functionality needed to handle and protect VoIP. I have a couple running dd/wrt and they are OK, but there are variations of firmware and not all are equal.

On your PC download and install Wireshark (wiresharl.org). Run the capture while making an outbound call and the stop the capture and download same when the call is complete. Open with Wireshark and look for the telephony tab at the top and select VoIP calls. Look for the lines with the call from the phone to the UCM and then from the UCM to Callcentric. Once highlighted, then click on flow. This will show the flow of messages between the devices involved in the call. Look at the INVITE from the UCM to Callcentric and highlight it and then go to the page where the details of that message are and expand the headers to see what I have posted above.

If needed, send me the pcap file via PM, but hopefully once you play around with it some, you will get the hang of it.


#27

Thanks, I definitely need more time to drill into this problem, for now I had to forward the callcentric number over to the cablevision number to keep everybody’s sanity.

Meanwhile this is a sanitized log callcentric sent me. It’s a call from my cell phone “5165555555” to the callcentric number “7185555555”. The section about 2/3 of the way down starting with the line v=0 shows the private ip address and the public ip address, is that the problem area?

Callcentric > UCM 

ACK sip:bf310bf09a181fe0abec2e8d4013ffca@<public IP of UCM>:5060 SIP/2.0 
v: SIP/2.0/UDP 204.11.192.169:5080;branch=z9hG4bK-e68a91d61b088e89b3dacb96f2e27b74 
f: "caller id string" <sip:15165555555@66.193.xx.xx>;tag=3748614816-171834 
t: <sip:17185555555@ss.callcentric.com>;tag=d37e1e7e-390d-470a-a9cc-5d319295d0e6 
i: 16799286-3748614816-171801@msw1.telengy.net 
CSeq: 1 ACK 
Max-Forwards: 13 
m: <sip:3a80de1e987eda6e31ae6694e684aed1@204.11.192.169:5080;transport=udp> 
l: 0 

UCM > Callcentric 

SIP/2.0 200 OK 
Via: SIP/2.0/UDP 204.11.192.169:5080;received=204.11.192.169;branch=z9hG4bK-e081fefc0dff099205e38d01571791f2 
Call-ID: 16799286-3748614816-171801@msw1.telengy.net 
From: "caller id string" <sip:15165555555@66.193.xx.xx>;tag=3748614816-171834 
To: <sip:17185555555@ss.callcentric.com>;tag=d37e1e7e-390d-470a-a9cc-5d319295d0e6 
CSeq: 1 INVITE 
Server: Grandstream UCM6116V1.5A 1.0.18.12 
Allow: OPTIONS, INFO, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER 
Contact: <sip:bf310bf09a181fe0abec2e8d4013ffca@<public IP of UCM>:5060> 
Supported: 100rel, timer, replaces, norefersub 
Content-Type: application/sdp 
Content-Length: 280 

v=0 
o=- 623577 865732 IN IP4 <private IP of UCM>
s=Asterisk 
c=IN IP4 <public IP of UCM> 
t=0 0 
m=audio 17588 RTP/AVP 0 8 18 101 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:18 G729/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-16 
a=ptime:20 
a=maxptime:150 
a=sendrecv 

UCM > Callcentric 

BYE sip:bf310bf09a181fe0abec2e8d4013ffca@204.11.192.169:5080;transport=udp SIP/2.0 
Via: SIP/2.0/UDP <public IP of UCM>:5060;rport;branch=z9hG4bKPjedce5690-c1c0-4edb-9bca-235f29d4e8ec 
From: <sip:17185555555@ss.callcentric.com>;tag=d37e1e7e-390d-470a-a9cc-5d319295d0e6 
To: "caller id string" <sip:15165555555@66.193.xx.xx>;tag=3748614816-171834 
Call-ID: 16799286-3748614816-171801@msw1.telengy.net 
CSeq: 6470 BYE 
Max-Forwards: 70 
User-Agent: Grandstream UCM6116V1.5A 1.0.18.12 
Content-Length: 0

#28

No. However, I do not know the entire scenario. I see the BYE from the UCM, so am unsure if the call was completed and ended normally or if it represented the issue.

From what you show, so far, all seems correct, but the UCM capture is missing.


#29

I repeat:
Turn off NAT on trunk.

You have set NAT section then you must unmark this on trunk. Then UCM will fill correctly IP in SDP.
Also if you turn on rtp keep then UCM will sent RTP packet that fix problem with SDP for external system.


#30

NAT is turned off in trunk. RTP keepalive is set to 5. These are the trunk, NAT and ToS settings as of now:


#31

In SDP you still see local IP ?


#32

Could it be something like SIP ALG that might rewrite packets?


#33

Ideally, what will help here is a full, complete, and private copy of a packet capture at the network level showing all SIP traffic to/from the external IP and to/from the UCM IP. This can then be combined into a SIP ladder and looked at to see what’s in the headers versus SDP.

The next best option is a packet capture as seen from the UCM.

Is there anyway you can create one of these? And I know you won’t like this, but leaving the IP addresses in there, unmasked, is the best way to provide that information. You’re welcome to contact me, or I’m sure some of the other people that have tried to help here, privately and send a ZIP file as a PM.


#34

I appreciate all the offers of help, sincerely & greatly! I’m going to set up a UCM capture and also, dig out an old 10 mpbs Netgear hub and set up a wireshark capture on-site but my schedule won’t permit this for a couple of weeks. In the meantime forwarding the number is the best stopgap I can come up with. We’re losing some channels in the interim but a busy signal is not as bad as dropping calls constantly. I’m also going to try swapping the router. The DD-WRT box currently in use does not have a SIP ALG setting but maybe something under the hood is causing the problem. You guys are the best.


#35

Oh stop, or I’ll cry.


#36

WRT routers should have SIP alg settings.
I had one model that I had to find the hidden page to turn it off.

Even then the router gave me NAT issues.
What is the exact model of the firewall you are using and which do you plan to swap in?


#37

Current router is:
Router Name: DD-WRT
Router Model: D-Link DIR-615-E1
Firmware Version: DD-WRT v24-sp2 (08/07/10) std - build 14896

It’s also used for guest wifi.

For a replacement I have an Asus RT-N10P laying around I was going to try. Maybe a pfSense box.


#38

Just catch packets on UCM. We will see reason for drop. But it must be full not few selected packets.


#39

I had a chance to look at this further. I tried downgrading to 1.0.17.16 and 1.0.16.20 to verify this wasn’t a version-specific problem (it isn’t). So I did a packet capture, made an incoming call through the callcentric trunk which dropped at 32 seconds, and ended the capture. Anyone want to take a look at it?


#40

32 seconds is usually when the t1 timer expires or the port in the router closes. Fundamentally a NAT issue. The t1 timer is used to allow a responding device enough time for an ack to be sent back and seen by the originating device thereby fully establishing the session.
If you want to PM the capture, I will take a look.