SIP Trunking with Broadsoft softswitch

skint · ‎09-21-2007

I am trying to configure a 2821 to perform SIP trunking with a Broadsoft switch on an inbound call leg. Outbound calls work fine, but the design for inbound calls is through SIP trunking, where a single phone number is associated to several hundred other phone numbers.

The first part of the SIP Invite is the only part being matched, not the underlying request. I am at a loss to find any documentation that uses a target phone number associated with a dial-peer to perform this type of function.

Once this is working, dial-peer 5 or 8 should be matched and then translated to a 4 digit number that a 5e directly connected switch is ready to accept. Dial-peer 7 can pretty much be ignored as this did not change the results in either direction.

Thanks,

-ryan

Report Inappropriate Content · ‎09-23-2007

Report Inappropriate Content · ‎09-23-2007

Report Inappropriate Content · ‎09-23-2007

Report Inappropriate Content · ‎09-23-2007

kyipcom84 · ‎09-23-2007

you can refer to this config file.

I'm using AS5400 for voice gateway

I'm using broadsoft as a softswitch.

skint · ‎09-24-2007

Thanks for your response. It appears that the issues are still persisting.

In particular I am seeing the following from 'debug voip ccapi inout':

*Sep 24 02:36:24.621: //562/C7143B7F82EB/CCAPI/ccCallSetupRequest:

Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened, Presentation=Allowed),

Called Number=6105559999(TON=Unknown, NPI=Unknown),

Redirect Number=, Display Info=6104365293@domain.com

The Display Info field is where I need to extract the TN from. Is it necessary to create a trunk group for this type of association, if so I have not found good documentation for SIP trunk configurations in IOS. I have, however, found plenty of documentation for the BTS.

Report Inappropriate Content · ‎09-24-2007

Greetings Ryan:

I work at BroadSoft. Do you have the BroadSoft partner configuration guide (PCG) for configuring the 28XX against BroadWorks? If not please contact me on chartmann@broadsoft.com

Thanks,

-Curtis

skint · ‎09-24-2007

To achieve a single match for the URI contained within the SIP message, we have had to use the following configuration:

!

voice class uri 8123 sip

pattern 6107938123@206.231.245.253

!

voice translation-rule 8123

rule 1 /^$/ /6107938123/

rule 2 /.*/ /6107938123/

!

voice translation-profile voice-8123

translate called 8123

!

dial-peer voice 8123 voip

translation-profile incoming voice-8123

service session

voice-class codec 99

session protocol sipv2

session target ipv4:192.168.252.1

incoming uri to 8123

!

dial-peer voice 8 pots

translation-profile outgoing inbound-5ess

huntstop

preference 2

service session

destination-pattern 6107938...

progress_ind setup enable 3

progress_ind progress enable 8

port 0/2/0:0

!

The call flow at this point comes in and matches dial-peer 8123 by using incoming uri to 8123. Next the call matches the voice class uri with the pattern of 6107938123@206.231.245.253. The call then references dial-peer 8123 again and then translates incoming on 'voice-8123' referencing translation-rule 8123 which uses the E.164 number and matches dial-peer voice 8.

I know we could remove a step and just use translation 8123 instead of translating again at dial-peer 8, but that's really the least of the problems. Unless there is a more elegant solution, we may have to do this for 800 TNs.

Any thoughts?

Thanks,

-ryan

paolo bevilacqua · ‎09-24-2007

A TCL/IVR script would let you use the to portion as called number directly. Actually very few lines of code should be.

skint · ‎09-24-2007

Thanks for your response p.bevilacqua, this looks like a step in the right direction. Do you happen to have a sample of the TCL code to use? Right now I'm attempting to work off a copy of the session script and referencing prompt_digit_xfer.tcl.

I am able to pull this information using a sample script designed to playback the number called:

*Sep 24 21:26:02.624: //1010//TCL :/tcl_PutsObjCmd:

get_headers.tcl: ani is

*Sep 24 21:26:02.624:

*Sep 24 21:26:02.624: //1010//TCL :/tcl_PutsObjCmd:

get_headers.tcl: dnis is 6107938123

This is the correct DNIS information, however, this is after some processing and manipulation in the background. I am still unable to see any values in the To= field. Do you have a script example that properly pulls information from the To field?

Thanks,

-ryan

paolo bevilacqua · ‎09-24-2007

Hi, have you tried accessing leg_proto_headers infotag, that is at page 4-32 of ivr 2.0 programming guide.

