'leg progress' has no effect

Version 1

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 27-04-2012 02:58:30 PM
    Have u try this ? Not quite remember, long long time ago people talking about issue with or without -p

    leg progress leg_incoming 1

    Apr 27 20:55:44.056 CEST: //3076//TCL :/tcl_PutsObjCmd: leg state lg_001
    Apr 27 20:55:44.056 CEST: //3076//AFW_:/AFW_FSM_Drive: Tcl_Eval to drive FSM inside Tcl modulespace. code=1 code=ERROR
    Apr 27 20:55:44.056 CEST: TCL script failure
            Result:
                             Illegal Option `?'
    Apr 27 20:55:44.056 CEST:       TCL script failure errorInfo:
                            Illegal Option `?'
        while executing
    "leg progress leg_incoming $stringPI
     
    Is there anybody from Cisco will to verify this problem ?

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 27-04-2012 03:44:27 PM
    interface BRI0/0/0
    no ip address
    isdn switch-type basic-net3
    isdn tei-negotiation preserve
    isdn point-to-point-setup
    isdn incoming-voice voice
    isdn outgoing ie progress-indicator

    dial-peer voice 686327991 pots
    service test
    incoming called-number 686327991

    vg-bws-rome-1a#sh deb
    The following ISDN debugs are enabled on all DSLs:
    debug isdn error is             ON.
    debug isdn q931 is              ON.   (filter is OFF)
    CCAPI:
      debug voip ccapi inout is ON (filter is OFF)
      debug voip application tcl commands is ON (filter is OFF)

    Apr 27 21:42:21.296 CEST: ISDN BR0/0/0 Q931: RX <- SETUP pd = 8  callref = 0x6E
            Bearer Capability i = 0x9090A3
                    Standard = CCITT
                    Transfer Capability = 3.1kHz Audio
                    Transfer Mode = Circuit
                    Transfer Rate = 64 kbit/s
            Channel ID i = 0x89
                    Exclusive, B1
            Calling Party Number i = 0x2183, '21111'
                    Plan:ISDN, Type:National
            Called Party Number i = 0xA1, '686327991'
                    Plan:ISDN, Type:National
            Sending Complete
    Apr 27 21:42:21.296 CEST: //-1/F0780581819B/CCAPI/cc_api_display_ie_subfields:
       cc_api_call_setup_ind_common:
       cisco-username=
       ----- ccCallInfo IE subfields -----
       cisco-ani=021111
       cisco-anitype=2
       cisco-aniplan=1
       cisco-anipi=0
       cisco-anisi=3
       dest=686327991
       cisco-desttype=2
       cisco-destplan=1
       cisco-rdie=FFFFFFFF
       cisco-rdn=
       cisco-rdntype=-1
       cisco-rdnplan=-1
       cisco-rdnpi=-1
       cisco-rdnsi=-1
       cisco-redirectreason=-1   fwd_final_type =0
       final_redirectNumber =
       hunt_group_timeout =0

    Apr 27 21:42:21.300 CEST: //-1/F0780581819B/CCAPI/cc_api_call_setup_ind_common:
       Interface=0x31869A7C, Call Info(
       Calling Number=021111,(Calling Name=)(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed),
       Called Number=686327991(TON=National, NPI=ISDN),
       Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
       Incoming Dial-peer=686327991, Progress Indication=NULL(0), Calling IE Present=TRUE,
       Source Trkgrp Route Label=ti, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1
    Apr 27 21:42:21.300 CEST: //-1/F0780581819B/CCAPI/ccCheckClipClir:
       In: Calling Number=021111(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed)
    Apr 27 21:42:21.300 CEST: //-1/F0780581819B/CCAPI/ccCheckClipClir:
       Out: Calling Number=021111(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed)
    Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

    Apr 27 21:42:21.300 CEST: :cc_get_feature_vsa malloc success
    Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

    Apr 27 21:42:21.300 CEST:  cc_get_feature_vsa count is 1
    Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

    Apr 27 21:42:21.300 CEST: :FEATURE_VSA attributes are: feature_name:0,feature_time:729184312,feature_id:3491
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_api_call_setup_ind_common:
       Set Up Event Sent;
       Call Info(Calling Number=021111(TON=National, NPI=ISDN, Screening=Network, Presentation=Allowed),
       Called Number=686327991(TON=National, NPI=ISDN))
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_process_call_setup_ind:
       Event=0x2C0167C8
    Apr 27 21:42:21.300 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
       Try with the demoted called number 686327991
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallSetContext:
       Context=0x2B768D84
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_process_call_setup_ind:
       >>>>CCAPI handed cid 3081 with tag 686327991 to app "_ManagedAppProcess_test"
    Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_LegObjCmd:  leg progress leg_incoming -p 1
    Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_LegProgressObjCmd: progress leg_incoming -p 1
    Apr 27 21:42:21.300 CEST: //3081//AFW_:/vtd_lg_incoming: argc 4
    Apr 27 21:42:21.300 CEST: //3081//AFW_:/vtd_lg_incoming: Legs [3081 ]
    Apr 27 21:42:21.300 CEST: //3081//Tcl :/tcl_parseCallID_vartagObj: VARTAG Translation Leg Count=1
    Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_LegProgressObjCmd: prog ind=1
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallCutProgress:
       Progress Indication=NOT END TO END ISDN(1), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0
       Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallCutProgress:
       Call Entry(Responsed=TRUE)
    Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_CallObjCmd:  call close
    Apr 27 21:42:21.300 CEST: //3081//TCL :/tcl_CallCloseObjCmd:  close
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallDisconnect:
       Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallDisconnect:
       Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/cc_api_get_transfer_info:
       Transfer Number Is Null
    Apr 27 21:42:21.304 CEST: //3081/F0780581819B/CCAPI/cc_api_call_disconnect_done:
       Disposition=0, Interface=0x31869A7C, Tag=0x0, Call Id=3081,
       Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
    Apr 27 21:42:21.304 CEST: //3081/F0780581819B/CCAPI/cc_api_call_disconnect_done:
       Call Disconnect Event Sent
    Apr 27 21:42:21.304 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

    Apr 27 21:42:21.304 CEST: :cc_free_feature_vsa freeing 2B767830
    Apr 27 21:42:21.304 CEST: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

    Apr 27 21:42:21.304 CEST:  vsacount in free is 0
    Apr 27 21:42:22.188 CEST: ISDN BR0/0/0 **ERROR**: L3_Go: Multi nlcb DL_EST, cid 0x41E cr 0xEE ev 0x300 ces 1
    Apr 27 21:42:22.188 CEST: ISDN BR0/0/0 Q931: TX -> RELEASE_COMP pd = 8  callref = 0xEE
            Cause i = 0x8090 - Normal call clearing
    This document was generated from CDN thread

    Created by: Tomas Ussher on 27-04-2012 12:27:57 PM
    I'm trying to play a message to an ISDN caller before conection to avoid caller being billed.
     
    For that I'm using ' leg progress' as per documentation.
    However, observing debug isdn q931, no progress message is ever sent, I have tried many combinations of code and router configuration.
    I can send and set PI of choice with any ISDN message type, but cannot send PROGRESS at all.
    Why ?
     
    This is the minal script that reproduces the problem:
     
    proc setup {}{
      leg progress leg_incoming -p 1
     call close
    }
    set fsm(INIT,ev_setup_indication)  "setup same_state"
    fsm define fsm INIT

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 27-04-2012 12:56:39 PM
    Document also says that:
    If a call proceeding message has already been sent, this command is ignored. If IVR debugging is
    on (see the “Testing and Debugging Your Script” section on page 2-8), the command that has been
    ignored is displayed.

    Check leg state
    set legState [infotag get leg_state $legID]

    http://developer.cisco.com/web/vgapi/blogroll/-/blogs/tcl-ivr-api-undocumented-status-code?_33_redirect=http%3a%2f%2fdeveloper.cisco.com%2fweb%2fvgapi%2fblogroll%2f-%2fblogs%3f_33_advancedSearch%3dfalse%26_33_cur%3d3%26_33_keywords%3d%26_33_delta%3d5%26_33_andOperator%3dtrue

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 27-04-2012 12:59:55 PM
    In my case, as the code example shows, no call proceeding message has already been sent.
     
    leg_state is lg_001 (LEG_INCOMING_FIRST)
     
    Can you try my example script on you system, anvd verify if PROGRESS is being sent or not ?

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 27-04-2012 01:05:22 PM
    Can you please try to get leg state ? In this case we can know what IOS should respond.
    Sorry I don't have ISDN line to try.

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 27-04-2012 01:07:55 PM
    Leg state added in my post above.

    Anybody from Cisco able to test this ? Can use routers back-to-back, no need for actual circuits.

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 27-04-2012 01:14:59 PM
    In this case proceeding is not sent and usually we want to do
    leg setupack leg_incoming
    leg proceeding leg_incoming
    before doing
      leg connect leg_incoming

    Did you try
    leg setupack leg_incoming
    before progress ?

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 27-04-2012 01:38:37 PM
    In this case proceeding is not sent and usually we want to do
    leg setupack leg_incoming
    leg proceeding leg_incoming
    before doing
      leg connect leg_incoming

    Did you try
    leg setupack leg_incoming
    before progress ?


     
    I cannot do leg setupack, because from documentation and also verified:
     
    Note The ISDN state machine actually connects the incoming call on a setup acknowledgement
     
    furthermore, PROGRESS after CONNECT is not allowed in ISDN.
    I do not want connection to complete. I want to send a PROGRESS message as per documentation.
     
    Can you tell me how to do that ?

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 27-04-2012 02:03:24 PM
    Is there a the following CLI in dialpeer ?

    progress_ind alert enable ...

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 27-04-2012 02:11:56 PM
    The progress_ind commands ONLY apply to outgoing dial-peer.
    This command sets the progress indicator only in messages from outbound dial peers that have a set destination pattern, configured by using the destination-pattern command

    Since scripts are triggered from incoming dial-peers, the command is not available and not applicable.

    Furthermore, I am able to generate ALERT message no problem, and attach a PI to it.

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 27-04-2012 02:25:12 PM
    Have u try this ? Not quite remember, long long time ago people talking about issue with or without -p

    leg progress leg_incoming 1

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 27-04-2012 03:21:39 PM
    Can you please collect
    deb voip app tcl
    deb voice ccapi inout

    will ask someone take a look

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 04-05-2012 02:16:48 PM
    Can you please collect
    deb voip app tcl
    deb voice ccapi inout

    will ask someone take a look

     
    Any update?
    Any hope to be able to do what the documentation promises ?

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 07-05-2012 01:01:56 PM
    I haven't received any response, from the log looks like you're using BRI is that right ?

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 07-05-2012 01:19:20 PM
    Just Got some feedback:

    Application is sending progress to underlying signaling stack:

    Apr 27 21:42:21.300 CEST: //3081/F0780581819B/CCAPI/ccCallCutProgress:
       Progress Indication=NOT END TO END ISDN(1), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0
       Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)

    We don’t know if signaling stack ignores it.

    Adding signaling team to this thread.



    So at least from API point of view there is not thing wrong, let's wait for more feedback

    Subject: RE: 'leg progress' has no effect
    Replied by: Yaw-Ming Chen on 07-05-2012 03:04:16 PM
    Another feedback:


    "I think the general order is

    leg proceeding leg_incoming
    leg setupack leg incoming


    If setupack and progress does not work  for them, please try

    leg alert leg_incoming –p <prog_ind>"

     
    Instead of progress, please try alert

    Subject: RE: 'leg progress' has no effect
    Replied by: Tomas Ussher on 10-05-2012 02:47:08 AM
    Another feedback:


    "I think the general order is

    leg proceeding leg_incoming
    leg setupack leg incoming


    If setupack and progress does not work  for them, please try

    leg alert leg_incoming –p <prog_ind>"

     
    Instead of progress, please try alert

     
    I did try, the PI is actually sent, however the calling party hears ringback and not the prompt being played to leg_incoming.
    I'm sure that to open the audio channel, progress has to be sent.
     
    Again: cannot use leg setup_ack as it would connect the call and I don't want that.