Call forward all - not working over SIP trunk

[sjones@techsgi.com]

Hello everyone--i've got a client with a SIP trunk running through CUBE.  Issue we're having is this--when they call-forward-all to an external number, it's sending the original outside calling number, instead of the DID of the Cisco phone.  I'm wondering what to do to overcome this problem, because they'll want the caller-id of the original outside call, not the number of their desk phone.  I haven't had this issue when forwarding over POTS lines or PRIs...

Thanks folks.

[Udit Mehrotra]

Is this a SIP to SIP CUBE or h.323 to SIP CUBE?

On SIP trunk or H.323 gateway page on CM check Calling Party Selection* to Last Redirecting Party..

HTH

Udit

[sjones@techsgi.com]

Sip to sip. I'll look for that setting. Thanks.

Scott A. Jones, CCVP

Iplogic, inc.

Sent from my iPhone

[sjones@techsgi.com]

Wanted to send a quick update--tried setting the 'last calling party' as mentioned below, but it's still not working. Will probably have to open a TAC case on Monday.

Also, the topology is this: CM - SIP - CUBE - SIP - Paetec

Thanks for the help so far folks.

Scott Jones

[paolo bevilacqua]

sjones@techsgi.com
Wanted to send a quick update--tried setting the 'last calling party' as mentioned below, but it's still not working.  Will probably have to open a TAC case on Monday.
Also, the topology is this:  CM - SIP - CUBE - SIP - Paetec
Thanks for the help so far folks.
Scott Jones

Please read my other message - IMHO you can't have original caller ID.

Let us know.

[calmichael · Accepted solution]

I would recommend doing a debug on the CUBE and seeing what number is being shown in the SIP diversion header.

You may need to modify the diversion header to match a DID that PAETEC accepts in 10D format (assuming you are a US customer).

You can do this in a couple of ways, using a SIP profile or a voice translation rule that plays with the redirect; but I understand that newer code may not work with the translation rule.

In a customer case, the diversion only contained four digits which is what the actual station was; but the SIP provider wanted ten digits to allow call forward or SNR/mobility functions to work.

Here is a sample sip profile that takes a 4D diversion header and prepends an area code/exchange to it for a 10D result:

voice class sip-profiles 1
request INVITE sip-header Diversion modify "<>" "<312555>"

I would place these on dial-peers that go towards the SIP provider.

dial-peer voice 011 voip
description RPOUTBOUND CALLING [SIP] 011! INTERNATIONAL
destination-pattern [0][1][1]T
session protocol sipv2
session target ipv4:

voice-class codec 1 
voice-class sip dtmf-relay force rtp-nte
voice-class sip profiles 1

Lastly, did you take a look at the interoperability guides that Cisco has published on CCO? I know PAETEC is one of the documents posted.

Hope this helps.

[sjones@techsgi.com]

That is some great info...i'm still new to SIP, so I keep finding different rules for different providers...i'll check out the redirect though...

As far as the interop guide, I did, but it's based on CM 6 and IOS 12.4...i found some cute little toll-fraud measures and a few other items that the guide didn't cover since it was out of date.

Thanks for the info--I'll post an update/rate if it corrects it.

Scott Jones

[paolo bevilacqua]

they'll want the caller-id of the original outside call, not the number of their desk phone.  I haven't had this issue when forwarding over POTS lines or PRIs...

In the US ISDN PRI users are often allowed to send any arbitrary calling number and it will be accepted,

However, on SIP trunks and PRI via VOIP services, this practice is no more allowed by SPs. So they align with the rest of the world, and overwrite any number to belonging to the customer with the main number.

In other words, your customer can not have the original calling number displayed when doing call forward over SIP trunks.

You can ask for confirmation to the SIP SP.

[anlyons]

Hey Scott,

Just wondering whether you'd got this working yet... I have come across this in loads of HCS deployments I have been involved in recently and to get a proper solution from the CUCM you need to be on 8.6.2 - this is the first release that has a redirecting number CSS on the SIP trunk for exactly this situation.

When you do a cfwd all out to the PSTN, your diversion header (presuming you've got the redirecting outbound header tick box ticked on the SIP trunk) will be in internal format (just your DN) and this causes most SIP SPs (at least here in the UK) to reject the cfwd/SNR call.  Your From header and PAI will contain the original A-number and it will be diversion header that contains the DDI of the IP phone (at least you want it to be the DDI).

In an 8.6.1 CUCM, changing the diversion header from an internal format isn't natively supported... you need to use a SIP normalisation script (aka LUA script) to do number manipulation on your headers.

Thanks,

Andy

[sjones@techsgi.com]

I did actually.  Those are valid points about doing the manipulation in CUCM directly.  I ended up doing it in the CUBE under a SIP profile...example is below.  Another interesting point is for certain carriers (Paetec/Windstream being one of them...), MoH won't work properly unless you modify the invite when you put someone on hold from being a one-way stream to a two-way stream.  the user's audio still doesn't get passed back, but the carrier believes it's normal conversation.

HTH

SJ

voice class sip-profiles 1

request INVITE sip-header Diversion modify "<>" "sip:@>" -- Allow forwarding

request REINVITE sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv" -- These 3 lines are the MoH workaround

response ANY sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv"

request ACK sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv"

[oliverpowell]

Hi Scott,

We have a similar issue with one of our customers. They are wanting to show the original external caller on the forwarded device.

What settings did you apply on the CUCM SIP trunk Outbound Calls?

Specifically Calling Party Selection and Redirecting Diversion Header Delivery - Outbound (checked or not).

Any advice appreciated.

Oli

[Gengad]

Hi Sjones,

I have similar problem,

We have 2 clusters when someone calls from Cluster A to Cluster B Call Forward All to Mobile, the call shows up the main corporate number rather than showing the original caller number or the IP Phone number. I saw how you solved your number, can you please confirm if your command is correct? 

request INVITE sip-header Diversion modify "<>" "sip:@>"

"<>" what do I need to put there or do I leave it empty same for "sip:@>"

Your help will be appreciated.