One way-audio until hold/resume

Brandon Pierce · ‎01-09-2015

Hey guys,

I got a issue that I am currently investigating and just looking for a brain dump on top of what I am already looking into. Basically I got a site that gets occasional one-way audio at a front desk from external callers. They solve the problem by going on hold then resume but isn't common. I did some tests lasts night and out of about quite a few calls only got it to happen once. I am currently sifting through SIP logs but they look in-tact but I am going to re-review them again anyways.

Infrastructure:

(Primary Site) (Branch Site)

ITSP ---> CUBE ---> CUCM ---> CUBE ---> End User Phone

(SIP) (SIP) (SIP) (SIP)

On top of that, sometime the user doesn't hear his/her first "Hello testing" when spoken into the phone and can take two or three times before they can hear themselves. I almost want to say this is carrier related but I prefer to rule out of my side before pointing the finger. The SIP trunk is connected via a T1 on the ITSPs side but is fiber to the branch. We did this during off hours so the call volume was nil, just us making the test calls so nothing on the WAN/LAN for congestion.

SIP Logs (masked IP's for protection of the site)

Received:
INVITE sip:7758237@x.x.x.x:5060 SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKc1gtam30ag71se0fu5k0.1
From: "Doe, John" <sip:1234567890@x.x.x.x:5060>;tag=43307675265235257_c3b05.1.2.1416814149291.0_2396204_4722963
To: <sip:0123456789@10.100.10.6>
Call-ID: 13536288985953693@c3b05_1_2
CSeq: 2 INVITE
P-Asserted-Identity: "Doe, John" <sip:9729357196@x.x.x.x(public IP):5060>
Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Max-Forwards: 65
Contact: <sip:x.x.x.x(public IP):5060;transport=udp>
Content-Length: 263
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 7643 23017 IN IP4 x.x.x.x (Public IP)
s=SIP Media Capabilities
c=IN IP4 x.x.x.x(public IP)
t=0 0
m=audio 16400 RTP/AVP 18 0 100
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:30

Then the 200 OK after CUCM and CUBE agree:

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKc1gtam30ag71se0fu5k0.1
From: "Doe, John" <sip:1234567890@x.x.x.x(public IP):5060>;tag=43307675265235257_c3b05.1.2.1416814149291.0_2396204_4722963
To: <sip:0123456789@x.x.x.x>;tag=B18BA428-21E8
Date: Thu, 08 Jan 2015 22:49:58 GMT
Call-ID: 13536288985953693@c3b05_1_2
CSeq: 2 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:3456789@x.x.x.x:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.2.4.M5
Supported: timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 244

v=0
o=CiscoSystemsSIP-GW-UserAgent 5147 6524 IN IP4 10.100.10.6
s=SIP Call
c=IN IP4 x.x.x.x
t=0 0
m=audio 17412 RTP/AVP 0 100
c=IN IP4 10.100.10.6
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:30

Again, sorry for the changes to the SIP log but I didn't want to put any revealing info in there.

Brandon Pierce · ‎01-09-2015

The one thing that is strange that I noticed is:

Call-ID: 13536288985953693@c3b05_1_2

Not sure why there isn't an IP in there. I noticed the SIP leg to CUCM has the right IP address however.

George Thomas · ‎01-09-2015

The Call-ID changes depending on vendor, The SONUS gateways usually dont include IP address in the Call-ID but Cisco does and that is perfectly fine.

In the above OK message, what is the c=IN IP4 'address'? Phone IP? or some random MTP IP? Is it different from a working call?

Please rate useful posts.

Brandon Pierce · ‎01-09-2015

That particular 200 OK is:

v=0
o=CiscoSystemsSIP-GW-UserAgent 5147 6524 IN IP4 10.100.10.6
s=SIP Call
c=IN IP4 10.100.10.6
t=0 0
m=audio 17412 RTP/AVP 0 100
c=IN IP4 10.100.10.6
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:30

10.100.10.6 is the CUBE. I took these CCSIP mess debugs from the perspective of the originating CUBE hanging off of the ITSP equipment so it would be as close as possible to the external side of things since the branch CUBE should just accept whatever comes in.

George Thomas · ‎01-09-2015

That looks correct. That particular OK has two C attributes which is not normal. Can you get an output of the OK when the call connects normally? Do you have the OK message when the media is established after the call is put on hold/resume?

Please rate useful posts.

Brandon Pierce · ‎01-09-2015

Hang on, I need to wipe this post and go back in and look. The SIP logs are a mess since there is CUCM, the ITSP, and the branch involved. I've got 4 captures so kinda brain scattered at the moment.

Brandon Pierce · ‎01-12-2015

Looks like the firmware corrected the delayed audio but the hold/resume is still a problem. I did more investigation today and got a bigger picture of what is going on. The original call flow still is accurate with the exception that Unity picks up the call for the school after the initial 200 OK. Basically providing options to reach certain numbers, in my case the front desk. I really want to say it's a Telco issue since one way audio coming in only to be fixed by hold/resume is backwards of how it usually breaks but I could be wrong. After I clean up the SIP logs I will post what I can.

rowdygardner · ‎02-19-2015

Hi Brandon,

Did you manage to resolve this issue with one-way audio when the call is answered, which gets two-way audio when you put the call on hold and release?

We have the same intermittant issue here and are desperate for a solution. Your feedback on a possible solution would be much appreciated.

Brandon Pierce · ‎02-20-2015

Yeah, ultimately this issue was only on the phone model and I just pushed a firmware update and the customer had reported that he has since to ever have a problem with the front desk.

Brandon Pierce · ‎01-09-2015

Ok so....here we go, I think I got everything sorted out. Here is a 200OK during hold indicated by the a=inactive and the 0.0.0.0. This was sent to the ITSP with the public IP that I changed to 1.2.3.4 for security and privacy.

*Jan 8 16:46:39.490 CST: //296891/F8AA6537B016/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.100.10.6:5060;branch=z9hG4bK2810F4C
From: <sip:9727758237@10.100.10.6>;tag=B18820E0-2196
To: "DOE, JOHN" <sip:1234567890@1.2.3.4:5060>;tag=7474604411319054_c1b05.1.4.1416208391779.0_2828405_5583523
Call-ID: 20036024800389762@c1b05_1_4
CSeq: 105 INVITE
Timestamp: 1420757198
Allow: INVITE, BYE, ACK, CANCEL, PRACK, INFO
Accept: application/sdp
Accept: application/isup
Accept: application/dtmf
Accept: application/dtmf-relay
Accept: multipart/mixed
Content-Disposition: session;handling=required
Content-Type: application/sdp
Content-Length: 231
Contact: <sip:1.2.3.4:5060;transport=udp>

v=0
o=Sonus_UAC 16995 2631 IN IP4 1.2.3.4
s=SIP Media Capabilities
c=IN IP4 0.0.0.0
t=0 0
m=audio 19368 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=inactive
a=maxptime:20

Now the 200 OK coming off of hold sending SDP:

*Jan 8 16:46:40.634 CST: //296891/F8AA6537B016/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.100.10.6:5060;branch=z9hG4bK28111F42
From: <sip:9727758237@10.100.10.6>;tag=B18820E0-2196
To: "DOE, JOHN" <sip:1234567890@1.2.3.4:5060>;tag=7474604411319054_c1b05.1.4.1416208391779.0_2828405_5583523
Call-ID: 20036024800389762@c1b05_1_4
CSeq: 106 INVITE
Timestamp: 1420757200
Allow: INVITE, BYE, ACK, CANCEL, PRACK, INFO
Accept: application/sdp
Accept: application/isup
Accept: application/dtmf
Accept: application/dtmf-relay
Accept: multipart/mixed
Content-Disposition: session;handling=required
Content-Type: application/sdp
Content-Length: 263
Contact: <sip:1.2.3.4:5060;transport=udp>

v=0
o=Sonus_UAC 16995 2632 IN IP4 1.2.3.4
s=SIP Media Capabilities
c=IN IP4 1.2.3.4
t=0 0
m=audio 19368 RTP/AVP 18 0 100
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:30

Then the final ACK saying G.711

Received:
ACK sip:1234567890@10.100.10.6:5060 SIP/2.0
Via: SIP/2.0/UDP 10.100.10.12:5060;branch=z9hG4bK260c8d1f9b6ae9
From: <sip:7758237@10.100.10.12>;tag=91697089~1f20bb13-00af-48d3-9646-72956db5502e-43294077
To: "DOE, JOHN" <sip:1234567890@10.100.10.6>;tag=B18820D0-5D0
Date: Thu, 08 Jan 2015 22:49:16 GMT
Call-ID: F8AB9E20-96BE11E4-B01C8870-E1A93528@10.100.10.6
Max-Forwards: 70
CSeq: 106 ACK
Allow-Events: presence, kpml
Content-Type: application/sdp
Content-Length: 238

v=0
o=CiscoSystemsCCM-SIP 91697089 7

IN IP4 10.100.10.12
s=SIP Call
c=IN IP4 10.100.3.49
b=TIAS:64000
b=AS:64
t=0 0
m=audio 17992 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

I think that's everything. I need to do one more test with a hold/resume that happens so I can get cleaner logs as the SIP was a mile long and there was a bunch of INVITES do to the hold which makes for sore eyes. Ended up using TranslatorX.

George Thomas · ‎01-09-2015

What i dont understand is why you have two IPs:

IN IP4 10.100.10.12
s=SIP Call
c=IN IP4 10.100.3.49

Also, what is 10.100.3.149 & 10.100.10.12? Since that changed from the initial non-working call.

Please rate useful posts.

Brandon Pierce · ‎01-09-2015

10.100.3.49 is the IP Phone itself

10.100.10.12 is the subscriber CUCM

Brandon Pierce · ‎01-09-2015

This issue has been potentially fixed. I pushed a new firmware update to the 7961 and did about 5 test calls with the only thing being a slight latency from pickup to hearing hello. I had the on-site representative email me back saying he did another set of calls and could not reproduce the issue either and was getting no latency at all this time. So the latest 78xx SIP loads did the trick presumably.