Incorrect Caller ID when transferring external calls - CUCM

[Steve Baker]

We have just migrated from ISDN30 to SIP. For the most part everything appears to work correctly however we have encountered an issue when transferring calls.

1. External call comes in to extension 3000 and caller ID is displayed correctly.

2. Extension 3000 transfers the call to extension 4000. Extension 4000 receives the call but Caller ID is displayed as extension 4000, not the external number of the caller.

All external calls that are transferred appear this way so it looks as if the user has dialed themselves. This only happens for external calls that are transferred. Internal transfers are fine.

Any ideas what could be causing this?

CUCM version 10.5

SIP calls via CUBE

[Abhay Singh Reyal]

Kindly share the show run and debugs ccsip messages. Also for the sip trunk if the Redirecting Diversion Header Delivery - Inbound  is checked or not. If not, check this check box and save it. See if this makes any difference or not.

Check this check box to accept the Redirecting Number in the incoming INVITE message to the Cisco Unified Communications Manager.
Uncheck the check box to exclude the Redirecting Number in the incoming INVITE message to the Cisco Unified Communications Manager.
The default value for Redirecting Number IE Deliver - Inbound specifies not checked.

Regards

Abhay

[Steve Baker]

Hi Abhay,

I tried it with Redirecting Diversion Header ticked and un-ticked but unfortunately it made no difference.

Attached is the show run and debug. Call was from 07786251277 to extension 4343 and I transferred to extension 4870.

Thanks

Steve

[Steve Baker]

With files this time!

[Mohammed al Baqari]

Hi, can you please attach a snapshot of your SIP trunk configuration? Is 4343 SIP or SCCP phone? If its SIP phone, please attach a snapshot of SIP Profile as well. 

[Steve Baker]

Hi,

4343 is an SCCP phone, logged in via extension mobility. Screenshots of SIP trunk attached.

[Steve Baker]

We managed to find a fix by adding the following on the CUBE under voice service

#no update-callerid 

[Steve Baker]

Any more thoughts on this?

We've found with further testing that it is only the final part of the transfer where the caller ID is lost.

1. Call comes in to extension 4343 from 07786251277. External number is displayed correctly.

2. Extension 4343 answers the call then presses transfer and dials extension 4870.

3. Extension 4870 receives the call. Incoming call is displayed as being from 4343.

4. Extension 4343 presses transfer again to complete the call transfer.

5. Extension 4870 now shows the call as coming from extension 4870. It should be showing         as from the mobile number.

[robert3kennedy]

WE came across this issue as well.

We found that adding midcall signalling passthru media-change under voice-service-voip -> sip allowed the CLID present correctly to the final leg of the call,

However this command then started causing issues with calling externally to some other 3rd parties.  The command was removed and no update-callerid was added. 

The CLID now presents as expected

External -> DN1 (CLID EXTERNAL) ->XFER TO DN2 (CLID DN1 during inital transfer then External once transfer complete)

[Gengad]

Hello Rebort,

I am also facing issue calling certain 3rd party phones, Can you please confirm if this is command what is causing the problem "midcall-signaling passthru"? Like some of my call forward number do work and some don't. Look at the debug below;

INVITE sip:+415XXXXXXXX@10.4.8.102:5060;user=phone;nt_info=proxy SIP/2.0
Via: SIP/2.0/UDP 138.187.57.135:5060;branch=z9hG4bKmk8177007o4lvsp1bg00.1
From: <sip:+97XXXXXXXXXX@138.187.57.135;user=phone>;tag=17575036
To: "+415XXXXXXXX"<sip:+415XXXXXXX@10.4.8.102:5060;user=phone;nt_info=proxy>
Call-ID: e639d9db367e1c9e85c44dcb480468c9d863e4@10.83.8.11
CSeq: 1 INVITE
Content-Type: application/sdp
Contact: <sip:+97XXXXXXXXX@138.187.57.135:5060;nt_end_pt=YM0+~KW9k1E5w4Q3QQn~F1.rCJ7ztae9~KIi60~EuNSr~PhpEXk~P63rfeHde.584~M.q~Nv2scid~Nzio62GQi91-0400zfo6~S4AJ;nt_server_host=10.83.8.8:5060;transport=udp>
User-Agent: Nortel SESM 19.0.4.0
Accept: application/sdp
Expires: 330
Max-Forwards: 26
Supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,x-nortel-sipvc,gin,100rel,timer,histinfo,replaces
Allow: INVITE,ACK,BYE,CANCEL,INFO,PRACK,REFER,SUBSCRIBE,NOTIFY,UPDATE
History-Info: <sip:+415XXXXXXXX@pstn.in:5060;user=phone;nt_info=proxy;sid=769380>;index=1,<sip:a_671511@10.83.8.25:5060;transport=udp;physicalsite=Site2;linkname=csbc2>;index=1.1;rc=1
Min-SE: 1800
P-Early-Media: supported
Content-Length: 308

v=0
o=genband 325373952 1527894611 IN IP4 138.187.57.135
s=-
e=unknown@invalid.net
c=IN IP4 138.187.57.135
t=0 0
m=audio 52146 RTP/AVP 8 0 13 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:on - - - -
a=ptime:20

I have no vad turned on on my dial peer or anywhere else.

Please do let me know if "no update-callerid" solves this problem?

[robert3kennedy]

The issue that we had after the changes was with an off-net 3rd party providers network.  Not with a 3rd party phone.

After months of searching around we eventually found out that there was a change inside our sip provider platform that cause this issue to be aparrent, in the route it took from the sip network to the 3rd party provider in question.  We were merely working out a workaround for their change.