skint · ‎09-25-2007

Hi p.bevilacqua,

With my limited TCL experience, I have been able to modify a copy of the app_session.tcl script in attempts to pull out header information. I made a simple adjustment to pull a value out of the headers and display it.

The only changes I have made are:

proc act_Setup { } {

global dest

global allHeaders

global beep

set beep 0

set allHeaders [infotag get leg_proto_headers]

puts "\n allHeaders = $allHeaders"

Output from the debug:

>>>>CCAPI handed cid 1133 with tag 8000 to app "_ManagedAppProcess_vtest"

*Sep 25 13:42:25.292: //-1//SERV:/AFW_Service_Process_Space:

*Sep 25 13:42:25.292: Process Started

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_Process_Register: ccAppInitialize(name: _ManagedAppProcess_vtest)

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_Event_New:

*Sep 25 13:42:25.296: //1133//AFW_:/AFW_Process_GetCcqEvent: Received

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_Process_GetCcqEvent: Event[CC_EV_CALL_SETUP_IND(29)] {

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_Process_GetCcqEvent: EXECENV[0x46EA4724][vtest]

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_Process_GetCcqEvent: LEG[1133][LEG_INIT(0)][Cause(0)]

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_Process_GetCcqEvent: }

*Sep 25 13:42:25.296: //1133//SSIN:/AFW_SS_MapEvent:

*Sep 25 13:42:25.296: //-1//SSIN:/AFW_SS_SIP_MapEvent:

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_Leg_UpdateStats: Updating stats for ID 21B type 0

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_Object_WalkListeners:

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_M_Object_ShowListeners: START

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_M_Object_ShowListeners:

*Sep 25 13:42:25.296: //1133//AFW_:/AFW_M_Module_GetHandle: Module handle: TclModule_45096A9C_0_629806192MOD[TclModule_45096A9C_0_629806192] (

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_M_Object_ShowListeners: LEG[1133][LEG_INCINIT(1)][Cause(0)]

*Sep 25 13:42:25.296: //-1//AFW_:/AFW_M_Object_ShowListeners: )

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_M_Object_ShowListeners: END

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_Object_WalkListeners: Entering Module : TclModule

*Sep 25 13:42:25.296: //1133//AFW_:/AFW_ExecEnv_SetModuleScope: TclModule_45096A9C_0_629806192 ---> TclModule_45096A9C_0_629806192

*Sep 25 13:42:25.296: //1133//AFW_:/AFW_M_TclModule_Action:

*Sep 25 13:42:25.296: //1133//AFW_:/AFW_TclModule_DefaultEvHandling:

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_Leg_CheckIncomingCallBlock:

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_Leg_SettlementValidateCall: target=sip-server, tokenp=0x0

*Sep 25 13:42:25.296: //1133/FBE74DB98654/AFW_:/AFW_Leg_IncomingTranslate:

*Sep 25 13:42:25.300: //1133//AFW_:/AFW_FSM_Drive: ACTION BEGIN: ------(CALL_INIT[1],ev_setup_indication[29])---[act_Setup]------

*Sep 25 13:42:25.300: //1133//TCL :/tcl_InfotagObjCmd: infotag get leg_proto_headers

*Sep 25 13:42:25.300: //1133//TCL :/tcl_InfotagGetObjCmd: infotag get leg_proto_headers

*Sep 25 13:42:25.300: //1133//AFW_:/vtr_lg_proto_headers: argc 2 argindex 2

*Sep 25 13:42:25.300: //-1//AFW_:/AFW_Leg_GetProtoHeaders: callID=1133, tag=41, reqHeader=473BC868, reqCount=-1

*Sep 25 13:42:25.300: //1133//TCL :/tcl_PutsObjCmd:

allHeaders =

*Sep 25 13:42:25.300:

I am wondering if I'm trying to pull the SIP headers too late in the call process, should I be using a different procedure. In the programming guide there is a mention of the procedure init, used for digit collection and breaking out of the script. The act_Setup section of the script is executed after ev_setup_indication, however I can't seem to pull any headers at this point.

Here is the dial-peer it's matching on:

dial-peer voice 8000 voip

service vtest

voice-class codec 99

session protocol sipv2

session target sip-server

incoming uri to 8000

!

Thanks again,

-ryan

skint · ‎09-26-2007

Hi. We resolved the issue, it seems we were missing the section to pass sip headers.

If anyone cares, the missing code was:

voice service voip

sip

header-passing

Thanks to everyone who assisted.

-ryan