CUCM hold issue

[kalashnikovsg]

Hi,

We are using CUCM 7.1 with Cisco 2901 15.2.1T as a CUBE. There is SIP trunk between CUCM and 2901, and another SIP trunk between 2901 and SIP provider. When we want to hold/transfer external call, which is coming from SIP provider, it is terminated. Internal calls have no issues.

In captured SIP traffic I see SIP INVITE to 0.0.0.0, 200 OK, ACK and then BYE from SIP provider. I tried configure "mid-call signaling block", but there is no any changes in behavior of CUBE. How can I fix this issue?

Thanks,

Sergey

[Ayodeji Okanlawon]

I dont need the SDL trace. I need the SDI trace. And the call is not in the SDI trace.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[kalashnikovsg]

From  4952874964 to AA (2189) and then I was transfered by AA to 1120.

After that I asked to transfer me. Call was terminated.

Call was made between 18:00 - 18:02.

In debug ypu should see two calls. Fist one was failed. I meen that during this call I wasn't transfered att all.

Intresting call is the second one.

[Ayodeji Okanlawon]

I cant still find this call. Did you check in the trace if you can find the called number 2189?

Where is this extension 4952874964? Where is the AA?

The only way I can help is if I get the correct trace

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[kalashnikovsg]

I don't see call again too . I think that I am doing something wrong.

Id 2189 presented only on GW. This is pilot number. CUCM doesn't know anything about it.

[Ayodeji Okanlawon]

Set the debug trace level to "detailed"

DO another test call, collect the trace and confirm that the call is present in the trace before snding it.

How many servers do you have? How does the call get routed to cucm?

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[kalashnikovsg]

Why I see call in SDL, but I don't see it in SDI?

[Ayodeji Okanlawon]

What is your call flow. Please describe the call legs to me. ave youc hanged the settings to detailed? Do you have only 1 server?

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[kalashnikovsg]

I've collected loges from CUCM.

Call flow:

SIP provider - SIP trunk (G711) - GW (CUBE) - IVR (script on CUBE) - SIP trunk to CUCM (G711) - CUCM

Caller id: 4952874964 -> 2189 (IVR pilot number on CUBE) -> dialed 1112 -> transferred successfully to 1112 (registered on CUCM) -> tried transferred to another ext -> call was terminated

[Suresh Subramanian]

Call flow:

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

Caller  id: 4952874964 -> 2189 (IVR pilot number on CUBE) -> dialed 1112  -> transferred successfully to 1112 (registered on CUCM) -> tried  transferred to another ext -> call was terminated

Correct me if I'm wrong: The PSTN number 4952874964 called 2189 and dialed 1112 and connected to it. After that 1112 transferred the call to 1130.

The call was terminated as soon 1112 completed the transfer to 1130.

SIP provider - SIP trunk (G711) - GW (CUBE) - IVR (script on CUBE) - SIP trunk to CUCM (G711) - CUCM

from the trace it looks like the IP phones are using G.722 instead of G.711

11/02/2012 14:51:26.585 CCM|Digit analysis: match(pi="2", fqcn="1112", cn="1112",plv="5", pss="P_CUCM:P_International:P_Local_Krasnodar_WAN:P_Local_Moscow:P_Local_Perm_WAN:P_Local_Volgograd_WAN:P_Mobile:P_National:P_Local_Kazan_WAN:P_Meetme:P_Local_Sklad_WAN:P_PickUp:P_Local_Novosib_WAN:P_Local_Rostov_WAN:P_Local_Samara_WAN", TodFilteredPss="P_CUCM:P_International:P_Local_Krasnodar_WAN:P_Local_Moscow:P_Local_Perm_WAN:P_Local_Volgograd_WAN:P_Mobile:P_National:P_Local_Kazan_WAN:P_Meetme:P_Local_Sklad_WAN:P_PickUp:P_Local_Novosib_WAN:P_Local_Rostov_WAN:P_Local_Samara_WAN", dd="1130",dac="0")|<:STANDALONECLUSTER><:CUCM-01><:1><:10.90.0.146><:SEP78E7D1C52B4D><:STATE transition=""><:0800>

11/02/2012 14:51:28.599 CCM|StationD:    (0001705) startMediaTransmission conferenceID=20565837 passThruPartyID=16798299 remoteIpAddress=IpAddr.type:0 ipAddr:0x0a5a0092000000000000000000000000(10.90.0.146) remotePortNumber=24716 milliSecondPacketSize=20 compressType=6(Media_Payload_G722_64k) RFC2833PayloadType=0 qualifierOut=?. myIP: IpAddr.type:0 ipv4Addr:0x0a5a0055(10.90.0.85) |<:STANDALONECLUSTER><:CUCM-01><:1><:10.90.0.146><:SEP78E7D1C52B4D><:SIGNIFICANT><:0020>

IP Phone configuration page: Advertise G.722 Codec --> Disabled

Please make sure it is disabled in Enterprise Parameter also

can you disable the G.722 between the IP phones and check?

Thanks

SS

[kalashnikovsg]

Hi,

Call flow is correct.

We are using IP phones 7911. As I know this phones don't support G722.

Also the same problem is appear with HOLD. So may be problem isn't in G722?

Can I centrally disable G722 on CUCM?

[Suresh Subramanian]

Yes, you can disable the G.722 under Enterprise parameter (Advertise G.722 Codec) it should be disabled

[Ayodeji Okanlawon]

Hi,

Sorry for the late response...

I have looked at your traces in detailed and here is what I see...

After the call was transfered from 1112 to 1130, CUCM sends the following:

11/02/2012 14:51:46.841 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.63.0.1:[5060]:

BYE sip:4952874964@10.63.0.1:5060 SIP/2.0

Reason: Q.850;cause=86

Date: Fri, 02 Nov 2012 10:51:14 GMT

From: <1112>;tag=2baadd03-a7b4-4f20-964a-6fbc9aec0881-20565815

Content-Length: 0

User-Agent: Cisco-CUCM7.1

To: "4952874964" <4952874964>;tag=2CA8C228-33A

Call-ID:

114B1FA0-241211E2-82A1B4CD-69E1B74B@10.63.0.1

Via: SIP/2.0/UDP 10.50.0.3:5060;branch=z9hG4bK229259e09193

CSeq: 102 BYE

Max-Forwards: 70

NB: There are no codec errors in the traces, so I dont think its codec related...However what the cause code mean is that the call having the requested call identity has been cleared. Now I also see that this disconnect was sent to the CUBE. So this also suggests that its not an issue with the IP phone....

I would have suggested that you should increase your session timer, but I can see that it is already set to the default 1800s. This may be a bug..I dont know, but the problem is between CUCM and CUBE. More likely CUCM disconnecting the call. I dont usually like using MTPs, but you may try forcing cucm using an MTP. I dont see cucm requesting MTP, I am just thinking out of the box....Your last resort will be to open a TAC case with cisco

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[kalashnikovsg]

Problem was in script on CUBE. Without it, transfer begins to work. This script doesn't understand SIP re-Invite with attribute Inactive.

[Ryan Gunn]

Hi KalashnikovSG.  Can you be more specific on what you did to fix this?  I seem to be hitting the same issue

[Ayodeji Okanlawon]

Ryan,

What is your issue? Do you have a script on CUBE similar to the issue in this thread Or are you getting call disconnected on hold/xfer...

Can you describe your call flow

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"