is.invalid... address in Via and Contact headers (SIP plugin)

[lminiero]

Apparently the SIP plugin generates invalid addresses in the Via and Contact headers when registering at SIP proxies. This doesn't affect outgoing calls, but it does affect incoming calls, as those invalid headers result in unreachable endpoints.

@saghul I tried an older version of the nua_create call, extracted from the plugin before all the fixes you provided:

https://github.com/meetecho/janus-gateway/blob/1281ca867db7e6ec20c5f3d12df92f43374a1920/plugins/janus_sip.c#L2299

and the issue doesn't occur there. I'm not sure what of the new tags added to nua_create could be the cause, though. I've read around that it is an issue that can occur with Sofia from time to time, but could find no indication on potential fixes. I'm hesitant to just put the old call to nua_create back, as your changes did indeed improve the plugin as a whole, and I'm sure the outbound settings in particular cannot just be ignored and were added for a purpose, specifically NATted instances of the plugin.

Have you encountered this issue in your tests? Are you aware of any parameter we should pass to the Sofia stack to prevent this from happening? Some say this could happen in NATted scenarios where no STUN server was provided, but it's happening on a publicly reachable address.

[lminiero]

Ok, found out the issue, apparently. Commenting this line:

https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_sip.c#L2091

the invalid address disappears, and the correct one is used instead. From what I read in the docs, setting TPTAG_SERVER to 0 disables server sockets binding: any reason why you added this specifically? Anyway, since it's apparently messing something within Sofia SIP with respect to those addresses, I'll comment it in a push for the moment: let me know if there's a cleaner fix.

[saghul]

I'll take a look. Can you please paste a trace of a broken package? On Apr 23, 2015 1:06 PM, "Lorenzo Miniero" notifications@github.com wrote:

Ok, found out the issue, apparently. Commenting this line:

https://github.com/meetecho/janus-gateway/blob/master/plugins/janus_sip.c#L2091

the invalid address disappears, and the correct one is used instead. From what I read in the docs, setting TPTAG_SERVER to 0 disables server sockets binding: any reason why you added this specifically? Anyway, since it's apparently messing something within Sofia SIP with respect to those addresses, I'll comment it in a push for the moment: let me know if there's a cleaner fix.

— Reply to this email directly or view it on GitHub https://github.com/meetecho/janus-gateway/issues/213#issuecomment-95542356 .

[lminiero]

You mean a broken REGISTER message?

[saghul]

If that is the broken package, then yeah.

[lminiero]

This is the REGISTER that is created if I leave the TPTAG_SERVER in place:

REGISTER sip:1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP X8Z1a0KU5XyXg4Sr.is.invalid;rport;branch=z9hG4bKB3079mg00aaUa
Max-Forwards: 70
From: <sip:lminieros@1.2.3.4:5060>;tag=B3g1QKN5BXcQe
To: <sip:lminieros@1.2.3.4:5060>
Call-ID: 9ce3daf3-645f-1233-9184-f01faf06fb8c
CSeq: 74561821 REGISTER
Contact: <sip:lminieros@X8Z1a0KU5XyXg4Sr.is.invalid:5060;transport=udp>
Expires: 3600
User-Agent: Janus WebRTC Gateway SIP Plugin 0.0.5
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS
Supported: path
Content-Length: 0

(I just replaced my public IP address with a 1.2.3.4) As you can see, both the Via and Contact header have broken information, X8Z1a0KU5XyXg4Sr.is.invalid, which is in fact confirmed by the Asterisk console:

ERROR[19521]: netsock2.c:269 ast_sockaddr_resolve: getaddrinfo("X8Z1a0KU5XyXg4Sr.is.invalid", "(null)", ...): Name or service not known
[Apr 23 15:29:30] WARNING[19521]: chan_sip.c:18089 check_via: Could not resolve socket address for 'X8Z1a0KU5XyXg4Sr.is.invalid'

Asterisk is less troublesome with respect to contacting the endpoint that has registered this way, as it has options to override what's written in the Contact and work anyway, but we've had problems with other SIP proxies that resulted in a failure to reach the peer.

Does this look like anything you met already? Thanks!

[saghul]

Doh, that's weird. That option just forces the sockets to not listen. Since we are acting as an endpoint who registers, there is no real need to listen for incoming connections, calls will come over the connection made in the REGISTER. Well, that was the idea, which worked IIRC :-)

Please leave this open, I hope to get back to Janus next week and I'll check it out.

[lminiero]

Thanks for the clarification: it is indeed weird that an unrelated setting triggers that strange behaviour. Unless it needs that binding anyway when acting as a UAS, e.g., for UDP usage? Not sure if it depends on the Sofia SIP version or not, or the distro: it did happen both on Fedora 18 and Ubuntu 12.04, and on both Sofia is v1.12.11. If you have a more recent version, it might explain why it's not happening to you.

Of course I'll keep it open: feel free to come back to it when you want! The important thing is that we do have a temporary workaround for the time being.

[saghul]

@lminiero You may close this and remove the option. I thought Sofia would be smart enough to pot the client socket's address there, but apparently it isn't. I didn't notice it because our proxy will replace the IP address in the contact header (the bogus one in this case) with the received one, for NAT traversal.

[lminiero]

I wonder if we need to provide a STUN server manually somehow? e.g., not only for machines with a public address, but also for the behind_nat property. I'll close the issue then.

[saghul]

I don't think that should be necessary. Sofia should put the local IP of the outgoing socket, but it seems to skip that in case on non-listening sockets. Oh well. If I come up with a solution I'll send a PR :-)

[lminiero]

Thanks!