cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3579
Views
0
Helpful
16
Replies

PSTN->CUCM->PSTN not sending calling number after transfer call

Hello.

I have mgcp gateway and CUCM. When call is comming to CUCM I answer by internal phone. After this I transfer call to PSTN. When transfer is complete I see calling number of internal phone, but I need to see first calling number of external phone. At PSTN side is Alcatel station.

I checked logs and saw that CUCM didn't send first external number to PSTN-side after transfer call have completed.

What is reason of this?

Thanks in advance.

16 Replies 16

Manish Gogna
Cisco Employee
Cisco Employee

Hi Grigory,

Please check the following points and see if the issue gets cleared.

>> 'Calling Party Selection' setting on the gateway ( PRI ) is set to 'Originator'

>> 'External phone number mask' is configured on the line

>> On the route pattern, 'Use Calling Party's External Phone Number Mask' is checked

>> In the route group, 'Use Calling Party's External Phone Number Mask' set to 'Default'.

HTH

Manish

If this helps, please rate.

What you mean under "'External phone number mask' is configured on the line"?

I want see external number from PSTN after transfer completed. Not mask of phone number.

All other options the same that you wrote.

Hi Grigory,

"'External phone number mask' is a standard config to ensure that ext mask is sent out for normal calls as well, apart from using the other settings as described above for the caller id for transferred / forwarded calls.

Now, in your case we are looking at a transfer scenario. When the user presses transfer it will first put the original caller on hold.  The called party will get dial tone for making an outbound call.  When that call is placed, a SETUP message is sent to the PSTN with the called party's number ( IP phone mask ) as the caller id and not the original calling party.  This is normal and no way to change the behavior.  This is because the initial calling party is the one doing the transfer.  When that user completes the transfer by pressing the transfer button the second time, a NOTIFY message should be sent to the PSTN reflecting the new calling party number. You can run "debug mgcp packets" for a test call to see if the NOTIFY is being sent to the gateway when transfer softkey is being pressed the second time. If you see it then the issue lies probably with the carrier else CUCM traces need to be investigated.

I hope this will explain the scenario that you are running into.

HTH

Manish

I see number from column external phone number mask if I use it under line. But calling number sending in SETUP message.

No NOTIFY message in both situation (with external phone number mask under line and without it).

I have investigated traces of CUCM and didn't find answer. I changed some options in service parameters that can block providing of calling nuber. But problem don't solved.

If I make CFWD at internal Cisco phone in this scheme to external number, external calling number sending is correct.

1111 call to 2222 cfwd 3333 = 3333 see 1111 (correct)

1111 call to 2222 transfer to 3333 = 3333 see 2222 (incorrect) (should see 1111)

call flow:

[PSTN]->GW (mgcp) -call-> CUCM -> IP Phone Cisco (SCCP) -transfer-> CUCM -> GW (mgcp) -> [PSTN]

Can you please share the cucm trace file and corresponding 'debug mgcp packets' for a test call with calling / called party details and the time stamp. I will take a quick look to see if i can find anything. Please share only the file with the relevant call.

Manish

Call from 7777777777 to 3050 (uccx ivr) -> script transfer call to internal number 3796 (3796 see 7777777777) -> blind transfer call to external number 2240 (2240 see 3796).

The same situation with simple transfer.

Debug and trace in attach

Hi Grigory,

I checked the traces, can't see the calling number being updated  there after Transfer softkey is pressed the second time. If the issue is  present even with a normal transfer where UCCX script is not involved  then I would recommend opening a case with TAC unless someone else wants  to look into it further on supportforum.

Manish

Manich, hi.

Thank you for your attention. 

I know about calling number. And yes, it don't work without uccx too. I have not bad skill of work with trace and debug of Cisco equipment and VoIP protocols. I have investigated all logs. Accordingly I opened notes here. I cann't open case in TAC because it's demo test of system.

Amine Nouasri
Level 3
Level 3

Your trace shows that the original called party not being updated as Manish said:

TcpHandle(TCPPid) = 0x(0000159)

Device Name = S0/SU0/DS1-0@GW3825.cisco.com

CallInfo

callingPartyName=''

callingParty=3796

cgpnVoiceMailbox=

alternateCallingParty=

calledPartyName=''

calledParty=2240

cdpnVoiceMailbox=

originalCalledPartyName=''

originalCalledParty=2240 <<<<

originalCdpnVoiceMailbox=

originalCdpnRedirectReason=0

lastRedirectingPartyName=''

lastRedirectingParty=2240

lastRedirectingVoiceMailbox=

lastRedirectingReason=0

callType=2(OutBound)

lineInstance=1

callReference=43961660.

version: 85720014

Have you tried checking Redirecting Number IE Delivery - Outbound on you PRI interface?

Amine, I know it.

Yes, sure. Redirecting Number IE Delivery checked.

Can you post a debug isdn q931?

Amine, hello.

Debug in attach.

This test I made for blind transfer, but for standard transfer situation is the same.

Call flow:

Call from 7777777777 to 3050 (uccx ivr) -> script transfer call to  internal number 3796 (3796 see 7777777777) -> blind transfer call to  external number 2240 (2240 see 3796).

You can see, that after Alerting from CUCM to E1, no new information about first caller (7777777777).

The same situation if I make test without CCX IVR.

Sorry, for some reason I was thinking about a forward all scenario and not a transfer. I believe this is by design and you cannot do anything about.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: