Asterisk and ADTRAN 7100 loses audio after hold or transfer

Asterisk Asterisk Support
1

I am re-posting this under a new topic because I feel like I miss-represented it as an asterisk 11 only problem, but it seems to be independent of the version. The fact that there aren’t a bunch of “me too’s”, makes me think that this is likely a configuration issue on my part, but I am stumped as to what it might be. I am fairly sure that this isn’t an ADTRAN issue, but the asterisk side not switching audio to the agreed ports.

I have a SIP trunk going from an Asterisk (verison 11, but this happened with version 1.6 also) installation to an ADTRAN 7100. Everything works if you don’t place someone on hold or transfer the call. The re-invites lose audio both directions. I also had this problem with version 1.6 so I upgraded to the latest version (11.0.0).

This is on a local network (10.132.0.0/16). No routers or NAT between them. The phones connected to the 7100 are connected to their downstream ports (1-24).
The upstream router port is 10.132.10.14.
The 7100 SIP media gateway is at 10.132.21.254/16
The Asterisk Linux Server is on 10.132.6.15

As I see the problem: The initial call is as expected. The placing on hold is also as expected, when the call is taken off of hold, the call flow all looks right, but asterisk never starts sending RTP on the invited and 200 OK’d IP/Port. Looking through the wireshark packets, there is an RTP flow, but it is still pointing at the stream established in the HOLD invite at 18.243 seconds. Asterisk had already received an invite and issued an OK for th enew stream, but never switched. Is there something in my SIP config that could be causing this? Why do the first and second invites work fine, but the third doesn’t?

Thanks,

Mike

========================================
This is the SIP.conf entry:
[xxxxxx]
username=xxxxxx
secret=xxxxx
type=friend
port=5060
nat=never
context=xxxxx
insecure=port,invite
host=10.132.21.254
fromuser=xxxxx
;defaultexpirey=20
disallow=all
allow=ulaw
allow=alaw
canreinvite=yes
qualify=yes

This is the call flow:
|Time | 10.132.6.15 | 10.132.10.14 |
| | | 10.132.21.254 |
|9.432 | INVITE SDP (g711A g711U telephone-eventRTPType…1) | |SIP From: “Mike Myhre” <sip:sss7100@10.132.6.15 To:<sip:2383@10.132.21.254:5060
| |(5060) ------------------> (5060) | |
|9.440 | 100 Trying| | |SIP Status
| |(5060) <------------------ (5060) | |
|9.696 | 180 Ringing | |SIP Status
| |(5060) <------------------ (5060) | |
|11.171 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) <------------------ (5060) | |
|11.171 | ACK | | |SIP Request
| |(5060) ------------------> (5060) | |
|11.454 | RTP (g711U) | |RTP Num packets:333 Duration:6.638s SSRC:0x72645C86
| |(10400) <-------------------------------------- (50598) |
|11.505 | RTP (g711U) | |RTP Num packets:334 Duration:6.717s SSRC:0x5427728E
| |(10400) --------------------------------------> (50598) |
|18.229 | INVITE SDP (g711U g729 telephone-eventRTPType-…) | |SIP Request
| |(5060) <------------------ (5060) | |
|18.229 | 100 Trying| | |SIP Status
| |(5060) ------------------> (5060) | |
|18.230 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|18.243 | RTP (g711U) | |RTP Num packets:1075 Duration:21.477s SSRC:0x5427728E
| |(10400) ------------------> (10000) | |
|18.330 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|18.388 | ACK | | |SIP Request
| |(5060) <------------------ (5060) | |
|18.401 | RTP (g711U) | |RTP Num packets:434 Duration:8.658s SSRC:0x1D861C07
| |(10400) <------------------ (10000) | |
|27.081 | INVITE SDP (g711U g729 telephone-eventRTPType-…) | |SIP Request
| |(5060) <------------------ (5060) | |
|27.081 | 100 Trying| | |SIP Status
| |(5060) ------------------> (5060) | |
|27.081 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|27.181 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|27.283 | ACK | | |SIP Request
| |(5060) <------------------ (5060) | |
|27.352 | RTP (g711U) | |RTP Num packets:666 Duration:13.298s SSRC:0x5BF105B1
| |(10400) <-------------------------------------- (50598) |
|40.598 | BYE | | |SIP Request
| |(5060) ------------------> (5060) | |
|40.603 | 200 OK | | |SIP Status
| |(5060) <------------------ (5060) | |

2

Does it happen without the missing ACK and retransmission?

Apart from that, and think you need to providing core set debug 5 chan_sip debugging output, and details of the media direction attributes exchanged.

3

