CALLS DROP after FORWARDING, SIP TRUNK with CUBE

[Cisco Kbsl]

Hi All,

We have SIP trunk for our PSTN connctivity with CUBE and CUCM 8.6 Below is the setup

Service Provider-------SIP------>CUBE(2911)--------H323----->CUCM

CUBE is running IOS  Version 15.2(4)M3. Problem is When we do internal (IP Phone to IP Phone) call forwarding (CFA/CFNA) and called that IP Phone from PSTN trough SIP trunk. Call successfully get forwarded to desired IP Phone but imediatly after answering the call it get disconncted. On my trouble shooting I found that when internal call forwarding happens CUBE sends UPDATE SIP Message to Service Provider and imedialy after answering (after SIP OK from CUBE) Service Provider sends us BYE message with Reason: Q.850;cause=47;text="Resource unavailable"

For a normal (non forwarded) PSTN incoming call though SIP trunk works fine

I have attached debug of SIP messages and "ccapi inout" for non forwarded (working) call and not working (forwarded) call

We have complained about this situation to our SP but yet to find solution

Pls guys help me if you have faced and similar cases and know anything we can done from our end

Thanks

[Ayodeji Okanlawon · Accepted solution]

Hi,

I loooked at the traces and the only difference I observed is that one of them had the "UPDATE" method and the other does not. Although your provider correctly responded to the "UPDATE", they later disconnected the call..

Suggestions

1. Find out why they are disconnecting the call

2. Configure your CUBE such that UPDATEs are not sent over to your ITSP..You can use the midcall UPDATE consumption to achive this..but for this to work you need to channe your solution to use sip to sip and not sip to h323..

More details here

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-2mt/cube-midcall-reinvite.html#GUID-46736E71-CA26-4A1C-B927-4FCD80D82851

Please rate all useful posts

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

[Selvarathnam Nadar]

Are you configured the "ip address trusted list" in CUBE

[Cisco Kbsl]

Hi Aokanlawon,

Thanks for your kind response. It helped me a lot

I managed to solve the issue. SP moved the SIP trunk to different switch from their end (ZTE to HUAWEI).

Also I have marked my h323 GW as MTP required. Other wise on call holds occure (call is landed to IVR) there are lot of INVITES send from CUBE to SP. It causes lot of problems, call get dropped after resuming call. Do you have any idea why these INVITES are sent. After marking MTP required I dont see these INVITES and functionality is much smooth

Hi Selvarathnam

Yes I configured the "ip address trusted list" in CUBE.

Thanks

[chrysostomos1980]

Hi

I had the same issue and when i used this command the problem solved

voice service voip

sip

pass-thru content sdp

But as AOK said(5 stars to you AOK) its better to use sip to sip between cube and cucm

Please rate all useful posts 

Regards
Chrysostomos

""The Most Successful People Are Those Who Are Good At Plan B""

[uliesss]

That solution worked for me, THANKS A LOT!!!

[Ayodeji Okanlawon]

This is expected behaviour because when you put a call on hold, there is a break in media path and the only way SIP does that is to send a re-INVITE. This can create problems as most providers dont like it. When ypu enable MTP on the trunk, media is terminated on the MTP device, hence there is never a break in media path. So when you put a call on hold, no re-INVITE is sent out.

Please rate all useful posts

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