cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
596
Views
0
Helpful
3
Replies

No audio on random incoming SIP calls

Jason Dance
Level 1
Level 1

Hi Community!

Hoping you can help me with this one.

I've had reports from some of my users that they get no audio on random incoming calls.  When they answer the call, the recipient cannot hear anything, and the caller is disconnected. 

I took some debugs and noticed in the failing calls that the SIP invite and the c line of the SDP have IP addresses that do not match.  Debugs of successful calls have IP addresses that both match in SIP invite and SDP. 

Here is the output I gathered (some values are masked to protect the innocent):

Failed call

008948: May 10 10:36:57.048: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:~~~~~~5056@XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP 12.194.141.181:5060;branch=z9hG4bKhak5ks200o6858hjj6m0.1
From: "MYCALLER" <sip:2~~~~~~787@12.194.141.181:5060>;tag=7638500593592712_c1b07.2.1.1487225703669.0_12746247_25332790
To: <sip:~~~~~~5056@XXX.XXX.XXX.XXX>
Call-ID: 09764958280100544@12.114.48.16
CSeq: 2 INVITE
P-Asserted-Identity: "MYCALLER" <sip:2~~~~~~787@12.194.141.181: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:12.194.141.181:5060;transport=udp>
Content-Length: 265
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 31400 8983 IN IP4 12.194.141.190
s=SIP Media Capabilities
c=IN IP4 12.194.141.190
t=0 0
m=audio 25184 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

Successful call

009173: May 10 10:58:18.552: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:~~~~~~5056@XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP 12.194.141.181:5060;branch=z9hG4bKnb35493078q64065nlp0.1
From: "MYCALLER" <sip:2~~~~~~592@12.194.141.181:5060>;tag=09002470632800741_c2b04.1.1.1485844275705.0_15931885_31660235
To: <sip:~~~~~~5056@XXX.XXX.XXX.XXX>
Call-ID: 5288979150146234@12.114.232.34
CSeq: 2 INVITE
P-Asserted-Identity: "MYCALLER" <sip:2~~~~~~592@12.194.141.181: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:12.194.141.181:5060;transport=udp>
Content-Length: 265
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 31304 8304 IN IP4 12.194.141.181
s=SIP Media Capabilities
c=IN IP4 12.194.141.181
t=0 0
m=audio 27116 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

Is this behavior normal and expected?

Regards,

Jason

3 Replies 3

Hi Jason,

This is normal. This means that your provider is having two sonus controllers which is normal to load balance in the calls in provider environment.  

Now its clear that when signaling and media goes through same controller, calls are successful. When signaling and media are through two different controllers, the call is failing. 

This sounds to be a problem with one of the controllers but if you share full debug for failed call, I might be able to confirm that. 

I attached the full debug of the failed call and I'm interested on what you see.  I already logged a case with my carrier, but they are very inefficient at resolving cases.

I was able to resolve this by adding a dial peer for the extra IP address.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: