Broadworks Trunk Group Identity (TGI) is an option in the Trunk Group Profile that allows a unique identity to be provisioned and allow Unscreened Calls from the customer premise. Unscreened Calls is common with TDM PRI customers who want to send a From DN that does not reside in their Trunk Group. With SIP trunks delivering PRI at the customer premise, this type of call will fail unless the PBX sends an ISDN Redirect on the PRI connected to the ISR/IAD which generates SIP Diversion to Broadworks. Otherwise Broadworks sees a To and From that are both PSTN numbers and rejects the call. A common scenario where this instance occurs is a PSTN caller calling a SIP subscriber and the call is forwarded to another PSTN number. The person receiving the forwarded call on the PSTN wants to see the caller ID of the original calling party not the SIP subscriber number. With Unscreened Calls enabled and Trunk Group Identity provisioned in the TG Profile the calls will be permitted even without SIP Diversion. This also requires an identical TGI to be configured on a SIP endpoint such as a Cisco ISR or IAD.  When the SIP endpoint sends a SIP invite it will include the provisioned TGI in the Contact header.  As of August 14, 2009, Adtran TA900′s do not support TGI. A feature request has been submitted to Adtran.

Trunk Group Identity in Broadworks complies with RFC 4904. Using trgp and trunk-context is a requirement to be compliant with the RFC.

Here is a screenshot of the TG Profile page in Broadworks. The Pilot User number is the TGI in this example.

If you are using an Acme Packet Session Director you must configure the SD global SIP option to pass the Contact through to Broadworks. Otherwise the SD will rewrite the Contact header and TGI will not pass.

acme# config t
acme(config)# session-router
acme(session-router)# sip-config
acme(session-router)# select
acme(sip-config)# options +reg-cache-mode=none

All SIP Contact header information from the endpoint is now retained. It is important to note that using + means this option will be added to the SD sip-config and your other options will be retained as well. If you issue the show command you will see an example of this.

acme(sip-config)# show

options
forward-reg-callid-change
max-udp-length=0
set-inv-exp-at-100-resp
reg-cache-mode=none

If you do not prepend + in front the option you are adding, the SD will remove the old options and only apply the option you are currently adding.

The last item to configure is the SIP endpoint. In this case it is a Cisco ISR or IAD. There is no “TGI feature” in IOS but IOS does offer the ability to modify SIP headers through the use of SIP Profiles which are a feature of CUBE. In the following example I am creating SIP profile 100 and when the sip-ua registers, sends an invite, or sends a refer to Broadworks it will include the tgrp modification in the Contact header.

voice class sip-profiles 100
request REFER sip-header Referred-By modify “<sip:(.*)@(.*)>” “<sip:\1@voip.telepacific.net:5060>”
request REFER sip-header Refer-To modify “sip:(.*)@(.*)” “sip:\1@voip.telepacific.net:5060″
request REGISTER sip-header Contact modify “<sip:(.*)@(.*)>” “<sip:\1;tgrp=9494289972;trunk-context=voip.telepacific.net@\2>”
request INVITE sip-header Contact modify “<sip:(.*)@(.*)>” “<sip:\1;tgrp=9494289972;trunk-context=voip.telepacific.net@\2>”
!
!

voice services voip
sip
sip-profiles 100

You can read about Cisco’s regular expression notation for CUBE SIP Profiles here. If you are familiar with translation patterns you will grasp regular expressions very quickly.

The example profile shows that we are taking all elements from the self-generated SIP registration and simply adding more information.  The second part of each “request” is where we inject the tgrp and trunk-context information.  The tgrp value in this example is the Pilot User number 9494289972.  If you note the Broadworks screenshot above you will see this value was provisioned as the Trunk Group Identity in the TG Profile.  The value of the trunk-context is a service provider domain.

This example only highlights Unscreened Calls for SIP to PRI customers using a SIP endpoint that has the ability to support RFC 4904.  There is another method which may be used by building unique session agents on the Session Director.  This becomes a bit more involved over time due to individual customer based provisioning on the SD which is why I did not cover it here.

  1. sanjay srinivasan says:

    Mark this is very well written. Have you received any update from ADTRAN on whether they have accepted the feature request and if so have they projected a support date for it?

  2. Mark says:

    Adtran has listened and included TGI support in A2.05. It’s far from a full CUBE implementation but it’s enough to support unscreened calling.

  3. Rick says:

    Do you really need the modification on the registration? Works fine with the modified Invite, but I have issues inbound when the I modify the registration.

    Thanks!

  4. Adtran is now RFC4904 compliant and supports TG identifier and asserted-id.

    Ex)

    !
    !!!!>A2.05!!!!
    !
    voice trunk T0x type sip !x == your logical sip trunk number!
    p-assert-diversion
    grammar p-asserted-identity host sip-server
    trunk-group-id 7025551234 yoursipdomain.com default-ring-cadence internal
    !trunk-group-id == NPAnxxXXXX yoursipdomain.com!
    !
    !
    ip rtp firewall-traversal
    ip firewall nat-preserve-source-port
    ip rtp firewall-traversal reuse-nat-ports
    !

    ML

  5. Franch says:

    Hi Mark. Have you ever connect PBX throw a SIP trunk without registration? Now I use LRT for it.
    I’m interesting in a connection with 2 PBX (For redudancy) with 1 DN. What should I write in address and contact in user profile filed?