Solved: Call appearance upon transfer from CUE to Operator

mmose · ‎01-22-2010

Folks:

Software Version: 12.4(22)YB1 / CME 7.1

Installer (Installer application) 7.0.2.0
Thirdparty (Service Engine Thirdparty Code) 7.0.2
Bootloader (Primary) (Service Engine Bootloader) 2.1.14
Infrastructure (Service Engine Infrastructure) 7.0.2
CUE Voicemail Language Support (Languages global pack) 7.0.2
Global (Global manifest) 7.0.2
Service Engine license (License for the Service Engine) 2.1.2.0
Auto Attendant (Service Engine Telephony Infrastructure) 7.0.2
Voice Mail (Voicemail application) 7.0.2
Bootloader (Secondary) (Service Engine Bootloader) 2.1.14.0
Core (Service Engine OS Core) 7.0.2
GPL Infrastructure (Service Engine GPL Infrastructure) 7.0.2

Scenario #1 If I transfer a call from one 7960 ext 2812 to another 7960 ext 2820 (non-consultatively), the line appearance on the receiving 7960 first displays the number of the transferring handset (2812), then when the transferred call is answered, the line appearance switches to the CLID number of the originating call. So basically the user at ext 2820, can determine that X2812 transferred a call to them.

Scenario # 2 A caller calls ext 2812 and the party doesn't answer and the call rolls to voice mail. The caller now opts to press "0" for the operator during the voice announcement (system operator has been defined), and the CUE then transfers the call to the designated system operator, the line appearance does not indicate the ext 2812 number but rather the CLID of the originating call

IHAC that would like to have the originating ext number be the line appearance that the operator handset gets, then if answered, the CLID number (just like the scenario #1) Is this possible?

Mark M.

Vladimir Savostin · ‎01-26-2010

Hello Mark,

This is not possible.

Once call is established information of original called number is not preserved on subsequent transfers.

In this case CUE does not pass Diversion: header it received within the forwarded call.

View solution in original post

Vladimir Savostin · ‎01-27-2010

Hello Mark,

Though trust customers is a good habit, if we really need to know was it working or not

this can be reproduced on the old IOS version in lab environment with exaclty same call flow.

It might be that caller was dialing some number which in turn was also has CFA set or operator's number was

and when call arrived at target phone it was shown as forwarded.

View solution in original post

Vladimir Savostin · ‎01-26-2010

Hello Mark,

This is not possible.

Once call is established information of original called number is not preserved on subsequent transfers.

In this case CUE does not pass Diversion: header it received within the forwarded call.

mmose · ‎01-27-2010

Vladimir:

Thanks for taking the time to respond. I kind of understand this answer. What has me confused is the customer insists that the system used to work like senario #1, prior to the upgrade to CME 7.1. I can't say for sure if this was so. I ran some test using debug ccsip message, and found as you said no diversion message between the transfer of the call from the CUE to the CME (i.e.: dial "0" to speak to an operator(X2880)). I did find the following CDR Logging - I assume the transfer from the CUE to the CME is the BXFER log string (2nd entry), which I don't see the Fwder defined

008485: Jan 27 15:09:13.355: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId BC7C0FD6A8C11DFA52EE69EB9A9CFB9, SetupTime 10:09:01.835 EST Wed Jan 27 2010, PeerAddress 2700, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime 10:09:01.885 EST Wed Jan 27 2010, DisconnectTime 10:09:13.355 EST Wed Jan 27 2010, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 425, TransmitBytes 68000, ReceivePackets 406, ReceiveBytes 64483

008486: Jan 27 15:09:13.355: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:BXFER,ft:01/27/2010 10:09:10.663,frs:0,fid:4566,xconsID:,fcid:B3851548A8C11DF80EE001A6DF2C4A0,legID:1323,xrsn:0,xsts:5,Xor:2700,Xee:5857034095,Xto:2880,bguid:B38515480A8C11DF80EE001A6DF2C4A0

008487: Jan 27 15:09:13.355: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:CFNA,ft:01/27/2010 10:09:01.831,frs:0,fid:4563,fcid:B3851548A8C11DF80EE001A6DF2C4A0,legID:1323,frson:3,fdcnt:1,fwder:2811,fwdee:5857034095,fwdto:2700,frm:2811,bguid:B38515480A8C11DF80EE001A6DF2C4A0

008488: Jan 27 15:09:13.355: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:01/27/2010 10:09:01.835,cgn:5857034095,cdn:2700,frs:0,fid:4564,fcid:B3851548A8C11DF80EE001A6DF2C4A0,legID:1323,bguid:B38515480A8C11DF80EE001A6DF2C4A0

008489: Jan 27 15:09:21.311: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId B3851548A8C11DF80EE001A6DF2C4A0, SetupTime 10:09:10.681 EST Wed Jan 27 2010, PeerAddress 2880, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime 10:09:13.321 EST Wed Jan 27 2010, DisconnectTime 10:09:21.311 EST Wed Jan 27 2010, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 0, TransmitBytes 0, ReceivePackets 391, ReceiveBytes 62560

Diversion: <2811>;privacy=off;reason=no-answer;counter=1;screen=no

Mark M.

Vladimir Savostin · ‎01-27-2010

Hello Mark,

Though trust customers is a good habit, if we really need to know was it working or not

this can be reproduced on the old IOS version in lab environment with exaclty same call flow.

It might be that caller was dialing some number which in turn was also has CFA set or operator's number was

and when call arrived at target phone it was shown as forwarded.

mmose · ‎02-03-2010

The word from TAC-

Unfortunately the feature you need is not currently implemented CUE. I

have discussed this case with a few of our experts to be sure nothing

was missed.

The best option at this point is to have your accounts manager file a

feature request so that we can incorporate this in future releases of CUE.