Yes, it happens every time (not dependent on a missed packet).
I tried enabling “core set debug 5 chan_sip.c” and I only get status messages like:
– Stopped music on hold on SIP/xxxx_xxxx-000040d7
– Started music on hold, class ‘none’, on SIP/xxxx_xxxx-000040d7
– Stopped music on hold on SIP/xxxx_xxxx-000040d7
I don’t see any ‘media exchange’ information (or are you talking about from the packet capture?)

4

Use sip set debug on as well.

5

After further digging, it appears that the double 200 OK packet seems to always happen. I don’t think that is significant though.
I have stripped out the REGISTER, OPTIONS, NOTIFY and other not needed packets to make it easier to read.

Here is a new wireshark flow and the SIP debug info:

==== FLOW ====
[size=85]|Time | 10.132.6.15 | 10.132.10.14 |
| | | 10.132.21.254 |
|1.134 | INVITE SDP (g711A g711U telephone-eventRTPType…1) | |SIP From: “Mike Myhre” <sip:sss7100@10.132.6.15 To:<sip:2303@10.132.21.254:5060
| |(5060) ------------------> (5060) | |
|1.143 | 100 Trying| | |SIP Status
| |(5060) <------------------ (5060) | |
|1.399 | 180 Ringing | |SIP Status
| |(5060) <------------------ (5060) | |
|9.790 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) <------------------ (5060) | |
|9.791 | ACK | | |SIP Request
| |(5060) ------------------> (5060) | |
|10.081 | RTP (g711U) | |RTP Num packets:350 Duration:6.979s SSRC:0x68153CEE
| |(10002) <-------------------------------------- (50818) |
|10.259 | RTP (g711U) | |RTP Num packets:344 Duration:6.916s SSRC:0x3E23A8CC
| |(10002) --------------------------------------> (50818) |
|17.180 | INVITE SDP (g711U g729 telephone-eventRTPType-…) | |SIP Request
| |(5060) <------------------ (5060) | |
|17.181 | 100 Trying| | |SIP Status
| |(5060) ------------------> (5060) | |
|17.181 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|17.196 | RTP (g711U) | |RTP Num packets:2058 Duration:41.154s SSRC:0x3E23A8CC
| |(10002) ------------------> (10000) | |
|17.280 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|17.339 | ACK | | |SIP Request
| |(5060) <------------------ (5060) | |
|17.356 | RTP (g711U) | |RTP Num packets:1190 Duration:23.776s SSRC:0x2D061CAD
| |(10002) <------------------ (10000) | |
|41.141 | INVITE SDP (g711U g729 telephone-eventRTPType-…) | |SIP Request
| |(5060) <------------------ (5060) | |
|41.142 | 100 Trying| | |SIP Status
| |(5060) ------------------> (5060) | |
|41.142 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|41.241 | 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) ------------------> (5060) | |
|41.337 | ACK | | |SIP Request
| |(5060) <------------------ (5060) | |
|41.407 | RTP (g711U) | |RTP Num packets:841 Duration:16.797s SSRC:0x631254C8
| |(10002) <-------------------------------------- (50818) |
|58.352 | BYE | | |SIP Request
| |(5060) <------------------ (5060) | |
|58.354 | 200 OK | | |SIP Status
| |(5060) ------------------> (5060) | |[/size]

==== SIP DEBUG TRACE =====

[size=85]“SIP/XXX_7100/2303”) in new stack
== Using SIP RTP CoS mark 5
Audio is at 10002
Adding codec 100004 (alaw) to SDP
Adding codec 100003 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.132.21.254:5060:
INVITE sip:2303@10.132.21.254:5060 SIP/2.0
Via: SIP/2.0/UDP 10.132.6.15:5060;branch=z9hG4bK7af35828
Max-Forwards: 70
From: “Mike Myhre” sip:xxx7100@10.132.6.15;tag=as37ced1e1
To: sip:2303@10.132.21.254:5060
Contact: sip:xxx7100@10.132.6.15:5060
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 11.0.0
Date: Mon, 10 Dec 2012 13:59:14 GMT
Session-Expires: 7200
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 255

v=0
o=root 157010108 157010108 IN IP4 10.132.6.15
s=Asterisk PBX 11.0.0
c=IN IP4 10.132.6.15
t=0 0
m=audio 10002 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

-- Called SIP/XXX_7100/2303

