SIP disconnects using dlink DPH-140S

Asterisk Asterisk Support
1

I’m getting disconnects on outbound numbers that require I enter in multiple DTMF entries. This is the log of when the call disconnects:

[Oct 31 20:17:53] WARNING[1079]: chan_sip.c:2303 retrans_pkt: Maximum retries exceeded on transmission CALL_ID22_00179AACFA5C_T1209263556@192.168.0.197 for seqno 337453400 (Critical Response) [Oct 31 20:17:53] WARNING[1079]: chan_sip.c:2330 retrans_pkt: Hanging up call CALL_ID22_00179AACFA5C_T1209263556@192.168.0.197 - no reply to our critical packet. -- Hungup 'Zap/11-1' == Spawn extension (from-pstn, 18004284322, 2) exited non-zero on 'SIP/adam-0880e000'

The confusing part to me is the SIP debug info. Here is a snippet:

[code]— (10 headers 0 lines) —
Handling message for SAPI/TEI=0/0
Retransmitting #6 (no NAT) to 192.168.0.197:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.197:5060;branch=z9hG4bK_00179AACFA5C_T3A95544A;received=192.168.0.197
From: “Anonymous” sip:adam@xxx.xxx.xxx.xxx:5060;tag=00179AACFA5C_T356113001
To: sip:xxxxxxxxx@xxx.xxx.xxx.xxx:5060;tag=as476fc785
Call-ID: CALL_ID22_00179AACFA5C_T1209263556@192.168.0.197
CSeq: 337453400 INVITE
User-Agent: Asterisk PBX SVN-trunk-r84726M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: sip:1xxxxxxxxxx@192.168.0.1
Content-Type: application/sdp
Content-Length: 280

v=0
o=root 145910542 145910543 IN IP4 192.168.0.1
s=Asterisk PBX SVN-trunk-r84726M
c=IN IP4 192.168.0.1
t=0 0
m=audio 12514 RTP/AVP 18 4
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

call*CLI>
<— SIP read from 192.168.0.197:5060 —>
ACK sip:18004284322@192.168.0.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.197:5060;branch=z9hG4bK_00179AACFA5C_T476F556D
From: “Anonymous” sip:adam@xxx.xxx.xxx.xxx:5060;tag=00179AACFA5C_T356113001
To: sip:xxxxxxxxx@xxx.xxx.xxx.xxx:5060;tag=as476fc785
Call-ID: CALL_ID22_00179AACFA5C_T1209263556@192.168.0.197
CSeq: 337453400 ACK
User-Agent: DPH-14001.01.08
Contact: sip:adam@192.168.0.197:5060
Max-Forwards: 70
Content-Length: 0[/code]

I’m assuming the "Critical Packet in question is the invite sent, and the confusing part is that the phone replies with an ACK, but * appears to ignore the ACK and continues sending invites.

We use two types of phones: the dlink DPH-140S and the SNOM 360. The call works perfectly with the SNOM. Every single time it fails with the dlink. Does anyone have insight into this behavior?

2

The router is dropping packets. It’s anyone’s guess as to why. See if you have any firewall settings enabled on the router.

3

There is no router involved except for the asterisk server which is dual homed. The IP phones are on a segregated switch/192.168 subnet. The network information I saw showed 0% packet loss. Can you tell me why you believe there is packet loss when the ACK gets back to *, yet * continues to send invites that are incremented.

One would think if the ACK was acknowledged then things would be fine again until some more packets were lost and another invite was sent at which point the Critical Packet increment would be reset. That isn’t the behavior here.

4

The asterisk server is connected directly to the public internet (the server has a public IP) ?

5

Yes, it has a public IP, but in this scenario it isn’t important as the internal packets never hit the internet as it’s translated into PRI immediately. This is not a dropping packets problem. There is no router or firewall or nat involved. There’s either something wrong with the packets the phone sends or in how * handles them. The Snom phone work under the same conditions.

6

Ok. Based on your error packets are being dropped. I would look at your network set up, switches being used etc., cables etc. I have seen in the past that all what was needed was the switch needed to be rebooted (who would of thought of that). Try rebooting all switches, plunging the server in to a switch and connecting that phone to the same switch right near the server and see what happens. A lot of times the issue is so simple that we over look it.