TCL Dnis

Version 1

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 07-03-2011 12:30:17 PM
    Looks like overlap dialing is used, is that right ?

    What is the value from "infotag get leg_dnis"

    Can you please do

    --------------------------------------------
          set dest [infotag get leg_dnis]

          puts "DEST is : $dest"
    --------------------------------------------
    then turn on  "deb voip app scr" to display the value ?

    You can also try to use en bloc dialing.

    Thanks !
    This document was generated from CDN thread

    Created by: xxxxx yyy on 07-03-2011 09:12:10 AM
    ve got an problem with TCL script, with one part that reads outgoing
    number, if called party number is sent in one part I've been using

    infotag get leg_dnis

    And it returned me this number, when Called Party Number is sent in
    parts I can't read it, could you help me?


    *Mar  7 16:39:12.012: ISDN Se0/3/0:15 Q931: RX <- INFORMATION pd = 8
    callref = 0x010F
           Called Party Number i = 0x81, '1'
                   Plan:ISDN, Type:Unknown
    *Mar  7 16:39:12.192: ISDN Se0/3/0:15 Q931: RX <- INFORMATION pd = 8
    callref = 0x010F
           Called Party Number i = 0x81, '0'
                   Plan:ISDN, Type:Unknown
    *Mar  7 16:39:12.332: ISDN Se0/3/0:15 Q931: RX <- INFORMATION pd = 8
    callref = 0x010F
           Called Party Number i = 0x81, '1'
                   Plan:ISDN, Type:Unknown
    *Mar  7 16:39:12.504: ISDN Se0/3/0:15 Q931: RX <- INFORMATION pd = 8
    callref = 0x010F
           Called Party Number i = 0x81, '0'

    This is example with called party number in parts

    Subject: RE: TCL Dnis
    Replied by: xxxxx yyy on 08-03-2011 07:48:55 AM
    OK, I made some changes and now script is attached as outbound application, so I got the DNIS with [infotag get evt_handoff dnis] command but I can't make the call active, I was using
     
    leg setup $DestinationNumber callInfo leg_incoming
     
    Do you know how to make call in this case?
     
    I'm getting error:
     

    %SYS-3-CPUHOG: Task is running for (2008)msecs, more than (2000)msecs (2/1),process = AFW_application_process.
     
    While executing leg setup

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 08-03-2011 10:48:29 AM
    If you need to apply service on outbound dial peer :

    1. In state machine the trigger will be "ev_handoff" in stead of "ev_setup_indication"

    2. In dial peer use "service xxx out-bound"

    Thanks

    Subject: RE: TCL Dnis
    Replied by: xxxxx yyy on 09-03-2011 04:07:21 AM
    I did it, but I've got an problem with making calls. leg setup $DestinationNumber callInfo leg_incoming does not work for me now

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 09-03-2011 10:46:37 AM
    Without seeing script is hard to tell what's wrong. Is it possible that you can post part of script ? Or send it to developer-support@cisco.com
     
    Thanks !

    Subject: RE: TCL Dnis
    Replied by: xxxxx yyy on 10-03-2011 08:32:59 AM
    Here is part of script

    proc act_GotDest { } {
        global UrlWorks
        global DialerNumber
        global DestinationNumber
        global LegId
        global dialPeer
        global dialpeerHandle
        global matchedPeer

        set LegId [infotag get evt_legs]
        puts "LEGID: "
        puts $LegId

        set DestinationNumber [infotag get evt_handoff dnis]
        set DialerNumber [infotag get leg_ani]

        puts "DNIS: "
        puts $DestinationNumber
     
       
        leg proceeding $LegId
        set callInfo(originationNum) [infotag get evt_handoff ani]
        leg setup $DestinationNumber callInfo leg_incoming

    init
    requiredversion 2.0

    #
    #   State Machine
    #----------------------------------
    set fsm(any_state,ev_disconnected)         "act_Cleanup,same_state"
    set fsm(CALL_INIT,ev_handoff)    "act_GotDest,CALLACTIVE"
    set fsm(CALLDISCONNECT,ev_disconnected)    "act_Cleanup,same_state"

    fsm define fsm CALL_INIT

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 10-03-2011 10:46:48 AM
    1. Did you place this in outbound dial peer ? With this logic it has to be in outbound dial peer.

    2. Remove "leg proceeding $LegId"

    Thanks !

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 10-03-2011 02:09:02 PM
    Script is working fine. You may need to check your configuration.

    proc act_GotDest { } {
    global UrlWorks
    global DialerNumber
    global DestinationNumber
    global LegId
    global dialPeer
    global dialpeerHandle
    global matchedPeer

    set LegId [infotag get evt_legs]
    puts "LEGID: "
    puts $LegId

    set DestinationNumber [infotag get evt_handoff dnis]
    set DialerNumber [infotag get leg_ani]

    puts "DNIS: "
    puts $DestinationNumber


    set callInfo(originationNum) [infotag get evt_handoff ani]
    leg setup $DestinationNumber callInfo leg_incoming

    }

    requiredversion 2.0

    #
    # State Machine
    #----------------------------------
    set fsm(any_state,ev_disconnected) "act_Cleanup,same_state"
    set fsm(CALL_INIT,ev_handoff) "act_GotDest,CALLACTIVE"
    set fsm(CALLDISCONNECT,ev_disconnected) "act_Cleanup,same_state"

    fsm define fsm CALL_INIT

    Subject: RE: TCL Dnis
    Replied by: xxxxx yyy on 11-03-2011 04:50:07 AM
    Where can I find a clues for configuration? I attached log of making a calls with scripts and compared isdn logs when call is going out and when is not going out, maybe it helps in some way. Do you need some more information?

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 11-03-2011 10:39:41 AM
    Only address the following simple script you posted. The log you posted is different from this.

    The only configuration for this simple script :

    #  service ub tftp://tftp/outbound.tcl


    #Out bound dial-peer
    dial-peer voice 67.. voip
    service ub out-bound
    destination-pattern 67..
    session target ipv4:172.10.156.100
    dtmf-relay h245-alphanumeric
    codec g711ulaw
    no vad

    For example if there is a  destination-pattern 6789, it will hit service "ub" and ring the destination 6789.

    Looks like you issue is different from this.

    You may open a SR for help if problem is complex. Please refer the follow link

    http://developer.cisco.com/web/devservices

    # script
    ----------------------------------------------------------------------
    proc act_GotDest { } {
    global UrlWorks
    global DialerNumber
    global DestinationNumber
    global LegId
    global dialPeer
    global dialpeerHandle
    global matchedPeer

    set LegId [infotag get evt_legs]
    puts "LEGID: "
    puts $LegId

    set DestinationNumber [infotag get evt_handoff dnis]
    set DialerNumber [infotag get leg_ani]

    puts "DNIS: "
    puts $DestinationNumber


    set callInfo(originationNum) [infotag get evt_handoff ani]
    leg setup $DestinationNumber callInfo leg_incoming

    }

    requiredversion 2.0

    #
    # State Machine
    #----------------------------------
    set fsm(any_state,ev_disconnected) "act_Cleanup,same_state"
    set fsm(CALL_INIT,ev_handoff) "act_GotDest,CALLACTIVE"
    set fsm(CALLDISCONNECT,ev_disconnected) "act_Cleanup,same_state"

    fsm define fsm CALL_INIT

    Subject: RE: TCL Dnis
    Replied by: WOJCIECH KACZOR on 11-03-2011 03:26:10 PM
    Hi,
    I am cooperating in this project. I am ipt system engineer not a TCL programmer. At the beginning script was attached to the incoming dial peer. It works fine when calls come from PSTN but doesn't work if calls come from phones attached to the PBX.
    For the clarification there is following connection to PSTN:

    PSTN<---ISDN PRI--->PBX<---ISDN PRI--->H.323GTW<---CUCM and IP Phones

    We have found that ISDN Q.931 setup is different when call comes from PSTN in comparison to setup for call from phone connected to PBX. In most cases PBX send DNIS in overlap, but for some numbers is reconfigured to send it in block. By the way for all calls sent from PBX (phones connected to PBX) DNIS isn't sent in SETUP frame but in INFORMATION Q.931 frames.

    With this type of setup script works wrong:
    *Mar 11 16:44:56: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x44B7
    Bearer Capability i = 0x8090A3
    Standard = CCITT
    Transfer Capability = Speech 
    Transfer Mode = Circuit
    Transfer Rate = 64 kbit/s
    Channel ID i = 0xA98389
    Exclusive, Channel 9
    Calling Party Number i = 0x0181, 'AAAAAAAAA'
    Plan:ISDN, Type:Unknown
    High Layer Compat i = 0x9181
    *Mar 11 16:44:56: ISDN Se0/0/0:15 Q931: Received SETUP  callref = 0xC4B7 callID = 0x0675 switch = primary-net5 interface = User
    *Mar 11 16:44:56: ISDN Se0/0/0:15 Q931: TX -> SETUP_ACK pd = 8  callref = 0xC4B7
    Channel ID i = 0xA98389
    Exclusive, Channel 9
    Progress Ind i = 0x8188 - In-band info or appropriate now available
    *Mar 11 16:44:56: ISDN Se0/0/0:15 Q931: RX <- INFORMATION pd = 8  callref = 0x44B7
    Called Party Number i = 0xA1, '1399'
    Plan:ISDN, Type:National
    *Mar 11 16:44:56: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0xC4B7
    *Mar 11 16:44:56: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8  callref = 0xC4B7
    Progress Ind i = 0x8188 - In-band info or appropriate now available
    *Mar 11 16:45:00: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Calling num 223401979
    *Mar 11 16:45:00: ISDN Se0/0/0:15 Q931: Sending SETUP  callref = 0x06ED callID = 0x866E switch = primary-net5 interface = User

    with this type of setup it works correct:
    *Mar 11 16:50:46: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x44BA
            Bearer Capability i = 0x8090A3
                    Standard = CCITT
                    Transfer Capability = Speech
                    Transfer Mode = Circuit
                    Transfer Rate = 64 kbit/s
            Channel ID i = 0xA9838C
                   Exclusive, Channel 12
            Calling Party Number i = 0x2181, 'BBBBBBBBB'
                    Plan:ISDN, Type:National
            Called Party Number i = 0xA1, '1801'
                    Plan:ISDN, Type:National
            High Layer Compat i = 0x9181
            Sending Complete
    *Mar 11 16:50:46: ISDN Se0/0/0:15 Q931: Received SETUP  callref = 0xC4BA callID = 0x0678 switch = primary-net5 interface = User

    If DNIS is sent in INFORMATION frames incoming dialpeer matching works wrong (incomming called-number command doesn't works). So as a work around we decided to rewrite script and attach it to outgoing dial-peer (outgoing dialpeer matching works fine), but it doesn't help. It seems that router works different (wrong) with DNIS in INFORMATION Q.931 frames.
    Do you have any experiance with that?
    Regards
    WK

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 11-03-2011 03:56:44 PM
    The script you posted really has no problem. I tested (not for ISDN call).
    I think this has something to do with ISDN setup(configuration)..etc.

    One thing you can try for incoming dialpeer scenario is that replying to incoming ISDN leg according to the state.
    Please refer to the following link

    http://developer.cisco.com/web/vgapi/blogroll/-/blogs?_33_delta=5&_33_keywords=&_33_advancedSearch=false&_33_andOperator=true&cur=2

    This is an example

       if {$legState != "lg_005" && $legState != "lg_008"} {
              if {$legState == "lg_001"} {
                  puts "\n>>>>>>>>>legstate = lg_001<<<<<<<<<<<\n"
                  leg setupack leg_incoming
                  leg proceeding leg_incoming
                  leg connect leg_incoming
              } elseif {$legState == "lg_002"} {
                   puts "\n>>>>>>>>>legstate = lg_002<<<<<<<<<<<\n"
                  leg proceeding leg_incoming
                  leg connect leg_incoming
              } else {
                   puts "\n>>>>>>>>>legstate = $legState<<<<<<<<<<<\n"
                   leg connect leg_incoming
              }
          }

    I haven't worked on ISDN for years so you might want to ask Cisco TAC for help.(not for the script but for ISDN signaling, configuration...etc)

    Thanks !

    Subject: RE: TCL Dnis
    Replied by: xxxxx yyy on 14-03-2011 06:37:19 AM
    It didn't help. Maybe you know what can cause looping of script?

    I was trying command

    handoff callappl leg_incoming default "DESTINATION=$DestinationNumber"

    but it doesn't help with calling and script is looped then.
     
    EDIT:
    I used command
     
    leg setup 0 callInfo leg_incoming
     
    Then call is made but callInfo(displayInfo) not shows, do you know where could be problem?
     
    I attached log with this kind of connection

    Subject: RE: TCL Dnis
    Replied by: Yaw-Ming Chen on 14-03-2011 10:58:24 AM
    It's not the script issue.
    Say you have DNIS# 1234 and then you use it as destination number when it goes out it will hit the same dial-peer again.

    what you can you is modify the dest# maybe then have another dial-peer to change it back.

    for example in script you change dest# to A1234 and you have another dial-peer to take dest#A1234, in that dial-peer you will remove "A" before send it out.

    Hope this help.

    Subject: RE: TCL Dnis
    Replied by: xxxxx yyy on 15-03-2011 04:17:24 AM
    I modified DestinationNumber and it didn't work, still has no displayInfo, I think is kind of problem like in this thread:

    http://developer.cisco.com/web/vgapi/forums/-/message_boards/view_message/1432804

    But there is also no answer to this, when I got to leg setup 0 callInfo leg_incoming I lost my callInfo(displayInfo) but call gets to callInfo(destinationNum) but when I change callInfo(originationNum) it is sent
     
    In debug I used:
     

     set displayinfo [infotag get leg_display_info leg_incoming]
     puts "DISPLAY INFO: $displayinfo"

     
    and $displayinfo is still null