We’ve in the process of switching from chan_sip to pjsip, and we’re seeing a change in how SIP messages are routed compared to chan_sip
Our setup is as follows:
sip.example.com (Kamailio, as Registrar and Load Balancer)
ast01.sip.example.com (Asterisk 15.1 with pjsip)
ast02.sip.example.com (Asterisk 15.1 with pjsip)
Firewall wise, only the RTP ports on the asterisk servers are accessible to the internet, everything else is only accessible by Kamailio.
An INVITE comes in to the registrar, is authenticated and passed on to Asterisk, and the call is established and all is well.
The INVITE contains a RR header:
sip.example.com is an external IP address, and DNS resolves it as such.
However, if Asterisk hangs up the call, it sends the BYE request to the external address of sip.example.com, meaning that Kamailio in turn attempts to route the 200 OK to the Asterisk Servers External IP (which is blocked by the firewall).
I realize that this is probably because the RR header specifies that this is the route messages should take.
However, is there any way to make PJSIP do what chan_sip did, and always respond to the IP address it received the INVITE from?
I can make it work by overriding sip.example.com in the hosts file on the asterisk server, but that’s not a preferred solution if it can be configured better.
What is your configuration?
The SIP log would also be useful (pjsip set logger on) to better understand the signaling. Generally, though, we don’t have an option specifically for this as it goes against the SIP spec.
Here is the configuration:
Yeah, it goes against the spec. It’s probably something I’d need to try and address in the Kamailio configuration.
Just wanted to confirm both that this is indeed against the spec, and there is no fancy configuration that gets us around it
Having stared myself blind at trying to solve this with PJSIP configuration, I feel silly now.
It was easy to address this issue in Kamailio. Should anyone have this issue: the record_route_advertised_address method in the Kamailio RR module makes it easy to enter whatever you need in the Record-Route header.
My apologies, and thank you for the fast response none the less!
2 posts were split to a new topic: ACK and BYE to wrong target