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.
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(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.
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:\email@example.com:5060>”
request REFER sip-header Refer-To modify “sip:(.*)@(.*)” “sip:\firstname.lastname@example.org: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
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.