C function which sets contact header in '200 OK' Message Header

Hello,

I want to force an IP Address into the Contact part of the Message Header on a ‘200 OK’ reply to an ‘INVITE’. Does any one know which C function(s) in Asterisk 15.3(chan_pjsip) are setting this?

Thank you,

That’s really more appropriate for the developer mailing list or IRC channel.

Which broken SIP implementation are you trying to work round? The only purpose of that field is to provide a means of routing requests to the right machine.

Hello, I was not aware there was another mailing list. I will try to sign up for that one.

My issue is that Asterisk 15.3 is putting it’s Public IP-Address into the Contact field of the Message Header on a ‘200 OK’ reply to an ‘INVITE’, however Asterisk 14.6 is putting it’s Private IP-Address. My Proxy has stopped working because of this; the Proxy works fine if I am using version 14.6.

I have played with all the setting that could effect this, but nothing I change is allowing the Private IP-Address to be used.

Thank you,

You haven’t provided your network topology, configuration, and packet captures in any of the posts you’ve created about the problem. If you provide those then it can be looked at, as it is likely configuration related.

Would you like to see pjsip.conf and a log with ‘pjsip logger on’?

Thank you

Yes. Without that one can only guess as to what is happening.

Hello Here are the debug file and pjsip.conf.

Asterisk Private IP:100.10.1.124
Asterisk Public IP:50.100.200.87
Proxy Public IP:50.100.200.87
Proxy Private IP:100.10.1.108
Thank you!

debug.investigate.txt (43.5 KB)
pjsip.conf.investigate.txt (14.7 KB)

I forgot to mention that I have tried combinations of local_net and external_signaling_address, contact_rewrite, but nothing is effecting the Contact Header

You haven’t configured local_net properly. The local_net option specifies a subnet, such as 100.10.1.0/255.255.255.0, and this is used to know when an internal IP address should be replaced with the external address provided. As it is configured the external address would really always be substituted in.

I did try setting local_net to 100.10.1.124 and I still did not work however in Asterisk 14.6 it does work.

As I stated it needs to include a subnet mask for your network, and the example I gave should work. Just providing the IP address for the Asterisk won’t work. The logic is: is this target IP address in a configured local net? If yes then leave the message alone. If no then substitute the external address.

I did try with the subnet mask, perhaps I typed in in wrong, I will go verify.
Thank you.

You also need to restart Asterisk to have these changes applied, and there are CLI commands to examine the configuration.

Thank you!, Yes, I can now change the Contact Header. However, this did not solve the problem like I thought it would. Asterisk 15.x still is hanging up on the (WebRTC<=>WebRTC) call, where as Asterisk 14.6 does not hang up. It appears there is an additional INVITE back to the Proxy in Asterisk 15.x. Does this make since?

Thank you!

I’d need to see a complete new trace to see what the INVITE is about and why the call is being hung up.

In Asterisk 15.x, a third Invite occurs to the web socket which is registered in the proxy. and the proxy thinks the web socket is closed. Asterisk 14.6 never makes this 3rd invite, which is why it works. I’m not sure why there is now a third invite, but Kamailio and Asterisk appear to be out of sync. I am not sure it this a Kamailio or Asterisk issue.

Hello, Here are the new debug file and pjsip.conf that have thepjsip.conf.txt (8.4 KB)
debug.investigate.txt (78.2 KB)
dropped call

Asterisk Private IP:100.10.1.124
Asterisk Public IP:50.100.200.87
Proxy Public IP:45.25.100.61
Proxy Private IP:100.10.1.108

I have been struggling with this for some time, so Thank you very much!

I believe it’s reinviting to renegotiate media stream properties to ensure the best possible match. It appears to be failing because our ACK is not reaching the remote side. It retransmits the 200 OK repeatedly (so it accepted the re-invite) until it gives up. Why the ACK Isn’t making it I don’t know, you’d have to look outside of Asterisk.

Yeah, I was a little worried it was a Kamailio problem. I thought it could have something to do with Asterisk because version 14.6 works but >= 15.x doesn’t (that third INVITE seems to be the issue).

Thanks again for taking time to look at this.

The fact the INVITE goes out should still be fine, and in fact we receive a 200 OK stating that it’s fine with it. It falls apart after that.

I think really your setup was just depending on specific conditions to just work.