<— SIP read from UDP:10.132.21.254:5060 —>
SIP/2.0 100 Trying
From: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
To: sip:2303@10.132.21.254:5060
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.132.6.15:5060;branch=z9hG4bK7af35828
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Content-Length: 0
<------------->
— (11 headers 0 lines) —
<— SIP read from UDP:10.132.21.254:5060 —>
SIP/2.0 180 Ringing
From: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
To: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.132.6.15:5060;branch=z9hG4bK7af35828
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Content-Length: 0
<------------->
— (11 headers 0 lines) —
list_route: hop: sip:2303@10.132.21.254:5060;transport=UDP
– SIP/XXX_7100-0000414c is ringing

<— SIP read from UDP:10.132.21.254:5060 —>
SIP/2.0 200 OK
From: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
To: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.132.6.15:5060;branch=z9hG4bK7af35828
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Content-Type: application/sdp
Content-Length: 234

v=0
o=MxSIP 0 0 IN IP4 10.132.10.14
s=SIP Call
c=IN IP4 10.132.10.14
t=0 0
m=audio 50818 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
<------------->
— (12 headers 12 lines) —
Found RTP audio format 0
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|alaw), peer - audio=(ulaw)/video=(nothing)/text=(nothing), combined - (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.132.10.14:50818
list_route: hop: sip:2303@10.132.21.254:5060;transport=UDP
set_destination: Parsing sip:2303@10.132.21.254:5060;transport=UDP for address/port to send to
set_destination: set destination to 10.132.21.254:5060
Transmitting (no NAT) to 10.132.21.254:5060:
ACK sip:2303@10.132.21.254:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 10.132.6.15:5060;branch=z9hG4bK5f65a4f4
Max-Forwards: 70
From: “Mike Myhre” sip:xxx7100@10.132.6.15;tag=as37ced1e1
To: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
Contact: sip:xxx7100@10.132.6.15:5060
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 11.0.0
Content-Length: 0

-- SIP/XXX_7100-0000414c answered SIP/XXX-snom-0000414b

Audio is at 10104
Adding codec 100004 (alaw) to SDP
Adding codec 100003 (ulaw) to SDP
Adding codec 100002 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
<------------>
– Locally bridging SIP/XXX-snom-0000414b and SIP/XXX_7100-0000414c
<------------->
<— SIP read from UDP:10.132.21.254:5060 —>
INVITE sip:xxx7100@10.132.6.15:5060 SIP/2.0
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-373017-d793da1c-7f8016c4
Max-Forwards: 70
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Content-Type: application/sdp
Content-Length: 266

v=0
o=- 1355149297 1355149297 IN IP4 10.132.21.254
s=-
c=IN IP4 10.132.21.254
t=0 0
m=audio 10000 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=silenceSupp:off - - - -
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
— (13 headers 12 lines) —
Sending to 10.132.21.254:5060 (no NAT)
Found RTP audio format 0
Found RTP audio format 18
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|alaw), peer - audio=(ulaw|g729)/video=(nothing)/text=(nothing), combined - (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.132.21.254:10000

<— Transmitting (no NAT) to 10.132.21.254:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-373017-d793da1c-7f8016c4;received=10.132.21.254
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 1 INVITE
Server: Asterisk PBX 11.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:xxx7100@10.132.6.15:5060
Content-Length: 0
<------------>
Audio is at 10002
Adding codec 100003 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<— Reliably Transmitting (no NAT) to 10.132.21.254:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-373017-d793da1c-7f8016c4;received=10.132.21.254
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 1 INVITE
Server: Asterisk PBX 11.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:xxx7100@10.132.6.15:5060
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 157010108 157010109 IN IP4 10.132.6.15
s=Asterisk PBX 11.0.0
c=IN IP4 10.132.6.15
t=0 0
m=audio 10002 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>
– Locally bridging SIP/XXX-snom-0000414b and SIP/XXX_7100-0000414c
Retransmitting #1 (no NAT) to 10.132.21.254:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-373017-d793da1c-7f8016c4;received=10.132.21.254
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 1 INVITE
Server: Asterisk PBX 11.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:xxx7100@10.132.6.15:5060
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 157010108 157010109 IN IP4 10.132.6.15
s=Asterisk PBX 11.0.0
c=IN IP4 10.132.6.15
t=0 0
m=audio 10002 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<— SIP read from UDP:10.132.21.254:5060 —>
ACK sip:xxx7100@10.132.6.15:5060;transport=UDP SIP/2.0
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 1 ACK
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-373017-d793dabc-50f4a8c6
Max-Forwards: 70
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Content-Length: 0
— (12 headers 0 lines) —

<— SIP read from UDP:208.74.152.69:9319 —>

<— SIP read from UDP:10.132.21.254:5060 —>
INVITE sip:xxx7100@10.132.6.15:5060 SIP/2.0
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 2 INVITE
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-37302f-d79437ae-72c07ae5
Max-Forwards: 70
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Content-Type: application/sdp
Content-Length: 281

v=0
o=MxSIP 0 2 IN IP4 10.132.10.14
s=SIP Call
c=IN IP4 10.132.10.14
t=0 0
m=audio 50818 RTP/AVP 0 18 101
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->
— (13 headers 14 lines) —
Sending to 10.132.21.254:5060 (no NAT)

<— Transmitting (no NAT) to 10.132.21.254:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-37302f-d79437ae-72c07ae5;received=10.132.21.254
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 2 INVITE
Server: Asterisk PBX 11.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:xxx7100@10.132.6.15:5060
Content-Length: 0
<------------>
Audio is at 10002
Adding codec 100003 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<— Reliably Transmitting (no NAT) to 10.132.21.254:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-37302f-d79437ae-72c07ae5;received=10.132.21.254
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 2 INVITE
Server: Asterisk PBX 11.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:xxx7100@10.132.6.15:5060
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 157010108 157010109 IN IP4 10.132.6.15
s=Asterisk PBX 11.0.0
c=IN IP4 10.132.6.15
t=0 0
m=audio 10002 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>
– Locally bridging SIP/XXX-snom-0000414b and SIP/XXX_7100-0000414c
Retransmitting #1 (no NAT) to 10.132.21.254:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-37302f-d79437ae-72c07ae5;received=10.132.21.254
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 2 INVITE
Server: Asterisk PBX 11.0.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:xxx7100@10.132.6.15:5060
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 157010108 157010109 IN IP4 10.132.6.15
s=Asterisk PBX 11.0.0
c=IN IP4 10.132.6.15
t=0 0
m=audio 10002 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<— SIP read from UDP:10.132.21.254:5060 —>
ACK sip:xxx7100@10.132.6.15:5060;transport=UDP SIP/2.0
From: sip:2303@10.132.21.254:5060;tag=5435100-a8415fe-13c4-373007-88c2f01e-373007
To: "Mike Myhre"sip:xxx7100@10.132.6.15;tag=as37ced1e1
Call-ID: 244b81fe5a25124a196583503aa73185@10.132.6.15:5060
CSeq: 2 ACK
Via: SIP/2.0/UDP 10.132.21.254:5060;branch=z9hG4bK-37302f-d7943872-546758d3
Max-Forwards: 70
Supported: 100rel,replaces
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER
User-Agent: ADTRAN_NetVanta_7100/R10.3.1.E
Contact: sip:2303@10.132.21.254:5060;transport=UDP
Content-Length: 0
[/size]

6

There is a protocol violation by the other side. You may be able to work round it by setting ignoresdpversion.

It is starting with an SDP version of 0 and routing the audio directly to …14. It then re-invites, with a large SDP version, to …254 the entity doing the SIP. Finally it re-invites back to …14, with SDP version 2. As this is out of sequence, it is being ignored.

It’s actually indicating a completely different session, for the intermediate state. I’m not entirely what the semantics of that are, or whether ignoresdpversion will help.

Also, you have an unacceptable level of packet loss. The double 200 OK pretty much indicates a network on the verge of collapse.

7

That solved the problem!
Thank you soooo much for your help. I have been trying to get this fixed for a couple months now. Way too much time spent on such a simple fix. Knowing is everything.

Thanks again!!

8

I am trying to understand the SDP version.
Where in the packet are you seeing this? In Wireshark, I see the Session Description Protocol version (v): 0 but it is always 0 there. There is also the v=0 in the SIP DEBUG text, and that is always 0. Maybe these are the asterisk side? I don’t see where you are seeing the version change.

Thanks,

Mike

9

The 2 in the following:

o=MxSIP 0 2 IN IP4 10.132.10.14

10

Thanks. I see it now. I never would have guessed that could have caused this problem. I guess I would have expected an “ignoring packet” or “invalid version sequence” message to be generated along with the non-action.

Addressing the “network collapse” issue. I don’t think a retransmission once in a while isn’t that unexpected. I do see a couple retransmissions in each of the call flows, but how do you get “network collapse” from that? The data sent is less than 1% of the bandwidth available on the ethernet port.

Are you saying that I shouldn’t expect any retransmissions on a healthy network?

11

A healthy VoIP network should not be losing packets, although QoS might be used to give priority to not losing RTP packets.

12

What would you suggest to do the best for packet loss elimination?
Have a separate voice network? That would work for local, but there are more people to talk to than just local people, so you need to cross the internet which means the ISP and the internet backbone, both of which are going to have data mixed with voice and the ISP is likely the biggest bottle neck.

We are having some voice quality issues, but I don’t think QoS alone can solve them.