Overview
Everyone knows that PJSIP is the channel driver of choice for Asterisk nowadays. It’s a powerful driver, but that doesn’t mean there isn’t more work to be done! In an effort to have feature parity between chan_sip and chan_pjsip, support has been added for TEL URIs. Right now, this only includes basic calls for a number of reasons. We’ll dive into some of those reasons in this post.
Basic Setup
Getting a basic call to work was fairly straightforward. The difficult part was scouring the code for potential areas that needed to be changed. When traffic comes through res_pjsip_message_filter.c, there’s a certain criteria that needs to be met in order for it to pass through. Before this change, URIs were checked to see if they were SIP or SIPS. Naturally, this was the first thing that needed to be changed. The request line, From, and To headers were updated to also check for TEL URIs. Now, if we get a URI that’s SIP, SIPS, or TEL, we allow it through.
The request line needed some additional work. There are only a handful of requests that we would expect (or allow) as of writing this: INVITE, ACK, BYE, and CANCEL. An allow list was created to handle that. In the future, if more requests need to be allowed, it’s as simple as adding it to this list.
Scope
Once those were both taken care of, basic calls with TEL URIs started working. There were several other places in the code that needed to be looked at, however. The URIs have different types defined by pjproject: pjsip_uri, pjsip_sip_uri, pjsip_tel_uri, etc. Anywhere that had a pjsip_uri or pjsip_sip_uri needed to be examined. Likewise, there were function calls to get these URIs that also needed to be looked at. Some helper functions were added to take in a generic pjsip_uri and return information based on what kind of URI it is. Because TEL URIs are structured differently than SIP and SIPS URIs, we needed a good way to simply call one function and not have to worry about URI type.
Restrictions
Another issue that presented itself was the URI types being nested in public API functions and structures. Adding any kind of support for TEL URIs to these areas would require rewriting most of this to be type agnostic. We usually don’t like making changes to public API functions, either. Of course, with the groundwork in place, it should be much easier to add support to other areas. However, we thought basic calls were a good place to start. Patches from the community are also welcome if someone wants to take the time to make these changes.
Testing
Like all new features, tests are strongly encouraged. One test was added to ensure basic calls with TEL URIs work. Another test was updated to allow TEL URIs in the request line, From, and To headers, but not the Contact header. Additional tests will need to be added alongside any new support that is added for TEL URIs, so having an existing test is also a nice way to provide an example for how to get started with that.
