Display info discarder during transfer/handoff to sccp application

Version 1
    This document was generated from CDN thread

    Created by: TASOS PAPADOPOULOS on 11-06-2009 04:24:40 PM
    Hi,
    I would like to have callerID name displayed on every CUCME ephone during incoming calls.
    In my test environment I have used the attached tcl script on a 2811 CUCME with ISDN BRI trunk ports.
     
    I've realized that the display info which have been looked up against a private db and injected by this tcl script during an incoming call, is shown correctly only on the first ephone but lost after transfer to another sccp ephone.  
     
    I've tested this application succesfuly using my 2811 configured as an H323 gateway on a CUCM 6.1 and it works always. Caller Name retained during call life (after transfer/call forward/pickup etc until disconnect).
     
    It seems that display info is lost during handoff/transition from my tcl application to the default sccp application after the transfer.
     
    Is this a known limitation on the CUCME sccp application? Is there any workaround? Have my script any mistake?
     
    Regards,
    Tasos Papadopoulos

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 11-06-2009 06:25:15 PM
    Your script is OK. The display info may lose during handoff/transfer.
     
    Regards,
     
    Yawming
     
     
     

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 12-06-2009 06:13:10 AM
    So, Is there something that I can do to preserve this info during transfer?
     
    Regards,
    T.
     

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: VijayPrasad Neelamegam on 12-06-2009 06:45:01 AM
    I would like you to try with this script first,¿app-h450-transfer.2.0.0.10.zip",you can download using CCO id from the following location.

    http://www.cisco.com/cgi-bin/tablebuild.pl/tclware
    In the above script,the IVR will itself take care of the full call transfer(with displayInfo).
     
    Otherwise if your script wants to do enhanced call transfer,you can try following option

    After the first leg setup(ls_000) before the transfer,just do a handoff to default(gateway).Now the gateway will take care of transfer.So displayInfo also will be preserved.
     
    Thanks
    Vijay

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 14-06-2009 08:35:45 PM
    Hi,
     
    Can you help me more with handoff?
    I've tried to do a handof just after ls_000 but I'm getting unavailable instead of the default application handle. What I'm doing wrong?
     
    Attached is my script and below is the debug output:
     
    156515: Jun 14 23:26:07.113: //14684//TCL :/tcl_LegConnectObjCmd: connect leg_incoming
    156516: Jun 14 23:26:07.113: //14684//AFW_:/vtd_lg_incoming: argc 2
    156517: Jun 14 23:26:07.113: //14684//AFW_:/vtd_lg_incoming: Legs [14684 ]
    156518: Jun 14 23:26:07.113: //14684//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    156519: Jun 14 23:26:07.113: //14684//TCL :/tcl_ConnectionObjCmd:  connection create leg_incoming leg_outgoing
    156520: Jun 14 23:26:07.113: //14684//TCL :/tcl_ConnectionCreateObjCmd: create leg_incoming leg_outgoing
    156521: Jun 14 23:26:07.113: //14684//AFW_:/vtd_lg_incoming: argc 3
    156522: Jun 14 23:26:07.117: //14684//AFW_:/vtd_lg_incoming: Legs [14684 ]
    156523: Jun 14 23:26:07.117: //14684//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    156524: Jun 14 23:26:07.117: //14684//AFW_:/vtd_lg_outgoing: argc 3
    156525: Jun 14 23:26:07.117: //14684//AFW_:/vtd_lg_outgoing: Legs [14685 ]
    156526: Jun 14 23:26:07.117: //14684//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    156527: Jun 14 23:26:07.117: //14684//TCL :/tcl_PutsObjCmd: Handoff to default application...
    156528: Jun 14 23:26:07.117: //14684//TCL :/tcl_InfotagObjCmd:  infotag get mod_handle_service Default
    156529: Jun 14 23:26:07.117: //14684//TCL :/tcl_InfotagGetObjCmd: infotag get mod_handle_service Default
    156530: Jun 14 23:26:07.117: //14684//AFW_:/vtr_mod_handle_service:
    156531: Jun 14 23:26:07.117: //14684//TCL :/tcl_HandoffObjCmd:  handoff appl leg_incoming unavailable Here is the arg
    156532: Jun 14 23:26:07.117: //14684//TCL :/tcl_handoff_common: appl leg_incoming unavailable Here is the arg
    156533: Jun 14 23:26:07.117: //14684//AFW_:/vtd_lg_incoming: argc 4
    156534: Jun 14 23:26:07.117: //14684//AFW_:/vtd_lg_incoming: Legs [14684 ]
    156535: Jun 14 23:26:07.117: //14684//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    156536: Jun 14 23:26:07.121: //-1//AFW_:/AFW_Module_ParseHandle: strModuleHandle unavailable
    156537: Jun 14 23:26:07.121: //-1//AFW_:/AFW_Module_ParseHandle: ERROR: Separator not found
    156538: Jun 14 23:26:07.121: //14684//TCL :/tcl_handoff_common: Handing off Legs [14684 ] to unavailable with args=Here is the arg
    156539: Jun 14 23:26:07.121: //14684//AFW_:/AFW_FSM_Drive: Tcl_Eval to drive FSM inside Tcl modulespace. code=1 code=ERROR
    156540: Jun 14 23:26:07.121: TCL script failure
            Result:
                             expected integer but got "unavailable"Invalid Leg ID in List: unavailableIllegal Info Tag or not a Leg List: unavailableIllegal Parameter: Connection is in the middle of conference/unconference
    156541: Jun 14 23:26:07.121:    TCL script failure errorInfo:
                            expected integer but got "unavailable"Invalid Leg ID in List: unavailableIllegal Info Tag or not a Leg List: unavailableIllegal Parameter: Connection is in the middle of conference/unconference
        while executing
    "handoff appl leg_incoming [infotag get mod_handle_service Default] "Here is the arg""
        (procedure "act_SetupDone" line 24)
        invoked from within
    "act_SetupDone"                   
    156542: Jun 14 23:26:07.121: //-1//AFW_:/AFW_ExecEnv_CallClose:  Exec Env state: 1
    156543: Jun 14 23:26:07.121: //-1//AFW_:/AFW_ExecEnv_CallClose:  Terminating ExecEnv's root module
    156544: Jun 14 23:26:07.121: //14684//AFW_:/AFW_M_TclModule_Terminate:  Module is in the state: ACTIVE
    156545: Jun 14 23:26:07.121: //14684//AFW_:/AFW_TclModule_Cleaner: lastFailureCause 0
    156546: Jun 14 23:26:07.121: //14684//AFW_:/AFW_TclModule_Cleaner: lastFailureCause 0
    156547: Jun 14 23:26:07.145: //-1//Call:HN9B7095F8:/AFW_M_CallSetup_Free: 
    156548: Jun 14 23:26:07.149: //14684//AFW_:/AFW_M_TclModule_Action:

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: VijayPrasad Neelamegam on 15-06-2009 05:02:11 AM
    Hi,
     
    Kindly try this handoff API
     
    handoff appl leg_incoming default "Here is the arg"
     
    Hope this helps
     
    Thanks
    Vijay

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 15-06-2009 12:08:40 PM
    Hi Vijay and thanks for your help.
     
    I've tried with:
    handoff appl leg_incoming default "Here is the arg"
     
    and I have the following output:
     
    194881: Jun 15 15:06:48.087: //15180//AFW_:/vtd_lg_incoming: argc 3
    194882: Jun 15 15:06:48.087: //15180//AFW_:/vtd_lg_incoming: Legs [15180 ]
    194883: Jun 15 15:06:48.087: //15180//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    194884: Jun 15 15:06:48.087: //15180//AFW_:/vtd_lg_outgoing: argc 3
    194885: Jun 15 15:06:48.087: //15180//AFW_:/vtd_lg_outgoing: Legs [15181 ]
    194886: Jun 15 15:06:48.087: //15180//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    194887: Jun 15 15:06:48.087: //15180//TCL :/tcl_PutsObjCmd: Handoff to default application...
    194888: Jun 15 15:06:48.087: //15180//TCL :/tcl_HandoffObjCmd:  handoff appl leg_incoming default Here is the arg
    194889: Jun 15 15:06:48.087: //15180//TCL :/tcl_handoff_common: appl leg_incoming default Here is the arg
    194890: Jun 15 15:06:48.087: //15180//AFW_:/vtd_lg_incoming: argc 4
    194891: Jun 15 15:06:48.091: //15180//AFW_:/vtd_lg_incoming: Legs [15180 ]
    194892: Jun 15 15:06:48.091: //15180//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    194893: Jun 15 15:06:48.091: //-1//AFW_:/AFW_Module_ParseHandle: strModuleHandle default
    194894: Jun 15 15:06:48.091: //-1//AFW_:/AFW_Module_ParseHandle: ERROR: Separator not found
    194895: Jun 15 15:06:48.091: //15180//TCL :/tcl_handoff_common: Handing off Legs [15180 ] to default with args=Here is the arg
    194896: Jun 15 15:06:48.091: //15180//AFW_:/AFW_FSM_Drive: Tcl_Eval to drive FSM inside Tcl modulespace. code=1 code=ERROR
    194897: Jun 15 15:06:48.091: TCL script failure
            Result:
                             expected integer but got "default"Invalid Leg ID in List: defaultIllegal Info Tag or not a Leg List: defaultIllegal Parameter: Connection is in the middle of conference/unconference
    194898: Jun 15 15:06:48.091:    TCL script failure errorInfo:
                            expected integer but got "default"Invalid Leg ID in List: defaultIllegal Info Tag or not a Leg List: defaultIllegal Parameter: Connection is in the middle of conference/unconference
        while executing
    "handoff appl leg_incoming default "Here is the arg""
        (procedure "act_SetupDone" line 24)
        invoked from within
    "act_SetupDone"                                                                
    194899: Jun 15 15:06:48.091: //-1//AFW_:/AFW_ExecEnv_CallClose:  Exec Env state: 1
    194900: Jun 15 15:06:48.091: //-1//AFW_:/AFW_ExecEnv_CallClose:  Terminating ExecEnv's root module
    194901: Jun 15 15:06:48.091: //15180//AFW_:/AFW_M_TclModule_Terminate:  Module is in the state: ACTIVE
    194902: Jun 15 15:06:48.091: //15180//AFW_:/AFW_TclModule_Cleaner: lastFailureCause 0
    194903: Jun 15 15:06:48.091: //15180//AFW_:/AFW_TclModule_Cleaner: lastFailureCause 0
    194904: Jun 15 15:06:48.115: //-1//Call:HN9ECDD238:/AFW_M_CallSetup_Free: 
     
    Regards,
    Tasos

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: JASMINE KALAISELVAN on 16-06-2009 05:10:18 AM
    Please issue "handoff appl leg_all default" once you get "ls_000". The API was used wrongly previously and thats the reason for the TCL failure.

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 16-06-2009 06:58:04 AM
    I've changed my scipt (attached) and the handoff now is succesful but again with no displayinfo after call transfer (which is handled by Default Application). Attached is a full log for an incoming call from 6974453553 to 954 which correctly display callername. After the handof a call is transfered to 127 (by Default application) and the display info with caller name is lost. 
     
    Am I doing something wrong?
     
    Thanks and Regards,
    Tasos

    Subject: RE: Display info discarder during transfer/handoff to sccp application
    Replied by: VijayPrasad Neelamegam on 16-06-2009 10:20:13 AM
    Hi,
     
    I have checked this issue in my local lab,I am able to see the displayInfo after the transfer.
     
    You can try this with a simple script for testing .Remove the other part of code and just do a leg setup after ls_000 handoff to default application.
    If you still face this issue.Kindly raise an SR so that you can get SLA based support.
     
    Thanks
    Vijay
     
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 17-06-2009 04:43:26 PM
    Hi,
     
    I've used the attached simple script which will set a static text (Mynumber) to all incoming calls and making a handoff after ls_000 (returned by succesful leg setup).
    I've made extensive tests and there is no way to see Mynumber as a caller name after a transfer.
    I've realized that I have no problem after a transfer to a SIP endpoint or after a CUE AA scipt return to the operator (AFAIK is SIP signaling).
     
    Are you sure that you are using SCCP in your lab?
     
    Attached is also the full log of a call from 6945453553 to 954 (954 is SCCP endpoint which normally displays caller name). By transferring the call to 127 (another sccp endpoint the callername is lost).
     
    Before raising an SR please tell me what I'm doing wrong.
     
    Regards,
    Tasos

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 17-06-2009 05:39:23 PM
    When you get ls_000 try to query display info
    "infotag get leg_display_info leg_incoming"
    and print it out
    Can we see display info at this moment ?
     
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 17-06-2009 07:36:08 PM
    No wonder you see nothing.
    How about when call just hit the script ? If we query in call setup procedure, after getting ev_setup_indication, can we see it ?
     
    Thanks,
     
    Yawming
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 17-06-2009 07:16:36 PM
    No its lost.
     
    I've inserted the following two lines before handoff command:
     
    ...
    set displayinfo [infotag get leg_display_info leg_incoming]
    puts -nonewline "Handing off to default appl. LEGS: Incoming LEG ID = $legIN; Outgoing LEG ID = $legOUT; displayinfo=$displayinfo"
    handoff appl leg_all default
    ...
    and the debug shows:
     
    802222: Jun 17 22:09:27.749: //-1//AFW_:/AFW_DataList_GetNext: Elem = 0x463C8114, with Instance = 0x4620EDA8, Prev = 0x4A2028AC
    802223: Jun 17 22:09:27.749: //17074//AFW_:/vtr_ev_legs: EVCALLID [17074 17075]
    802224: Jun 17 22:09:27.749: //17074//TCL :/tcl_PutsObjCmd: CallSetupDone status ls_000 leg 17074 17075
    802225: Jun 17 22:09:27.749: //17074//TCL :/tcl_PutsObjCmd: Call Setup succesfull. Preparing to handoff to default application.
    802226: Jun 17 22:09:27.749: //17074//TCL :/tcl_InfotagObjCmd:  infotag get leg_incoming
    802227: Jun 17 22:09:27.749: //17074//TCL :/tcl_InfotagGetObjCmd: infotag get leg_incoming
    802228: Jun 17 22:09:27.753: //17074//AFW_:/vtr_lg_incoming: argc 2
    802229: Jun 17 22:09:27.753: //17074//TCL :/tcl_InfotagObjCmd:  infotag get leg_outgoing
    802230: Jun 17 22:09:27.753: //17074//TCL :/tcl_InfotagGetObjCmd: infotag get leg_outgoing
    802231: Jun 17 22:09:27.753: //17074//AFW_:/vtr_lg_outgoing: argc 2
    802232: Jun 17 22:09:27.753: //17074//TCL :/tcl_InfotagObjCmd:  infotag get leg_display_info leg_incoming
    802233: Jun 17 22:09:27.753: //17074//TCL :/tcl_InfotagGetObjCmd: infotag get leg_display_info leg_incoming
    802234: Jun 17 22:09:27.753: //17074//AFW_:/vtd_lg_incoming: argc 3
    802235: Jun 17 22:09:27.753: //17074//AFW_:/vtd_lg_incoming: Legs [17074 ]
    802236: Jun 17 22:09:27.753: //17074//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    802237: Jun 17 22:09:27.753: //17074//TCL :/tcl_PutsObjCmd: Handing off to default appl. LEGS: Incoming LEG ID = 17074; Outgoing LEG ID = 17075; displayinfo=
    802238: Jun 17 22:09:27.753: //17074//TCL :/tcl_HandoffObjCmd:  handoff appl leg_all default
    802239: Jun 17 22:09:27.753: //17074//TCL :/tcl_handoff_common: appl leg_all default
    802240: Jun 17 22:09:27.753: //17074//AFW_:/vtd_lg_all: argc 3
    802241: Jun 17 22:09:27.753: //17074//AFW_:/vtd_lg_all: Legs [17074 17075 ]
    802242: Jun 17 22:09:27.753: //17074//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=2
    802243: Jun 17 22:09:27.753: //-1//AFW_:/AFW_Module_ParseHandle: strModuleHandle default
    802244: Jun 17 22:09:27.753: //-1//AFW_:/AFW_Module_ParseHandle: ERROR: Separator not found
    802245: Jun 17 22:09:27.753: //17074//TCL :/tcl_handoff_common: Handing off Legs [17074 17075 ] to default with args=
    802246: Jun 17 22:09:27.757: //17074/332D15028839/Hand:/ah_put_in_the_bag:
    802247: Jun 17 22:09:27.757: //17074/332D15028839/Hand:/ah_put_in_the_bag: Bag of Objects: LEG[17074  ][LEG_INCCONNECTED(5)][Cause(0)]
    802248: Jun 17 22:09:27.757: //17074//Hand:/ah_put_in_the_bag: CON[5943   ][CONNECTION_CONFED(2)] {LEG[17074  ][LEG_INCCONNECTED(5)][Cause(0)],LEG[17075  ][LEG_OUTCONNECTED(10)][Cause(0)]}
    802249: Jun 17 22:09:27.757: //17075/332D15028839/Hand:/ah_put_in_the_bag: LEG[17075  ][LEG_OUTCONNECTED(10)][Cause(0)]
    802250: Jun 17 22:09:27.757: //-1//Hand:/ah_handoff:
    802251: Jun 17 22:09:27.757: //-1//Hand:/ah_handoff_core:
     
    Regards,
    T.

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 18-06-2009 08:55:49 AM
    No.
    CallerName does not provided from ISDN pots provider, so after ev_setup_indication I'm setting callInfo structure on my own with appropriate display info and pass it to leg setup. My code after ev_setup_indication is:
     
      set displayinfo [infotag get leg_display_info leg_incoming]
      puts -nonewline "\n Incoming Leg displayinfo=$displayinfo\n "
      puts "\n---- in act_Setup \n"
      set ani [infotag get leg_ani]
      set dnis [infotag get leg_dnis]
      puts "\n---- ANI: $ani\n"                                                                                           
      leg proceeding leg_incoming
      leg progress leg_incoming
      set mytext Mynumber
      set callInfo(rotaryRedirectMode) "REDIRECT"
      set callInfo(displayInfo) $mytext
      set dnis [infotag get leg_dnis]
      puts "\n---- DNIS: $dnis\n"
      fsm setstate CALL
      leg setup $dnis callInfo leg_incoming
     
    and the debug log is below. What I'm doing wrong?
     
    937676: Jun 18 11:49:23.677: //17263//AFW_:/AFW_M_Leg_SetExecEnv: 
    937677: Jun 18 11:49:23.677: //-1//AFW_:EE475F06F0000:/AFW_ExecEnv_IncrPendingCmd:  PendingCmdCount: 1
    937678: Jun 18 11:49:23.677: //-1//AFW_:LP:EE475F06F0000:LG17263:/AFW_M_Object_SetExecEnv: ObjCount: 2, CmdPending 1
    937679: Jun 18 11:49:23.677: //17263//AFW_:/AFW_Object_AddListener: adding Module TclModule as listener
    937680: Jun 18 11:49:23.677: //17263//AFW_:/AFW_M_Leg_GetHandle: Leg handle: LEG_17263
    937681: Jun 18 11:49:23.677: //-1//AFW_:/AFW_DataArray_ElementSet: Adding param: LEG_17263, type: Leg
    937682: Jun 18 11:49:23.677: //-1//AFW_:/AFW_Instance_IncrRefCount: Object: 0x46202B78, Type: Leg, RefCount: 2
    937683: Jun 18 11:49:23.677: //-1//AFW_:EE475F06F0000:/AFW_ExecEnv_AssignCall: Execenv = 0x475F06F0, Leg = 17263, Peer_Tag = 1
    937684: Jun 18 11:49:23.677: //17263//AFW_:/AFW_ExecEnv_SetCallCorID:
    937685: Jun 18 11:49:23.677:  CallCorID is Aw^V^\[^[^QW
    937686: Jun 18 11:49:23.681: //-1//SERV:/AFW_Service_Process_Space:
    937687: Jun 18 11:49:23.681: Process Started
    937688: Jun 18 11:49:23.681: //-1//AFW_:/AFW_Process_Register: ccAppInitialize(name: _ManagedAppProcess_caller)
    937689: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Event_New: Event ID: ev_any_event
    937690: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Class_Allocate: Malloc Data Space: Event(Size=2544)
    937691: Jun 18 11:49:23.685: //-1//AFW_:/AFW_DataList_New: 
    937692: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Class_Allocate: Malloc Data Space: DataList(Size=40)
    937693: Jun 18 11:49:23.685: //17263//AFW_:/AFW_Process_GetCcqEvent: Received
    937694: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Process_GetCcqEvent:   Event[CC_EV_CALL_SETUP_IND(30)] {
    937695: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Process_GetCcqEvent:     EXECENV[0x475F06F0]
    937696: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Process_GetCcqEvent:     LEG[17263][LEG_INIT(0)][Cause(0)]
    937697: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Process_GetCcqEvent:   }
    937698: Jun 18 11:49:23.685: //17263//SSIN:/AFW_SS_MapEvent: 
    937699: Jun 18 11:49:23.685: //17263//AFW_:/AFW_Leg_GetTypeDetail: invalid interface
    937700: Jun 18 11:49:23.685: //-1//SSIN:/AFW_SS_Telephony_MapEvent: 
    937701: Jun 18 11:49:23.685: //-1//AFW_:/AFW_Util_SaveRawMsg: 
    937702: Jun 18 11:49:23.685: //17263/C177969C8857/AFW_:/AFW_Leg_UpdateStats: Updating stats for ID 1B74 type 0
    937703: Jun 18 11:49:23.685: //17263/C177969C8857/AFW_:/AFW_Object_WalkListeners: 
    937704: Jun 18 11:49:23.685: //17263/C177969C8857/AFW_:/AFW_M_Object_ShowListeners: START
    937705: Jun 18 11:49:23.685: //-1//AFW_:/AFW_M_Object_ShowListeners:  
    937706: Jun 18 11:49:23.685: //17263//AFW_:/AFW_M_Module_GetHandle: Module handle: TclModule_475F1CC4_0_2911647372MOD[TclModule_475F1CC4_0_2911647372]  (
    937707: Jun 18 11:49:23.685: //-1//AFW_:/AFW_M_Object_ShowListeners:     LEG[17263][LEG_INCINIT(1)][Cause(0)]
    937708: Jun 18 11:49:23.685: //-1//AFW_:/AFW_M_Object_ShowListeners:   )
    937709: Jun 18 11:49:23.685: //17263/C177969C8857/AFW_:/AFW_M_Object_ShowListeners: END
    937710: Jun 18 11:49:23.685: //17263/C177969C8857/AFW_:/AFW_Object_WalkListeners: Entering Module : TclModule
    937711: Jun 18 11:49:23.689: //17263//AFW_:/AFW_ExecEnv_SetModuleScope: TclModule_475F1CC4_0_2911647372 ---> TclModule_475F1CC4_0_2911647372
    937712: Jun 18 11:49:23.689: //17263//AFW_:/AFW_M_TclModule_Action: 
    937713: Jun 18 11:49:23.689: //17263//AFW_:/AFW_TclModule_DefaultEvHandling: 
    937714: Jun 18 11:49:23.689: //17263/C177969C8857/AFW_:/AFW_Leg_CheckIncomingCallBlock: 
    937715: Jun 18 11:49:23.689: //17263/C177969C8857/AFW_:/AFW_Leg_SettlementValidateCall: target=, tokenp=0x0
    937716: Jun 18 11:49:23.689: //17263/C177969C8857/AFW_:/AFW_Leg_IncomingTranslate: 
    937717: Jun 18 11:49:23.689: //17263//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(CALL_INIT[1],ev_setup_indication[30])---[act_Setup]------
    937718: Jun 18 11:49:23.689: //17263//TCL :/tcl_InfotagObjCmd:  infotag get leg_display_info leg_incoming
    937719: Jun 18 11:49:23.689: //17263//TCL :/tcl_InfotagGetObjCmd: infotag get leg_display_info leg_incoming
    937720: Jun 18 11:49:23.689: //17263//AFW_:/vtd_lg_incoming: argc 3
    937721: Jun 18 11:49:23.689: //17263//AFW_:/vtd_lg_incoming: Legs [17263 ]
    937722: Jun 18 11:49:23.689: //17263//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    937723: Jun 18 11:49:23.689: //17263//TCL :/tcl_PutsObjCmd:
     Incoming Leg displayinfo=
     
    937724: Jun 18 11:49:23.689: //17263//TCL :/tcl_PutsObjCmd:
    ---- in act_Setup
    937725: Jun 18 11:49:23.689:
    937726: Jun 18 11:49:23.689: //17263//TCL :/tcl_InfotagObjCmd:  infotag get leg_ani
    937727: Jun 18 11:49:23.689: //17263//TCL :/tcl_InfotagGetObjCmd: infotag get leg_ani
    937728: Jun 18 11:49:23.689: //17263//AFW_:/vtr_lg_ani: argc 2 argindex 2
    937729: Jun 18 11:49:23.689: //17263//TCL :/tcl_InfotagObjCmd:  infotag get leg_dnis
    937730: Jun 18 11:49:23.689: //17263//TCL :/tcl_InfotagGetObjCmd: infotag get leg_dnis
    937731: Jun 18 11:49:23.689: //17263//AFW_:/vtr_lg_dnis: argc 2 argindex 2
    937732: Jun 18 11:49:23.693: //17263//TCL :/tcl_PutsObjCmd:
    ---- ANI: 6974453553
    937733: Jun 18 11:49:23.693:
    937734: Jun 18 11:49:23.693: //17263//TCL :/tcl_LegObjCmd:  leg proceeding leg_incoming
    937735: Jun 18 11:49:23.693: //17263//TCL :/tcl_LegProceedObjCmd: proceeding leg_incoming
    937736: Jun 18 11:49:23.693: //17263//AFW_:/vtd_lg_incoming: argc 2
    937737: Jun 18 11:49:23.693: //17263//AFW_:/vtd_lg_incoming: Legs [17263 ]
    937738: Jun 18 11:49:23.693: //17263//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    937739: Jun 18 11:49:23.693: //17263//TCL :/tcl_LegObjCmd:  leg progress leg_incoming
    937740: Jun 18 11:49:23.693: //17263//TCL :/tcl_LegProgressObjCmd: progress leg_incoming
    937741: Jun 18 11:49:23.693: //17263//AFW_:/vtd_lg_incoming: argc 2
    937742: Jun 18 11:49:23.693: //17263//AFW_:/vtd_lg_incoming: Legs [17263 ]
    937743: Jun 18 11:49:23.693: //17263//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    937744: Jun 18 11:49:23.693: //17263/C177969C8857/AFW_:/AFW_Leg_GetTypeDetail: invalid interface
    937745: Jun 18 11:49:23.693: //17263//TCL :/tcl_InfotagObjCmd:  infotag get leg_dnis
    937746: Jun 18 11:49:23.693: //17263//TCL :/tcl_InfotagGetObjCmd: infotag get leg_dnis
    937747: Jun 18 11:49:23.693: //17263//AFW_:/vtr_lg_dnis: argc 2 argindex 2
    937748: Jun 18 11:49:23.693: //17263//TCL :/tcl_PutsObjCmd:
    ---- DNIS: 954
    937749: Jun 18 11:49:23.693:
    937750: Jun 18 11:49:23.693: //17263//TCL :/tcl_FSMObjCmd:  fsm setstate CALL
    937751: Jun 18 11:49:23.693: //17263//TCL :/tcl_FSMSetStateObjCmd: setstate setstate CALL
    937752: Jun 18 11:49:23.693: //17263//TCL :/tcl_LegObjCmd:  leg setup 954 callInfo leg_incoming
    937753: Jun 18 11:49:23.697: //17263//CSPK:/tcl_LegSetupObjCmd: leg setup 954 callInfo leg_incoming
    937754: Jun 18 11:49:23.697: //17263//AFW_:/vtd_lg_incoming: argc 4
    937755: Jun 18 11:49:23.697: //17263//AFW_:/vtd_lg_incoming: Legs [17263 ]
    937756: Jun 18 11:49:23.697: //17263//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    937757: Jun 18 11:49:23.697: //-1//AFW_:/AFW_Util_GetTgCicValue: CIC Not  found for tag(56)
    937758: Jun 18 11:49:23.697: //-1//CSPK:/tclSetCallInfoParams: displayInfo=Mynumber
    937759: Jun 18 11:49:23.697: //-1//AFW_:/AFW_ExecEnv_CallProc: CallSetup::Start
    937760: Jun 18 11:49:23.697: //17263//CSPK:/C_CallSetup_Start: ControlInfo = 0x4A5C7008, callInfo = 0x4A704660, destination[0]=954
    937761: Jun 18 11:49:23.697: //17263//PACK:/ParamRead:  Reading param mode from callsetup
    937762: Jun 18 11:49:23.697: //-1//PACK:/ParamRead:  Reading parameter mode for a script callsetup,
    937763: Jun 18 11:49:23.697: //-1//PACK:/ParamRead:     appRegParams=0x4726A88C dpParamArray=0x0 pMainParamArray=0x0
    937764: Jun 18 11:49:23.697: //-1//PACK:/ParamRead:  Parameter for the script: callsetup has been read: mode
    937765: Jun 18 11:49:23.701: //-1//AFW_:/AFW_DataString_Get: 
    937766: Jun 18 11:49:23.701: //17263//CSPK:/C_CallSetup_Start: configured mode=rotary (1)
    937767: Jun 18 11:49:23.701: //17263//PACK:/ParamRead:  Reading param reroutemode from callsetup
    937768: Jun 18 11:49:23.701: //-1//PACK:/ParamRead:  Reading parameter reroutemode for a script callsetup,
    937769: Jun 18 11:49:23.701: //-1//PACK:/ParamRead:     appRegParams=0x4726A88C dpParamArray=0x0 pMainParamArray=0x0
    937770: Jun 18 11:49:23.701: //-1//PACK:/ParamRead:  Parameter for the script: callsetup has been read: reroutemode
    937771: Jun 18 11:49:23.701: //-1//AFW_:/AFW_DataString_Get: 
    937772: Jun 18 11:49:23.701: //17263//CSPK:/C_CallSetup_Start: configured reroutemode=rotary (1)
    937773: Jun 18 11:49:23.701: //-1//Call:/AFW_CallSetup_New: 
    937774: Jun 18 11:49:23.701: //-1//AFW_:/AFW_Class_Allocate: Malloc Data Space: CallSetup(Size=4584)
    937775: Jun 18 11:49:23.701: //-1//AFW_:/AFW_DataArray_New: 
    937776: Jun 18 11:49:23.701: //-1//AFW_:/AFW_Class_Allocate: Malloc Data Space: DataArray(Size=80)
    937777: Jun 18 11:49:23.701: //-1//AFW_:/AFW_FSM_New: 
    937778: Jun 18 11:49:23.701: //-1//AFW_:/AFW_Class_Allocate: Malloc Data Space: FSM(Size=104)
    937779: Jun 18 11:49:23.701: //-1//AFW_:LP:EE475F06F0000:HNAD8C36FC:/AFW_M_Object_SetExecEnv: ObjCount: 3, CmdPending 1
    937780: Jun 18 11:49:23.701: //17263//AFW_:/AFW_ExecEnv_IncrPendingCmd:  PendingCmdCount: 2
    937781: Jun 18 11:49:23.701: //17263//AFW_:/AFW_Object_AddListener: adding Module TclModule as listener
    937782: Jun 18 11:49:23.701: //17263//AFW_:/AFW_M_Module_GetHandle: Module handle: CallSetup_49832A20_0_2911647484
    937783: Jun 18 11:49:23.701: //-1//AFW_:/AFW_DataArray_ElementSet: Adding param: CallSetup_49832A20_0_2911647484, type: CallSetup
    937784: Jun 18 11:49:23.701: //-1//AFW_:/AFW_Instance_IncrRefCount: Object: 0x49832A20, Type: CallSetup, RefCount: 2
    937785: Jun 18 11:49:23.701: //17263//Call:/AFW_CallSetup_AddDest:  954 index 0
    937786: Jun 18 11:49:23.701: //17263//Call:/AFW_CallSetup_SetIntWrkLeg: 
    937787: Jun 18 11:49:23.701: //17263/C177969C8857/AFW_:/AFW_Leg_SignalPeerGet: Leg [17263]
    937788: Jun 18 11:49:23.705: //-1//AFW_:/AFW_ExecEnv_CallProc: Session::GetSigPeer
    937789: Jun 18 11:49:23.705: //-1//AFW_:/C_PackageSession_GetSigPeer:
     
    Regards,
    T.

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: VijayPrasad Neelamegam on 18-06-2009 09:55:26 AM
     
    Can i know the topology you are using for this script?
     
    Thanks
    Vijay

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 18-06-2009 10:26:41 AM
    Physical topo:
    Phone_A--PSTN---2811/CUCMEv7_with_ISDN_BRI---IPPhone_A(
     
    Call Flow Description: 
    Call from Phone_A (6974453553) incoming from ISDN BRI and matched on an incoming pots dial-peer (which have assigned the above mentioned tcl script) ringing in IPPhoneA(954) because its a DDI call. Caller Name which is injected by leg setup as display info is correctly shown in IPPhone_A's screen (Mynumber "6974453553"). Then IPPhoneA transfers the call to the IPPhone B(127). IPPhone B shows only the calling number after transfer completion and the diaplsy info is lost.
     
    My IOS config:
    !
    application
     service caller http://***/number2name.tcl
    !
    interface BRI0/0/0
     no ip address
     isdn switch-type basic-net3
     isdn overlap-receiving
     isdn point-to-point-setup
     isdn incoming-voice voice
     isdn static-tei 0
    !
    voice-port 0/0/0
     translation-profile incoming TP01
     compand-type a-law
     bearer-cap Speech
    !
    dial-peer voice 1 pots
     description *** Incoming PSTN Calls
     service caller
     incoming called-number .
     direct-inward-dial
    !
    ephone-dn  4  dual-line
     number 954 secondary 124
     pickup-group 1
     description Tasos
     name Tasos Papadopoulos
     allow watch
     no huntstop
    !
    ephone-dn  1  dual-line
     number 951 secondary 127
     pickup-group 1
     description Savvas
     name Savvas Karagiannidis
     allow watch
     no huntstop
    !
    ephone  1
     description Savvas
     video
     mac-address 000A.B823.3211
     ephone-template 1
     paging-dn 80
     type 7941GE
     button  1:1 2m24
    !
    ephone  4
     description Tasos 7941
     mac-address 000E.3841.264D
     ephone-template 1
     type 7970
     button  1:4
    !  
     
    #do sh ver
    Cisco IOS Software, 2800 Software (C2800NM-IPVOICEK9-M), Version 12.4(22)T1, RELEASE SOFTWARE (fc5)
    Is the above enough?
     
    Regards,
    T.
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 18-06-2009 03:01:02 PM
    So actullay Tcl script has no problem. display info lost @ the point of destination phone transfering call to other phone.
    Can we say that ? If so, we should focus on the transfering on destintion phone but not Tcl script.
     
    Thanks,
     
    Yawming

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 18-06-2009 03:20:10 PM
    So, What is your proposal?
     
    T.
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 18-06-2009 09:15:49 PM
    Vijay said it worked for him, you need to check if your call scenario is the same as his.
     
    After we get ls_000 we query "infotag get leg_display_info leg_incoming" again and we see it's gone
    If I remember correctly the root cause maybe that :
    the updated caller id or the notify message is sent up to the ephone at ringing state and hence the ephone calling info would be updated accordingly. Means we see the display correctly but after that updated caller id was sent to ephone again. So later when we do the transfer it's gone. 
    This is why I said it before it may got lost during the tranfer, I think call forward should be OK.

    I wonder if we raelly can do it jsut by handiff to IOS.

    Thanks,

    Yawming

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 19-06-2009 04:24:30 AM
    Maybe you can try to add  "leg callerid" command in call setup done

      set param(name) ABC
      set param(number) $ani
      leg callerid leg_outgoing param
     
    Yawming

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 19-06-2009 01:59:21 PM
    I've changed my script as you've proposed just before handoff in SetupDone. The same thing happen (display info lost). See the debug below. It seems that cellerid doesn't have any relation with display info. If I could change display info like changing callerid will be a trick.
    Here is my changed code:
     
    puts -nonewline "Call Setup succesfull. Preparing to handoff to default application."                
    set legIN [infotag get leg_incoming]                                                                 
    set legOUT [infotag get leg_outgoing]                                                                
    set param(name) Mynumber                                                                             
    set param(number) $ani                                                                               
    leg callerid leg_outgoing param                                                                      
    set displayinfoi [infotag get leg_display_info leg_incoming]                                         
    set displayinfoo [infotag get leg_display_info leg_outgoing]                                         
    puts -nonewline "Handing off to default appl. LEGS: Incoming LEG ID = $legIN; Outgoing LEG ID = $legOU
    handoff appl leg_all default         
     
    and this is debug :
     
    1742418: Jun 19 16:32:35.885: //18329//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(CALL[2],ev_setup_done[197])---[act_SetupDone]------
    1742419: Jun 19 16:32:35.885: //18329//TCL :/tcl_InfotagObjCmd:  infotag get evt_status
    1742420: Jun 19 16:32:35.885: //18329//TCL :/tcl_InfotagGetObjCmd: infotag get evt_status
    1742421: Jun 19 16:32:35.885: //18329//AFW_:/vtr_ev_status: argc 2 argindex 2
    1742422: Jun 19 16:32:35.885: //18329//TCL :/tcl_InfotagObjCmd:  infotag get evt_legs
    1742423: Jun 19 16:32:35.885: //18329//TCL :/tcl_InfotagGetObjCmd: infotag get evt_legs
    1742424: Jun 19 16:32:35.885: //18329//AFW_:/vtr_ev_legs: argc 2
    1742425: Jun 19 16:32:35.885: //-1//AFW_:/AFW_DataList_GetFirst: Elem = 0x4A695A14, with Instance = 0x497C253C
    1742426: Jun 19 16:32:35.885: //-1//AFW_:/AFW_DataList_GetNext: Elem = 0x4745D954, with Instance = 0x4620EDA8, Prev = 0x4A695A14
    1742427: Jun 19 16:32:35.885: //-1//AFW_:/AFW_DataList_GetNext: Elem = 0x4A2E1E10, with Instance = 0x46207628, Prev = 0x4745D954
    1742428: Jun 19 16:32:35.885: //18329//AFW_:/vtr_ev_legs: EVCALLID [18329 18330]
    1742429: Jun 19 16:32:35.885: //18329//TCL :/tcl_PutsObjCmd: CallSetupDone status ls_000 leg 18329 18330
    1742430: Jun 19 16:32:35.889: //18329//TCL :/tcl_PutsObjCmd: Call Setup succesfull. Preparing to handoff to default application.
    1742431: Jun 19 16:32:35.889: //18329//TCL :/tcl_InfotagObjCmd:  infotag get leg_incoming
    1742432: Jun 19 16:32:35.889: //18329//TCL :/tcl_InfotagGetObjCmd: infotag get leg_incoming
    1742433: Jun 19 16:32:35.889: //18329//AFW_:/vtr_lg_incoming: argc 2
    1742434: Jun 19 16:32:35.889: //18329//TCL :/tcl_InfotagObjCmd:  infotag get leg_outgoing
    1742435: Jun 19 16:32:35.889: //18329//TCL :/tcl_InfotagGetObjCmd: infotag get leg_outgoing
    1742436: Jun 19 16:32:35.889: //18329//AFW_:/vtr_lg_outgoing: argc 2
    1742437: Jun 19 16:32:35.889: //18329//TCL :/tcl_LegObjCmd:  leg callerid leg_outgoing param
    1742438: Jun 19 16:32:35.889: //18329//TCL :/tcl_LegCallerIDObjCmd: callerid leg_outgoing param
    1742439: Jun 19 16:32:35.889: //18329//AFW_:/vtd_lg_outgoing: argc 3
    1742440: Jun 19 16:32:35.889: //18329//AFW_:/vtd_lg_outgoing: Legs [18330 ]
    1742441: Jun 19 16:32:35.889: //18329//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    1742442: Jun 19 16:32:35.889: //18330/7B475F9288C8/AFW_:/AFW_Leg_SetCallerID: Caller-ID number: [6974453553], name: , time: [06191632]
    1742443: Jun 19 16:32:35.889: //18329//TCL :/tcl_InfotagObjCmd:  infotag get leg_display_info leg_incoming
    1742444: Jun 19 16:32:35.889: //18329//TCL :/tcl_InfotagGetObjCmd: infotag get leg_display_info leg_incoming
    1742445: Jun 19 16:32:35.893: //18329//AFW_:/vtd_lg_incoming: argc 3
    1742446: Jun 19 16:32:35.893: //18329//AFW_:/vtd_lg_incoming: Legs [18329 ]
    1742447: Jun 19 16:32:35.893: //18329//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    1742448: Jun 19 16:32:35.893: //18329//TCL :/tcl_InfotagObjCmd:  infotag get leg_display_info leg_outgoing
    1742449: Jun 19 16:32:35.893: //18329//TCL :/tcl_InfotagGetObjCmd: infotag get leg_display_info leg_outgoing
    1742450: Jun 19 16:32:35.893: //18329//AFW_:/vtd_lg_outgoing: argc 3
    1742451: Jun 19 16:32:35.893: //18329//AFW_:/vtd_lg_outgoing: Legs [18330 ]
    1742452: Jun 19 16:32:35.893: //18329//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    1742453: Jun 19 16:32:35.893: //18329//TCL :/tcl_PutsObjCmd: Handing off to default appl. LEGS: Incoming LEG ID = 18329; Outgoing LEG ID = 18330;
     Incoming Leg displayinfo=
     Outgoing Leg displayinfo=Tasos Papadopoulos
    1742454: Jun 19 16:32:35.893: //18329//TCL :/tcl_HandoffObjCmd:  handoff appl leg_all default
    1742455: Jun 19 16:32:35.893: //18329//TCL :/tcl_handoff_common: appl leg_all default
    1742456: Jun 19 16:32:35.893: //18329//AFW_:/vtd_lg_all: argc 3
    1742457: Jun 19 16:32:35.893: //18329//AFW_:/vtd_lg_all: Legs [18330 18329 ]
    1742458: Jun 19 16:32:35.893: //18329//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=2
    1742459: Jun 19 16:32:35.893: //-1//AFW_:/AFW_Module_ParseHandle: strModuleHandle default
    1742460: Jun 19 16:32:35.897: //-1//AFW_:/AFW_Module_ParseHandle: ERROR: Separator not found

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 19-06-2009 02:01:21 PM
    The same results if I use:
    leg callerid leg_incoming param
    instead of :
    leg callerid leg_outgoing param
     
    Regards,
    T.

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 19-06-2009 02:48:28 PM
    What is you IOS version ?
    Can you please collect trace with "deb voip app all", "deb voip ccapi inout", "deb vpm sig", and "deb ephon det mac <>" enabled ? Running config too.

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 19-06-2009 03:17:01 PM
    I've attached them all in a single file. To the end you can find my conf and a sh ver.
     
    T.

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 24-06-2009 11:50:41 AM
    Hi
    Do you have any suggestion?
     
    Regards,
    Tasos Papadopoulos
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 24-06-2009 04:37:32 PM
    Looks like display info cannot retain by using simple script. I think you have to use H.450 script, may be you can add the dispinfo over there.
     
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: TASOS PAPADOPOULOS on 25-06-2009 06:20:05 PM
    I've used the h450 script and placed display info in act_Setup function before leg setup. It seems that after the transfer the call is handed off to default application and the display info have been lost again to the Xto IP Phone (final leg).
     
    Would you like to suggest me the point in H450 script code to put display info in order to work?
     
    Regards,
    Tasos Papadopoulos
     

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: YAW-MING CHEN on 25-06-2009 09:04:32 PM
    You don't need to try it. I have tried, it's the same. I think Vijay just using H450 script without modifying any DisplayInfo. So I think my first comment still stands. The dispaly info will get lost.
     
    If I can think of any solution get back to this.
    Cheers !

    Subject: RE: Display info discarded during transfer/handoff to sccp application
    Replied by: xxxxx yyy on 15-03-2011 05:27:30 AM
    Hi
    Do you have any suggestion?
     
    Regards,
    Tasos Papadopoulos