cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1040
Views
0
Helpful
7
Replies

One way Audio in SIP to SIP Call

sherif.elella
Level 1
Level 1

here is the topology

(non-cisco SIP server) <----> (sip trunk on CUCM with "mtp required" checked and "early offer" check in SIP profile) <---> CUCM <---> (SIP Trunk to CME) <--> Phone with SNR configured

call flow:

1. Cisco phone registered to CUCM dials a number that goes to CME SIP Trunk, rings the phone and triggers SNR that sends the call back to CUCM and through the CSS sends the call to the non-cisco SIP Server SIP Trunk

2. SIP Client on non-cisco SIP Server rings, and when answered, there is only one way audio going backwards.

3. Cisco phone can hear SIP Client but SIP Client cannot hear Cisco phone.

I have tried all possible termination configuration, always one way audio.

SIP Packets have no occurance of a=inactive or audio=sendonly

what is odd is that it was working then three days later tested again, and it gives only way audio

here is the CME Config:

voice service voip
no ip address trusted authenticate
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sip
bind control source-interface GigabitEthernet0/0
bind media source-interface GigabitEthernet0/0
listen-port non-secure 5068

dial-peer voice 61 voip
destination-pattern 332..$
session protocol sipv2
session target ipv4:xx.xx.xx.xx:5068
incoming called-number 332..$
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
no vad

what can i do to figure out why it stoppped working? everything looks fine. 

7 Replies 7

Rajan
VIP Alumni
VIP Alumni

Hi,

You need to get packet captures from CIsco phone and the SIp client/the nearest possible entity to see whether RTP streams are reaching either ways since you confirm the signaling to be fine.

HTH

Rajan

already did that, the destination of RTP is correct and there is RTP being generated as long as the phone call is up, the destination of the RTP Packets are the MTP. 

Dennis Mink
VIP Alumni
VIP Alumni

can you add a trace of the call to the post, and also, why are you forcing to invoke an MTP?

Please remember to rate useful posts, by clicking on the stars below.

the calls between the non cisco server and the cucm wouldn't work otherwise ((excluding the CME))

in the sdl its the phone call going from 7438 to 3266 and 7438 to 123453266

I can see the call come from 10.109.11.2 go to 10.10.97.106  (MTP?).

the the 200OK has a c=10.10.10.4 (from 10.10.97.106 ie. the MTP

the there is a BYe from 10.109.11.2 with Q.850 cause code 16.

Can you explain these IP addresses, what is what?

Please rate if useful

Please remember to rate useful posts, by clicking on the stars below.

10.109.11.2 is CME

10.10.10.14 is a MTP on a voice gateway

10.10.97.106 is the cucm also MTP

I tested the same call again and it worked, opened 

sh sccp conn on the MTP VG

and sh voip rtp conn det

the call flow is good,

a transcoder is invoked, not an MTP

XX#sh sccp conn
sess_id conn_id stype mode codec ripaddr rport sport

16982270 34419634 xcode sendrecv g711u 10.109.11.2 17694 19498
16982270 34419633 xcode sendrecv g711u 10.10.98.77 54950 19104

XX#do sh sccp conn det

bridge-info(bid, cid) - Normal bridge information(Bridge id, Calleg id)
mmbridge-info(bid, cid) - Mixed mode bridge information(Bridge id, Calleg id)

sess_id conn_id call-id codec pkt-period dtmf_method type bridge-info(bid, cid) mmbridge-info(bid, cid) srtp_cryptosuite

16982287 - 166152 N/A N/A rfc2833_pthru transmsp All RTPSPI Callegs N/A N/A

16982287 34419754 166153 g711u 20 rfc2833_pthru rtpspi (58519,166152) N/A N/A

16982287 - 166152 N/A N/A pthru_report transmsp All RTPSPI Callegs N/A N/A

16982287 34419753 166151 g711u 20 pthru_report rtpspi (58518,166152) N/A N/A

after 3 successfull calls, it failed and i could not get it to work again.