Re: Call Transfer Fails CUCM 8.6

pm115redc · ‎04-04-2014

Hi,

Hope you can help me - I'm out of my depth here!

So I have set up a SIP trunk (via an Enterprise CUBE) to a UK SIP provider. It works, I can place a call and it connects, two-way voice all is good. There are of course 2 call legs, one from CUCM (v8.6) to the CUBE via SIP and a second from the CUBE to the provider. Just for clarity the CUBE has a public address to which the dial-peer binds SIP for the external call leg, and a private address to which the dial-peer binds SIP for the internal leg.

So far so good...until I try a call transfer. I make an outbound call, get it connected, hit the transfer button on the phone and... nothing. The phone sort of freezes for a few seconds and the Transfer softkey is greyed out. A few seconds later the Transfer softkey returns to its previous state, and the call appears like its resumed (off hold) but there is now no voice traffic in either direction.

its very odd - and probably somthing I dont understand. The odd thing is that inbound calls (via another trunk but different provider) are fine, and I can transfer or hold or whatever without issue.

I watched the SIP messages on the CUBE when I hit the transfer and all I got was:

Received:

INVITE sip:07775xxxxxxx@10.75.75.100:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.75.75.200:5060;branch=z9hG4bK11766a4f7a3

From: "Peter Moore" <sip:7001@10.75.75.200>;tag=412~b2b44154-5f1c-40dd-beec-492fa4b45cb6-25681932

To: <sip:07775xxxxxxx@10.75.75.100>;tag=419E178-96

Date: Fri, 04 Apr 2014 16:02:06 GMT

Call-ID: 6dd80700-33e1d76f-3f-c84b4b0a@10.75.75.200

Supported: 100rel,timer,resource-priority,replaces

Min-SE: 1800

User-Agent: Cisco-CUCM8.6

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

CSeq: 104 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

P-Asserted-Identity: "XXX XXXXX" <sip:7001@10.75.75.200>

Privacy: none

Remote-Party-ID: "XXX XXXXX" <sip:7001@10.75.75.200>;party=calling;screen=yes;privacy=full

Contact: <sip:10.75.75.200:5060;transport=tcp>

Content-Type: application/sdp

Content-Length: 220

v=0

o=CiscoSystemsCCM-SIP 412 2 IN IP4 10.75.75.200

s=SIP Call

c=IN IP4 0.0.0.0

t=0 0

m=audio 20354 RTP/AVP 18 101

a=rtpmap:18 G729/8000

a=ptime:20

a=inactive

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

Apr 4 16:02:06.819: //358/6DD807000000/SIP/Msg/ccsipDisplayMsg:

Sent:

2811-Cube-VPN(config-class)#SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.75.75.200:5060;branch=z9hG4bK11766a4f7a3

From: "XXX XXXXX" <sip:7001@10.75.75.200>;tag=412~b2b44154-5f1c-40dd-beec-492fa4b45cb6-25681932

To: <sip:07775xxxxxx@10.75.75.100>;tag=419E178-96

Date: Fri, 04 Apr 2014 16:02:06 GMT

Call-ID: 6dd80700-33e1d76f-3f-c84b4b0a@10.75.75.200

CSeq: 104 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

... thats all. Nothing else until I cleared the call.

I know its a long shot, but has anyone got any idea where to start troubleshooting this?

Thanks

sgyablonski · ‎04-04-2014

we have had a similar issue with SIP Calls using CUBE and CUCM 7.1 not sure if it will help but....

Issue: In a bad call, Phone A talks to Phone B and tries to
conference in Phone C [PSTN]. While Phone C is ringing, Phone A presses
the conference soft key (Phone C is not connected right now, it is still
ringing). This is not an issue when the conference call softkey is
pressed after the PSTN phone answers. Since our migration to CUBE,

The Fix: In order to resolve the issue with calls dropping when
conferencing a PSTN person before answer, we would need to check/enable
"MTP Required" on the SIP trunk. In doing so, CUCM has the
ability to control and change the RTP connection when the call is conferenced
and not rely on SIP messaging to the CUBE and SIP provider. This will
result in fewer SIP messages being sent through the CUBE since the MTP will be
able to handle the media changes using SCCP messaging. TAC recommends
that we utilize IOS software MTP on the CUBE. This is something that is
already set up on our CUBE. These are software only resources and this
won’t utilize any DSP hardware resources. To facilitate this change, we
should change the MRGL on the SIP trunk, such that only the MTPs are in the
first MRG and the transcoders are in another MRG further down the list.
This will prevent CUCM from using a transcoder as a possible MTP resource
and will mitigate unnecessarily wasting of DSP resources.

Technical issue - SIP Early
offer: As we know, Verizon [and
most providers now] require SIP Early Offer as the means of quickly setting up
media for calls. With “early offer” the calling party sends the SDP
within the SIP Invite message. SDP contains codec, IP address, port # and
dtmf parameters. Early offer insures no delay in the SIP call
setup. When the original SDP parameters are changed as a result of a
conference call being invoked the “conferenced PSTN” leg of the call
fails/drops. MTP is a means of addressing this issue. With MTP configured,
the SDP contains the MTP information and this fixes the conference call
issue.

**CUCM version** - With UCM versions 8.0 and prior, MTP must be invoked
for ALL calls regardless of the need if the “MTP Required” box is checked on
the SIP trunk. Call Manager version 8.5 and beyond address this
limitation. Cisco added an option in the UCM “SIP profile” which is
applied to the VZ SIP trunk via a check box “Early Offer support for voice
and video calls (insert MTP if needed)”

Unexpected impact: We believe that CPU on the CUBE router may not be
an issue as currently CPU does not go above 30% on JSQ CUBE but we don’t know
for sure if this may be an issue. Also, the IOS MTP resources of the CUBE
will be utilized and we are confident this will not be an issue but cannot be
100% sure about this.

Expected Impact: As we know, when making a change to a SIP trunk, a
reset of the trunk is needed. A SIP trunk reset will disconnect/drop all
active calls. I suggest that we make this change on our JSQ SIP Trunk
first.

Abbas Hussain · ‎04-04-2014

Hi

Did you set Redirecting Diversion Header Delivery – Inbound and Outbound in SIP trunk.

Thanks

keglass · ‎04-04-2014

Peter,

Welcome to the Cisco Collaboration Community. I recommend you also post this issue to the Cisco Support Forum for additional feedback.

Cisco Technical Support Forum

We look forward to hearing from you again.

Kelli Glass

Moderator for the Cisco Collaboration Community