A new feature that was initially implemented during a recent visit to SIPit has now been merged into the 13, 14, and master Asterisk branches. It’s called PJSIP dual stack!
For those who may be unfamiliar with what dual stack is it is technique of running both IPv4 and IPv6 connectivity on a system. This allows you to connect to the older IPv4 based network services but also to the IPv6 accessible ones as well.
Previously PJSIP supported this but in a rigid manner. In the case of SDP it would only allow you to explicitly configure in pjsip.conf on the endpoint that IPv6 should be used. If enabled the SDP would contain IPv6 address information, no matter what. This was problematic for people who just “wanted it to work” without knowing whether IPv4 or IPv6 would be used and did not satisfy the requirements for the new DNS work in Asterisk 14. Additionally the SIP signaling information may not have been updated to reflect the address information of the transport that it was going out on.
Have no fear though, proper PJSIP dual stack support is now here!
When a request is being sent the underlying transport (IPv6 TLS, IPv4 TLS, IPv6 TCP, IPv4 TCP, IPv6 UDP, IPv4 UDP) that is used updates the SIP message itself with new address information. This includes both the SIP portion and the SDP portion. This means that if DNS resolution resulted in IPv6 being used the message is updated with IPv6 address information. If IPv4 is being used then it is updated with IPv4 information.
In particular for Asterisk 14 this is important because the new DNS work allows failover to occur. A message may actually fail over from IPv6 to IPv4 if the IPv6 address does not respond. With proper dual stack support the message is updated as expected and “just works”.
So what do you need to do to use this? Nothing, actually, except upgrade. The goal was to make it as seamless as possible. In fact the option on the PJSIP endpoint which controlled whether IPv6 should be used for the SDP no longer has any effect. Everything is done automatically for you.
Unfortunately though this feature did introduce an issue for some environments (my fault). If an environment has been built with IPv4 only this feature breaks RTP. This was not something that was originally tested but has made us more aware that the environments do exist and to keep them in mind. A fix, contributed by community member Guido Falsi who maintains the FreeBSD port, has been placed into the branches and will be in the next release. If your environment has been built with both IPv4 and IPv6 support (as many have) this problem does not impact you.
So if you are one of those who have a system built with IPv4 and IPv6 support update to Asterisk 13.13.0 or 14.2.0 and gain dual stack support without having to do anything else!
4 Responses
sounds great! ipv6 is awesome, but why I can’t use several tcp over ipv4 transports in pjsip? it looks like only first defined is recognized. sorry for bad English – non native speaker here.
This is a limitation in PJSIP itself. While it has come up a few times in the community (maybe 3 times over the last 3-4 years) it has not yet been changed, as it’s not something a lot of people are asking for. If PJSIP themselves change this behavior then we will naturally gain it.
Looks like moving the multihomed module inside res_pjsip broke loading pjsip altogether. There is now an unsolvable circular dependency between res_pjsip.so and res_pjsip_session.so via ast_sip_session_register_supplement().
> module load res_pjsip.so
[Jan 20 14:34:29] WARNING[14286]: loader.c:556 load_dynamic_module: Error loading module ‘res_pjsip.so’: /usr/lib/asterisk/modules/res_pjsip.so: undefined symbol: ast_sip_session_register_supplement
> module load res_pjsip_session.so
[Jan 20 14:40:07] WARNING[14286]: loader.c:556 load_dynamic_module: Error loading module ‘res_pjsip_session.so’: /usr/lib/asterisk/modules/res_pjsip_session.so: undefined symbol: ast_sip_dialog_set_endpoint
There is an issue on the issue tracker[1] tracking this problem. If you have an account you can add yourself as a watcher to receive updates as things change.
[1] https://issues.asterisk.org/jira/browse/ASTERISK-26518