External to External transfer not updating Caller ID

[rynard.coetzee]

Hi All

I have a scenario where an External caller calls in via the SIP trunk to CUCM ,the call then gets transferred from the Internal phone to another External phone. Problem is that the calling number that shows on the external callers phone is the number of the Internal phone and not the original external party.

I have run debugs on the CUBE ,and the only time i see the original External calling number being passed over to the CUBE is in an UPDATE message from CUCM to CUBE ,but that UPDATE never gets sent to ITSP from CUBE.

Any ideas ?

[Roger Kallberg]

Are you passing Diversion header to the ITSP? Either you'd need to set Redirecting Diversion Header Delivery - Outbound on the SIP trunk from CUCM to the SBC or you need to add a Diversion header to the invite sent to the ITSP.

voice class sip-profiles 10
request INVITE sip-header Diversion modify "Diversion:(.*)(<sip:)(.*)(@.*>)" "Diversion: \2+15551234567\4"
request INVITE sip-header Diversion add "Diversion: <sip:+15551234567@<ip of interface towards ITSP>"

Add this to any other SIP profile information you might have and set it on the outbound dial-peer to the ITSP.

[rynard.coetzee]

Hi Roger

Thanks for the reply ,i have "Redirecting Diversion Header Delivery - Outbound" set on the trunk ,although for some reason i do not see this in the SIP messages received on the CUBE.

SIP profiles is definitely an option ,but i will not be able to do a static number in the header like you have done in your example as this is an HCS solution so there are multiple companies using the same dial-peers on the CUBE. Ultimately we would like to fix it for all the clients ,so if i can find a way to include the Diversion header for all diverted calls.

Regards

Rynard

[TONY SMITH]

You're talking about a "transfer".  Does that mean the call gets answered internally, then the internal person makes a new outbound call to the final destination, then commits the transfer?   

I stand to be corrected but I don't think the Diversion headers would apply in this case, the call is not being diverted.

You might want to look instead at why the Update messages that your CUBE receives are not being passed on to the carrier.  Have a look at this document, it mostly discusses Re-Invites rather than Update, but Update is mentioned as well.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-midcall-reinvite.html

[Roger Kallberg]

The number used in the Diversion header in my example is to set a number that belongs to the DID range applied to the SIP connection for the ITSP to allow the number sent in the From and P-Asserted-Identity. As such it has no real tie to the actual call that is sent, it’s use case is to spoof the ITSP to pass actual calling number. We use this for other things than redirects and transfers, for example for toll bypass to be able to either allow it through if the ITSP white lists calls based on calling number and/or to present the original calling number information to the called party.

[rynard.coetzee]

Hi Roger

Yes i understand ,but in my case using one static number in the sip-profile will not work as multiple companies use the same dial-peer on the CUBE ,so that number will change. I have removed the passthru from the SIP config on the CUBE ,and now the UPDATE messages are actually being sent through to the ITSP ,but the issue i have now is that the PAI is being stripped out of the SIP Invite ,although it is received on incoming leg from the CUCM. Trying to figure out if i can include this in the sip-profile on the outgoing dial-peer.

Regards

Rynard

[Roger Kallberg]

If you have the information in the inbound path you should be able to use a copy profile to copy it to the outbound. I’ll dig up a good document about this and pass it along shortly.

[Roger Kallberg]

Have a look at this document, https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html. It contains some really useful information.

[TONY SMITH]

Can you post an example of the Update as received from CUCM, and noting whether the various numbers are correct or not.  And the corresponding Update sent to the carrier.   If the correct number exists in the Update, we may be able to use a profile to copy that into PAI.

And just to labour the point, can you confirm that this is a Transfer.  The incoming call is answered first internally, then a new outbound call made, then finally transferred?   

[rynard.coetzee]

Hi Guys

Thanks for all the help so far ,so you are correct in saying there is no Diversion as it is a transfer ,so we have to rely on the UPDATE message to change the Calling number after the transfer has been Completed. I went ahead and turned off the midcall-signalling passthru on the CUBE and it seems that the UPDATE message is atleast being passed on to the ITSP now. Now i`ll just have to use a copylist to inject the Diversion header into the UPDATE message ,as they will only honour it if it has a Diversion header.

Regards

Rynard