Solved: VM fails on SIP trunk calls transfered from AA

bross · ‎08-11-2011

Im running version 8.1 on a UC540, using SIP trunks from Paetec. My main number DID points to the auto attendant, calls come in fine, you can follow the prompts, when you select a user extension the phone rings but no voice mail. If I set up the same scenario with a blast group instead of the auto attendant, the calls work fine and no problems with voice mail. I'm only losing VM when the call is transferred from the AA.. Any suggestions would be appreciated.. Thanks

David Trad · ‎08-11-2011

Hi Barry,

I know with a couple of ITSP's this issue will happen, one Codec is negotiated when the AA answers, then the call is passed to an extension, and in most cases there is Codec renegotiation, however as soon as that is passed back to the CUE it would fail as there is another request to renegotiate the Codec... Some ITSP's either do not allow this or cannot handle it.

In theory though the Cisco should be doing its own internal transcoding et`all and not having to deal with the ITSP, but in all the CCSIP debugs I have done looking over this, you can see that a renegotiation request is sent to them.

I know this is not the best request, but can you test (If the ITSP allows it) by using G.711aLAW end-to-end and see if the problem happens, if it doesn't then we can certainly work on it at the UC level

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

View solution in original post

lgaughan · ‎08-11-2011

Was this setup by CCA?

For the blast group, I assume the call is going to the general delivery mailbox (GDM) for the group, not for the user.

Did you check the configuration on the user's extension? Voicemail should be enabled (mailbox created) and call forward no answer should be to voicemail. If you dial the extension from another phone (not through the AA), does it go to voicemail when not answered?

Laura

bross · ‎08-11-2011

It was setup with CCA 3.1

User VM works for every call, except calls transferred from the auto attendant. I'm thinking this has to be a SIP issue with calls coming into CUE (AA), then leaving CUE (user Ext), then back to CUE (for VM). Or possibly a Codec problem.

lgaughan · ‎08-11-2011

We had an issue like this a couple years with Paetec when CCA supported multiple codecs. But if setup with CCA 3.1, Paetec should only be configured for G729 and transcoding should be triggered for any calls with CUE since using G711ulaw. Check that we have the following for the voice class and that all inbound dial-peers for SIP are using voice-class codec:

voice class codec 1

codec preference 1 g729r8

Also, what kind of phone is involved here?

Laura

bross · ‎08-11-2011

Yep, the system is already configured as you described.

The phones are SPA504, and SPA525

Thanks

Barry

David Trad · ‎08-11-2011

Hi Barry,

I know with a couple of ITSP's this issue will happen, one Codec is negotiated when the AA answers, then the call is passed to an extension, and in most cases there is Codec renegotiation, however as soon as that is passed back to the CUE it would fail as there is another request to renegotiate the Codec... Some ITSP's either do not allow this or cannot handle it.

In theory though the Cisco should be doing its own internal transcoding et`all and not having to deal with the ITSP, but in all the CCSIP debugs I have done looking over this, you can see that a renegotiation request is sent to them.

I know this is not the best request, but can you test (If the ITSP allows it) by using G.711aLAW end-to-end and see if the problem happens, if it doesn't then we can certainly work on it at the UC level

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

bross · ‎08-11-2011

Hi David,

Thanks for the response, I've been thinking along the same lines. I'm going to try testing with the ITSP using G.711, I'll respond with the results if they'll do it..

Thanks again,

Barry

bkwon · ‎08-12-2011

Hi Barry,

the problem is VVC can not handle the transcoding in re-INVITE properly.

this issue addressed and fixed in the latest IOS image 15.1.(2).T4, which is included in 8.2.0 uc500 software pack.

thanks
Bongsu

bross · ‎08-12-2011

I was able to get Paetec to change the codec to G.711ulaw, and that solved the problem.

Thanks for all the help and feedback on this..

Barry

David Trad · ‎08-13-2011

Hi Barry,

Glad to hear that it is working for you now, sadly though this should not have been the solution

This tells me that the UC is not doing the transcoding locally when it should be, the Codec to the ITSP should have remained as first negotiated and then the UC should transcode it to the one the CUE negotiates/requests for.

I hope you can get away with running G.711 it is a bandwidth hog, but if this is not a problem for this site then I hope it all goes smoothly for you from hear on end

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

lgaughan · ‎08-15-2011

The other solution would have also been to upgrade to 8.2. Seems the issue with this call flow was known issue in some IOS versions (see Bongsu's post above) and the fix is included in the UC500 8.2 software package.

Laura

bross · ‎08-15-2011

Yes, I saw the post from Bongsu and I plan to upgrade to 8.2 in the next week or so.

OldCCIE · ‎10-23-2011

I just ran into this issue with a customer on Friday during a cutover to a new PaeTec SIP trunk. Upgrading to 8.2 fixed the issue.

bkwon · ‎10-24-2011

great, thanks Todd for update.