UCM6202 - GPX2130 on NAT with One-way Audio


#21

I’ve found that my remote phones are behind a port restricted cone NAT. That means that only the port that comes in, can go out?


#22

Just catch packets and see what is happening there. It will be much easier to determine correct resolution.


#23

This is the INVITE my external phone sends:

Via: SIP/2.0/UDP EXT WAN IP:5061;branch=z9hG4bK1546974205;rport
From: <sip:50@UCM WAN IP:51064>;tag=1438114953
To: <sip:18@UCM WAN IP:51064>
Call-ID: 827334678-5061-12@II.JI.BBD.BIA
CSeq: 111 INVITE
Contact: <sip:50@EXT WAN IP:5061>
Authorization: Digest username=“50”, realm=“disatel_FARMAVET”, nonce=“1542355789/adc535f86740357aa88b77821703842e”, uri=“sip:18@UCM WAN IP:51064”, response=“40b408c96b016fa8d772d43deff65679”, algorithm=md5, cnonce=“06843656”, opaque=“0dc154df070906a3”, qop=auth, nc=00000001
Max-Forwards: 70
User-Agent: Grandstream GXP2130 1.0.9.69
Privacy: none
P-Preferred-Identity: <sip:50@UCM WAN IP:51064>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length: 434

This is the OK response that comes from my UCM

Via: SIP/2.0/UDP EXT WAN IP:5061;rport=5061;received=EXT WAN IP;branch=z9hG4bK1546974205
Call-ID: 827334678-5061-12@II.JI.BBD.BIA
From: <sip:50@UCM WAN IP>;tag=1438114953
To: <sip:18@UCM WAN IP>;tag=29e26795-364c-4d88-92fd-f42857f124f8
CSeq: 111 INVITE
Server: Grandstream UCM6202V1.5A 1.0.18.12
Allow: OPTIONS, INFO, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Contact: <sip:50@UCM LOCAL IP:51064>
Supported: 100rel, timer, replaces, norefersub
X-UCM-AudioRecord: *3
X-UCM-CallPark: #72
Content-Type: application/sdp
Content-Length: 304

And this is one of the UDP packets the phone recieves (incoming audio)

Internet Protocol Version 4, Src: UCM WAN IP, Dst: PHONE LOCAL IP
0100 … = Version: 4
… 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 200
Identification: 0x0000 (0)
Flags: 0x4000, Don’t fragment
Time to live: 57
Protocol: UDP (17)
Header checksum: 0xc4fc [validation disabled]
[Header checksum status: Unverified]
Source: UCM WAN IP
Destination: PHONE LOCAL IP
User Datagram Protocol, Src Port: 13554, Dst Port: 10002


#24

Again, with SDP :slight_smile:
Hard to talk without Sdp.


#25

But I have SDP active on PBX Settings > SIP Settings > NAT, and on packet capture, wireshark detects the invite as SIP/SDP protocol, not just SIP, also packet captures states

Content-Type: application/sdp

what am I missing?


#26

Invite have SDP section. You do not add this here, it contains data about codec, port and UCM IP.

image


#27

Oh I see… I only posted the header, not the body. Here it is

Internet Protocol Version 4, Src: PHONE LOCAL IP, Dst: UCM WAN IP
User Datagram Protocol, Src Port: 51064, Dst Port: 51064
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:18@UCM WAN IP:51064 SIP/2.0
Message Header
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 50 8000 8000 IN IP4 PHONE WAN IP
Owner Username: 50
Session ID: 8000
Session Version: 8000
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: PHONE WAN IP
Session Name (s): SIP Call
Connection Information ©: IN IP4 PHONE WAN IP
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: PHONE WAN IP
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 10002 RTP/AVP 0 8 4 18 9 97 2 123 101
Media Type: audio
Media Port: 10002
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.723
Media Format: ITU-T G.729
Media Format: ITU-T G.722
Media Format: DynamicRTP-Type-97
Media Format: ITU-T G.721
Media Format: DynamicRTP-Type-123
Media Format: DynamicRTP-Type-101
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:4 G723/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:9 G722/8000
Media Attribute (a): rtpmap:97 iLBC/8000
Media Attribute (a): fmtp:97 mode=30
Media Attribute (a): rtpmap:2 G726-32/8000
Media Attribute (a): rtpmap:123 opus/48000/2
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15


#28

UCM - router. We need outgoing packet from UCM and receiving back.
Best full communication. You can share full in private if you do not want put it here. If @lpneblett is correct (i agree with him) there will be no 200 ACK after 183 ring (183 allow talk). Other problem can be wrong SDP (1 one audio).

Probably it should like this:

And problem is lack 200OK (SDP)


#29

Ok, I can see on my captures that UCM sends 100 trying and 180 ringing but there’s no 183 session progress


#30

I have had the same issue. The problem might be at the ISP? - am not really sure. I solved doing a site to site VPN. Basicaly in my opinion there is a problem on the routing.


#31

@Aleck_VoIP
Ok what you have after 180 ?
180 is pure ring, so no talk there.
What is next ?

enkli: it really depend. It can be router or ISP or bad config in UCM.


#32

After the 180 I get a SIP OK 200
then SIP REQUEST INVITE ACK from Phone to UCM
And then I start to get the stream from my UCM to Phone, but not labeled as RTP but as UDP instead.

Question: My LAN network on my UCM side uses the same as my remote network. Meaning both use 192.168.1.0/24 network… would this cause an issue?


#33

He sent me the Pcap and the issue is that the UCM in its 200OK to the INVITE is telling the remote phone to use the UCM’s private IP of 192.168.1.100 in the Contact and the Connection header. As a result, the UCM never sees the ACK to the 200OK and TimerB fires as the 32 second mark and BYEs the call and audio, also being told to go to the 192.168.1.100 address, is never seen (heard).

He has set the local LAN segment in the UCM and has indicated that NAT is enabled on the extension and that can direct media is disabled. SIP ALG does not enter into the mix as the pcap is direct from the UCM and the 192.168.1.100 is in the headers as mentioned.

I can only think that perhaps an “apply” was not set after the save when he changed the NAT setting in the extension of the UCM. Originally it was reported not to have been set.


#34

Fixed or not ?


#35

Sorry, out of the office today. Will try and update tomorrow.

Thanks everyone for your help


#36

My guess is yes, as we found and corrected a setting where one of the settings was cut-off in a posted screen shot. but fully sent to me with one of the pcaps.

In any event only Aleck will know for sure.


#37

Seen this issue before when i was trying to set up phones on 2 LANs, turned out to be the SIP packet from the UCM had the wrong IP address to return to itself.

Phone calls in ok, receives a SIP packet from the UCM with the WRONG IP address so the phone uses the wrong IP address for voice data…

Result was sound TO the phone, but nothing from the phone to the UCM. The fix was the NAT table entries AND which order to add them, i had a whole thread on here about it, almost lost a client over it.


#38

Apologies, was out for a week, has this been resolved?


#39

I’m sorry but I won’t be able to test this until next week


#40

Hi everyone,

Sorry for the late response on this topic.

Issue is resolved! Thanks a lot to everyone, special thanks to @lpneblett for taking the time on the pcaps and his insight.

The final issue was that I had included the WAN ip inside the “local networks” on the NAT config inside the UCM by recomendation of my VoIP provider. Obviusly they were wrong.

Also in my case, the use of STUN is required, once this settings were correctly configured, outbound or inbound calls, work as normal with sound in both sides.

Thanks everyone!