09-24-2014 01:39 PM - edited 03-17-2019 12:17 AM
Hi all,
I am doing a new CUCM setup and am having issues with Forward Busy External and Forward No Answer External. Forward Busy Internal and Forward No Answer Internal work just fine. Even the forward all to Voicemail also works when calls come from external numbers. In the DN configuration everything has been setup to go to voicemail with the correct CSS.
Calls coming in via Analog lines go to voicemail without any problem. Its only ths SIP calls that are not working.
I have been stuck on this for days now, any help is greatly appreciated.
Please see the attached debug ccsip message. In the debug 5344 in the internal number and 5943 is the external number.
Thanks,
AJ
Solved! Go to Solution.
10-03-2014 02:48 AM
Hello Deji,
The issue is with Inbound calls from ITSP not forwarding to voicemail.
so my point was, when CUBE sending the 1st invite to CUCM, allowed headers field will not have the UPDATE and hence CUCM should not send the UPDATE to CUBE instead expecting ReINVITE from CUCM.
10-03-2014 02:57 AM
Suresh (+5) Excellent idea and thanks for reminding me how dull I can be sometimes..Lol. I am glad I asked, atleast I am a lot wiser now.
10-03-2014 07:26 AM
Hi Deji,
Thanks so much for your support. I really appreciate you helping with this and pointing me in the right direction. I even spoke with the ITSP and suggested what you suggested and they agreed that the problem is on their side and they are working on fixing it.
Again, you are just brilliant. You really do have great skills and knowledge of the technology. Thanks for sharing.
Regards,
AJ
10-03-2014 07:22 AM
Hi Suresh,
You solution did the trick. I applied the sip profile and no more UPDATE messages going to the ITSP.
This is plain and simple brilliant. I cannot thank you enough for your help. Even TAC was not able to provide any solution. I cannot tell you how many sleepless nights I have spent because of this.
Have a great day!!!
Regards,
AJ
05-20-2015 11:34 AM
Hi,
This is a simple and great solution.
Thank you for sharing the knowledge.
10-03-2014 03:14 AM
Hi just to add to the thread..
According to RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method
If a UA receives a non-2xx final response to a UPDATE, the session
parameters MUST remain unchanged, as if no UPDATE had been issued.
Note that, as stated in Section 12.2.1 of RFC 3261 [1], if the non-
2xx final response is a 481 (Call/Transaction Does Not Exist), or a
408 (Request Timeout), or no response at all is received for the
UPDATE (that is, a timeout is returned by the UPDATE client
transaction), the UAC will terminate the dialog.
This confirms that it is the UPDATE that is causing the issue as your provider is sending a 481 and hence CUBE terminates the call..
Try and implement Suresh's suggestion and let us know how it goes.
10-04-2014 03:56 AM
This thread tells how this forum is blessed with great minds.
I am curious to test a change in UPDATE message , i know this might work or might not but it will satisfy my mind. :)
AJ,
Can you configure this sip profile on the outbound dial-peer towards ITSP. You can disable sip profile 100 which Suresh suggested just for the time being.
voice class sip-profiles 101
request UPDATE sip-header To modify "@bvoice.primus.ca" "@209.183.11.198"
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide