The Dialogic® Brooktrout® Fax SDK Release 6.12 is the latest Brooktrout development kit providing feature rich capabilities to our partners. In this blog post, I will discuss a new feature and why it can help you.

 

SIP allows for the capability of transferring a call before it arrives at your endpoint. The call arrives at the endpoint and is answered with no issue, but some of the information within the call may be different from what you expect. Specifically, the SIP message may show your phone number that was called (sometimes referred to as your DID number) in a different spot.

 

In SIP, when you receive a call, what happens is you’ll get in an INVITE message which will arrive with various pieces of information including headers to identify aspects of the call itself and, optionally, codecs to be used for the call. Normally, the number that was called appears in the “To:” field. That’s where an SR140 application would normally look for the called phone number. When the call gets transferred though, sometimes a different number will appear in the To: field and your (DID) number will instead appear in the Request-URI field.

 

The Request-URI appears at the beginning of a SIP INVITE message, before any of the headers like the “To:” field.   In most cases it contains the same information as the “To:” field, other than in the cases of calls being transferred of course. The Request-URI will look something like this with a phone number and IP address:

 

Request-URI: sip:5551212@10.20.30.40:5060

          

In SDK 6.7.3, Dialogic added a feature to make SIP headers available to an application.  Access to the Request-URI was not part of this feature. In SDK 6.12, we’ve expanded upon this feature to also allow the application to retrieve the SIP Request-URI field too.

 

To retrieve the number sent in the Request-URI, your application would follow the same procedure as for getting the rest of the SIP headers. Your application will wait for a call using BfvLineWaitForCall (or BfvCallWaitForSetup) and as part of that, you’d supply a buffer in your application where the Request-URI and the rest of the header fields will be populated. The Request-URI will always appear first. Note that, like the “To:” field, only the phone number portion of the Request-URI (e.g. “5551212” in the example above) would be given to the application.