cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
384
Views
5
Helpful
8
Replies

CUBE - One way audio

Hi expert,

We have Cisco CUBE connect to other company as SIP trunk.     

Design below:

------------

Phone A -- 3rd Party PBX --- SBC --- WAN --- CUBE SBC --- Call Manager --- Phone B

When I do test call, the SIP call flow as below:

------------------------------------------------

- Phone A -- SBC -- CUBE SBC -- Call Manager (Phone B)   

   (Phone A can hear Phone B, but Phone B cannot hear Phone A)

Questions:

---------

a. Why SIP call flow, we see Call Manager above, I thought Cisco SBC CUBE will hide Call Manager? So, I should not see UCM on SIP Call Flow.   Do I need SIP Header manipulation to hide UCM or this is expected?

b. What is likely cause the one-way audio here?   And what is the fix?

Thanks,

VT

 

2 Accepted Solutions

Accepted Solutions

If Cube functionality is turned on and configured correctly the SIP dialog from the POV of the 3:rd party SBC should not have information about your CM(s). Can you please post the running configuration of your Cisco router that acts as your SBC? Feel free to mask out any information that you don’t want to disclose, but please keep the overall configuration when it relates to call routing and Cube functionality structurally intact. Information such as phone numbers and public IPs you can replace with dummy information to obscure it.



Response Signature


View solution in original post

The audio from B to A doesn’t guarantee that traffic from A to B will occur. In your situation, the RTP packets from A to B are not reaching Phone B.

There are two streams of RTP traffic: one from A to B and another from B to A. In your case, the RTP packets from A are being dropped somewhere in the network.



Response Signature


View solution in original post

8 Replies 8

a. From which point of the call flow is it that you’re looking at the SIP dialogue? If it’s from the POV of your SBC (Cube) it would see the CM. Another option is that you haven’t configured your router with Cube functionality turned on. If you want help with this please share your router configuration.

b. The most common cause of one way audio is IP traffic not flowing from/to the endpoints involved in the media stream.



Response Signature


hi Roger,

a. The SIP call flow is from 3rd party SBC view point ( not from Cisco CUBE)

b. According to 3rd party SBC vendor, the reason of one way audio is their SBC dont want to communicate with UCM ( only with Cisco CUBE SBC), is it possible ?  and How to prove that?

 

Rgds,

V

 

Btw,  Cisco CUBE functionality is enabled.  Do we need to manipulate the SIP profile  , so UCM not come in picture?

If Cube functionality is turned on and configured correctly the SIP dialog from the POV of the 3:rd party SBC should not have information about your CM(s). Can you please post the running configuration of your Cisco router that acts as your SBC? Feel free to mask out any information that you don’t want to disclose, but please keep the overall configuration when it relates to call routing and Cube functionality structurally intact. Information such as phone numbers and public IPs you can replace with dummy information to obscure it.



Response Signature


hi Roger and Nithin,

Thanks for input here, I just about to send the config for you, however we figured out the issue, it is interface for dial-peer. We need to use different interface for UCM and the B2B

Thanks again

V

Phone A – SBC – CUBE SBC – Call Manager (Phone B)
(Phone A can hear Phone B, but Phone B cannot hear Phone A)

First, you need to do a packet capture on the CUBE router to see if you have received the RTP from Phone A. If you don’t see the RTP packets for this call on the CUBE, you need to check the route from the Phone A subnet to the CUCM site network.Investigate why the RTP doesn’t reach the CUBE.

 

If you receive the RTP packets on the CUBE, next you need to investigate who is dropping these packets before they reach the phone.

One-way and two-way audio issues are commonly due to routing problems.



Response Signature


Thanks Nithin,

The audio is happening from Phone B to Phone A using same route. Possible codec issue or other things?

 

Rgds

V

The audio from B to A doesn’t guarantee that traffic from A to B will occur. In your situation, the RTP packets from A to B are not reaching Phone B.

There are two streams of RTP traffic: one from A to B and another from B to A. In your case, the RTP packets from A are being dropped somewhere in the network.



Response Signature