CUCMBE 6.1 AA and SIP trunk issue

[sjones@techsgi.com]

Hello everyone--having a horrible time trying to get the AA on the business edition system at a client.  They recently switched to a SIP trunk over a dedicated T1 line.  They previously had a PRI with no issues on the AA.  After the migration, it's been painful to say the least.  The current issue is that when the auto attendant is activated, it plays and when you put in an extension, you hear one or two 'beeps' (cisco's standard hold sound) while it tries to transfer, it goes silent and then the call drops.  When i call the AA internally, it works like a charm, even on my IPC.  I need some guidance--trying to learn as i go but this is way over my head.  Would open a TAC case, however, the server serial number is on a smartnet that the install site is about 15-20 hours away...still trying to figure that out.  while my people are getting that resolved, i'm trying to find an answer or at least some guidance on what to look for. I'm also hoping this will help on my journey to a CCIE voice...  Thanks in advance.

Scott J.

.

[ADAM CRISP]

Hello,

It's my guess that the SIP service provider doesn't support the SIP REFER method (OR you've a voice codec incompatability between the SIP service provider and the telephone handset and no transcoding facility but I think this is relativly unlikely)

Often when calls are transfered within a SIP network, the call signalling path is shifted from one endpoint to another and this is kicked off with a Refer.

you can make a quick change to see if this is the problem.

On your ISR router, amend the incoming dial peer for the SIP trunk to have the command

no supplementary-service sip refer

OR

you can switch off refer on the whole router by configuring a similar command under the voice service voip / sip section

It would be helpful if you could capture the output of a debug ccsip messages on the ISR router and make a call into the AA, so we can see what's going on.

Adam

[sjones@techsgi.com]

That's a great idea. I'll be working on it over the weekend. I'll try that and if it doesn't work, I'll capture the debug and post it.

[ADAM CRISP]

OK. Let us know how you get on!

cheers

[sjones@techsgi.com]

Ok--no luck, tried both global and per dial-peer.  I've attached the output of the ccsipmessages debug, along with the running-config.  Let me know as i'll be trying to continue on it monday.  Thanks.

[sjones@techsgi.com]

dumb question--i got my hands on the telco document telling their installers how to configure CUBE...i see where the GW is

supposed to be H.323.  Currently, the gateway is MGCP (as it was previously...)  Is this necessary?  To provide some background, the telco sent their PS people in to configure the gateway.  I also let them into the CM as i didn't know what they wanted as far as partitions, etc. at the time.  However, i'm reading the document and i'm beginning to think there is more missing that we initially thought.  The document also references H.323 fast-start, which is apparently only able to be used under an H.323 gateway.  If anyone can provide some clarification, it looks like i'm going to be re-doing the entire configuration...

[ADAM CRISP]

Hi,

No refers, so not that at all.

You trace is good, not blatent errors. There may be something going on with codecs though,

The call gets placed.

CM puts the call on hold

CM takes the calls off hold with an offerless reinvite (presumable when you transfer the call)

and then there's the codec exchange

and then -( this is the odd part)  - we get another offerless invite from CM which could mean it didn't like the codec offer from the gateway?

You should check:

What codecs are supported by the phones and call manager

Try setting the codec to transparent on he gateway, or try forcing one codec through - like g711ulaw to start off with.

the MGCP configuration is for your ISDN, the Cisco ISR is acting as a SIP-SIP gatwway.

Adam

[sjones@techsgi.com]

Great stuff. I'll try setting the codec to passthrough and see what

happens. Thanks again.

Scott

Sent from my iPhone

On Sep 6, 2010, at 4:49 AM, "adamcrisp"

[sjones@techsgi.com]

Gave it a shot and when I forced it to use g.711ulaw, it failed miserably. Worth a shot though. Currently waiting on a TAC engineer to call me back to hammer it out further. Appreciate the help though. Once we figure out what it is, I'll post it on here so that hopefully the next poor soul won't have to struggle like I have.

Scott J.

[ADAM CRISP]

Hi Scott,

Did you fix this ?

Adam

[sjones@techsgi.com]

It's funny you ask that when you did. The client restarted the CTI Manager service, along with a couple others that they could not remember the names of, and after trying it, the AA started working...very strange.  Thanks for the help.  Greatly appreciated.

Scott Jones