leg setup and dial-peer

Version 1
    This document was generated from CDN thread

    Created by: Mark Alliban on 28-05-2013 03:59:40 AM
    When I use leg setup, it will seek through the dial-peers to find a match. I have multiple dial-peers for each carrier, because I have that carrier on multiple systems, for load balancing.   dial-peer voice 1 voip  destination-patterm 100.T  session target ipv4:192.168.1.1 dial-peer voice 2 voip  destination-patterm 100.T  session target ipv4:192.168.1.2 dial-peer voice 3 voip  destination-patterm 100.T  session target ipv4:192.168.1.3   Is there any way for my TCL to know which dial-peer the call was sent through?  

    Subject: RE: leg setup and dial-peer
    Replied by: Raghavendra Gutty Veeranagappa on 28-05-2013 04:55:18 AM
    Hi Mark,
    I don't think TCL script will know through which dial peer the call was sent through. please refer Dial-Peer Hunting Sample Script.zip in below link to Specify the dial-peer handle to use for the setup.
    leg setup {destination | array-of-destinations} callinfo [legID | info-tag] [-g <GTDHandle>] [–d <dialpeerHandle>]
    http://developer.cisco.com/web/vgapi/documentation
     
    By default, if all destination patterns are equal, the preference is set to 0 on all dial peers. If the preference does not act as the tiebreaker, then a dial peer matching the called number will be picked randomly.
     
    Thanks,
    Raghavendra
     
     

    Subject: RE: leg setup and dial-peer
    Replied by: Mark Alliban on 28-05-2013 06:21:15 AM
    Thanks, I was wondering if there's any way to get feedback of which dial-peer is selected by that "random" progess you mention at the end. I guess not, oh well!
     

    Subject: RE: leg setup and dial-peer
    Replied by: Raghavendra Gutty Veeranagappa on 28-05-2013 07:26:01 AM
    Hi Mark,
    i think it is not possible to get which dial peer used for leg setup in TCL script.
    thanks,
    Raghavendra

    Subject: RE: leg setup and dial-peer
    Replied by: Mark Alliban on 28-05-2013 08:39:20 AM
    Okay, thanks for letting me know. I couldn't see any way but thought I'd ask in case I was missing it.
     

    Subject: RE: leg setup and dial-peer
    Replied by: Yaw-Ming Chen on 28-05-2013 01:44:19 PM
    Well, you you just need to know which dial-peer is currently triggered by Tcl service there is a way.
     
    Use your dial peer 1,2,3 as an example.
     Assuming we have a service dp
    I would add this in you act_setup
     
      if {[infotag get cfg_avpair_exists dp-num]} {
                set dp_num [string trim [infotag get cfg_avpair dp-num]]  
            } else {     
                set dp_num""
      }
     
      puts "dial-peer number = $dp_num"
     
    Now go to your "incoming" (might not work in outgoing) dial-peer  which we deploy tcl script.
    do "paramspame ? "  we show see dp (your service name)
    then we do "paramspace dp dp-num 1" for dial-peer 1 (2 for dial-peer 2...etc)
    In this way we can tell which dial-peer is going thru.
     
     

    Subject: RE: leg setup and dial-peer
    Replied by: Mark Alliban on 29-05-2013 04:52:52 AM
    Thanks for the try, but it is the outbound dial-peer that I need to know. The inbound is always the same.
     

    Subject: RE: leg setup and dial-peer
    Replied by: Yaw-Ming Chen on 29-05-2013 09:27:13 AM
    You have a Tcl script running on an incoming dialpeer, when setup a outgoing leg it could go to different dialpeer even with the the same number because of load balance right ?
    I haven't try the namespace in outbound but it might work, If it works then you might be able to make this to work but it's complicated.
    So you will have two scripts, new one will sit on outbound, gathering the dialpeep info, callid,..etc using namespace config. When call comes in, it will send these message to the first script that sent call to here using "sendmsg" command, also get handoff DNIS to make the call out.
     

    Subject: RE: leg setup and dial-peer
    Replied by: Mark Alliban on 29-05-2013 10:58:50 AM
    Wow that's a complicated solution! Should work I think, but for this project it's a bit too much. I think it will be easier to find a workaround that does not involve the TCL knowing the dial-peer.