2901 CME: One way Audio via SIP Trunk

[ooiaiyoon]

Dear All,

Merry Xmas !!! :P

I have read some cases of 'One way audio' but it seems can't relate exactly my current scenario.

Mine setup is having CME setup on my 2901 router, analog phone attach to my FXS port to make call via SIP across another 'big cloud' (I would name it as B). My problem is about the audio traffic, when calling to a fixed line no (from my local analog phone), both ends can listen to each other but when local phone calls to mobile number, only one way traffic is there -> recipient can hear the caller but caller can't hear anything.

Not good in identifying the RTP traffic/flow that might cause the problem, hence asking for help on this.

Kindly assist. Many Thanks.

P/S: Many say its routing issue but we got double check the routing on few devices, it's been open up way for the traffic, not sure where else goes wrong. Attached with the config file and logs.

[Aaron Harrison]

Can you re-post your config? I can see the log file but not the configuration...

Aaron

[ooiaiyoon]

Hi Aaron,

No problem, in fact I make quite a few changes on the configuration due to the failure hence there are lines which might not using.

Thanks for your help.

[Aaron Harrison]

Hi

Firstly, this looks bad:

voice service voip
 ip address trusted list
  ipv4 192.168.51.0 255.255.255.0
  ipv4 192.168.51.1
  ipv4 0.0.0.0 0.0.0.0 <--- allows connections from anywhere

You have no ACL on your publicly addressed interface; in fact I can telnet to 5060 on it from here.

This means you are open to toll fraud - anyone can send SIP calls to you, and you will send them to your service provider at your cost.

I would suggest you remove that 0.0.0.0 line, and allow only trusted IPs. Also apply an ACL to the outside interface to back that security up. Finally, once you have the config improved you should configure your peers so that 'inbound' peers cannot reach 'outbound' peers and vice versa..

NOw... on to your main problem...

Can you post up a debug ccsip messages for each call? i.e. the 'working' and 'non working' scenario?

Thanks

Aaron

[ooiaiyoon]

Hi Aaron,

Thanks for the advice, the ipv4 0.0.0.0 0.0.0.0 was configured initially just for troubleshooting purpose, just want to try to allow to avoid any unexpected blocking traffic from reaching the CME. Anyway, I have removed it.

For ACL, I just want to do after resolving the issue as I prefer to let them working then slowly restrict rather than the other way round.

As per your advice, attached with 2 ccsip message logs on

1. Working without audio issue - call from local number (093080413) to no 03 8318 3648 via SIP trunk

2. Not Working with one way audio - call from local number (093080413) to mobile no 012 263 1736 via SIP trunk

Thank you very much for your fast response.

Yoon

[Aaron Harrison]

So your working call INVITE starts like so:

Sent: 
INVITE sip:0383183648@58.27.113.196:5060 SIP/2.0

Via: SIP/2.0/UDP 58.27.18.61:5060;branch=z9hG4bK341AA2

<snip>

v=0

o=CiscoSystemsSIP-GW-UserAgent 5786 537 IN IP4 58.27.18.61

s=SIP Call

c=IN IP4 58.27.18.61

t=0 0

m=audio 16416 RTP/AVP 8

c=IN IP4 58.27.18.61

a=rtpmap:8 PCMA/8000

a=ptime:20

Compared to your non-working:

Sent: 
INVITE sip:0122631736@58.27.113.196:5060 SIP/2.0

Via: SIP/2.0/UDP 58.27.18.61:5060;branch=z9hG4bK372307

<snip>

v=0

o=CiscoSystemsSIP-GW-UserAg
CME_2901#ent 5337 7646 IN IP4 58.27.18.61

s=SIP Call

c=IN IP4 58.27.18.61

t=0 0

m=audio 16418 RTP/AVP 0 101

c=IN IP4 58.27.18.61

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

You have different media capabilities being advertised. This is because your mobile calls are going out of dial-peer 199, and others are going out of 200. The two are configured inconsistently and it appears your SP doesn't like the config on 199. 

If you configure :

dial-peer voice 200

dtmf-relay rtp-nte

codec g711a

vad

It will probably work... 

Aaron

[ooiaiyoon]

Hi Aaron,

Thanks for your reply, I haven't tested base on your suggestion as already left the workplace. However, I don't understand why would the 2 different dial peer affect each other as I thought the outgoing traffic map the desire dial peer base on destination pattern (as per configuration, mobile no and fixed line are separate dial peer due to testing/isolation). And more over, the single way audio issue already there before I put in the dial peer 200, hence, logical thinking I didn't link both of them as a confusion to the system.

By the way, for the highlighted advertised media capability, can I know entry should be identical? I can only see the ulaw and alaw different, perhaps the RTP/AVP or a=rtpmap ??

m=audio 16418 RTP/AVP 0 101

c=IN IP4 58.27.18.61

a=rtpmap:0 PCMU/8000,

m=audio 16416 RTP/AVP 8

c=IN IP4 58.27.18.61

a=rtpmap:8 PCMA/8000

Kindly advise.

Thanks ya.

[Aaron Harrison]

Hi

You said calls to mobile are one-way, and calls to fixed lines are OK?

That's two different numbers.

The numbers in your traces match the two dial-peers (0383183648 matches dp 200, 0122631736 matches DP 199), so they get the settings on that peer.

One goes out as ulaw, one as alaw, and you also have inconsistent dtmf relay and VAD, all of which may or may not confuse the other end. Make the peer that doesn't work match the one that does, and it will be OK.

Aaron

[ooiaiyoon]

Hi Aaron,

Sorry for late reply,

You said calls to mobile are one-way, and calls to fixed lines are OK? That's correct.

I tried with your config but still the same. Attached is my log and the config as well.

m=audio 30942 RTP/AVP 0 101

c=IN IP4 58.27.18.61

a=rtpmap:0 PCMU/8000

I tried with both 711u and 711a.

I can't see a further info on why is the audio from receiver to caller not established.  Kindly assist.

Thanks

[Aaron Harrison]

Hi

Your call in that trace now matches the previous non-working call trace:

v=0

o=CiscoSystemsSIP-GW-Use
CME_2901#rAgent 6604 5195 IN IP4 58.27.18.61

s=SIP Call

c=IN IP4 58.27.18.61

t=0 0

m=audio 30942 RTP/AVP 0 101

c=IN IP4 58.27.18.61

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

You haven't made the changes I described, but you have made the working dial-peer like the non-working one...????