Cisco to Avaya Integration - one way audio

[invisibleaxm]

Hello everyone,

I've been working on a integration between Avaya and Cisco telephone systems and we are experiencing one-way audio calls. So far we have found that on the Avaya side, there is a setting on the signaling group which pretty much prevents or blocks direct IP-IP audio connections between the endpoints. (see http://www.iaug.org/p/fo/et/thread=24201) I am not familiar with the cisco equipment so I am hoping you all can help me here.

I have to say that for this integration, we do not have routing enabled, the only thing the CUBE router can reach is the Avaya PBX and nothing else (the CUBE router doesn't have a way to talk to any of the Avaya's endpoints and viceversa).  The reason for us not having routing enabled is still not clear to me (technical??) but I've been told that as long as the Call Managers can reach is other, everything is supposed to work (inter-PBX integration)?.

From reading around, so far the only setting I've seen to allow for this so called inter-PBX integration is the Avaya setting i mentioned and that has been working for calls made from Avaya to Cisco (two way audio work fine). So far, calls initiated from the Cisco Call Manager to Avaya experience one way audio.

Is there a setting on the cisco call manager that will force all calls to negotiate the VoIP traffic using the call manager's IP address (NAT/PAT) or do i have to enable routing and let the phones do the RTP voice setup ? Am I missing something basic? I have to say that my background is system administration and I am trying to cover the role of the PBX admin so I know i have lots of gap of knowledge.

I appreciate all of your help and hope that you can point me in the right direction,

Thanks!

[CHRIS CHARLEBOIS]

My suspicion is that the problem is not the traffic from the Cisco IP Phone to the Avaya.  If you have CUBE in the mix, all traffic should go through that.  However, depending on how that is configured, the CUBE may be negotiating using a source address that the Avaya cannot route to.  First, can you confirm in which direction the audio flows and which direction is doesn't?  Second, would you be willing to share your CUBE configuration so we can look at that?

[invisibleaxm]

Chris,

Thanks a lot for your reply. Unfortunately i do not have access to the CUBE (as you can already imagine, I'm the one working on this from the Avaya side) however, I can tell you that we have been doing traces and we observed the following:

Working scenario (audio travels both ways):

Endpoint --> Avaya Call Manager --> Session Manager--> CUBE --> Cisco Call Manager --> endpoint

During this setup, the IP address that shows up in the traces are those of the Call Managers. Keep in mind that I disabled Direct IP-to-IP setting as previously stated.

Not working scenario: (one way audio)

Endpoint --> Cisco Call Manager -->  CUBE --> Avaya session manager --> Avaya Call Manager --> endpoint

During this scenario, the IP addresses that show up in the traces are (some times) the IP of the Cisco Call manager and the Avaya endpoint and sometimes is between both endpoints.

I can try to get a copy of the CUBE configuration, but i guess is there a specific setting you are interested in seeing?
 

Once again, thank you very much for your feedback,

[moyo oyegunle]

Hello

Some things you can try

a In Cube make sure the under the SBC config that SIP to SIP configurations are allowed  and that the session manager address is in the trusted list.

b This might be a codec issue configure a MRGL on cucm and add dsp resorces which hopefully the cube router has and assign to the phone or it's device pool.

c On the Avaya side since you disabled Direct ip-ip ,enable the ip-audio hairpining, if cube is configured for forced fast start(the person who configured it will know) also enable the fast start

d On the Avaya SES just to make sure you might want to add the Cisco cube to the trusted list host.

3 Try a trace on the Avaya CM( In emulation type" li trace st ext") what you will be looking for is how the call was processed.

Let is know how it goes.

[invisibleaxm]

Hello,

Thanks for this info, i indeed have ip-audio hairpining currently set to 'n' so that is something i can try. Let me follow the rest of the recommendations and let you know how it goes.

[moyo oyegunle]

Another thing I totally forgot to mention is this can be a NAT issue assume the network engr's would have noticed but just in case. You can catch this if you see the private address in the SDP payload that gets to the Avaya.

[invisibleaxm]

Thank you, as it turns out, the problem was that there were 2 trunks from Avaya Communication Manager and Avaya Session Manager (trunk 18 and 19). Outgoing calls from Avaya to Cube were all using trunk 19 which had Direct IP-IP disabled but some incomming calls were being routed using trunk 18 which did NOT have direct-IP-IP disabled, thus letting the phones do the VoIP RTP piece of the phone call.

Thank you very much for your assistance in this matter, it allowed us to narrow down the issue a little bit further.