Unroutable Contact SIP header if behind NAT

[cavedon]

If qutecom is behind NAT, the Contact header is set to the local unroutable IP address, which prevents REGISTRATION with some SIP providers (e.g. ekiga.net).

The value of the Contact header should be updated to the IP/port discovered using STUN or, better, to the "received=" and "rport=" values stored in the Via header of response SIP messages (http://www.faqs.org/rfcs/rfc3581.html).

[forest]

Best practices for dealing with such problems:

http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09

[neo]

I can confirm that. Although it seems to work with my provider, the wrong internal IP is announced and visible in the web interface of my voip provider.

[ibc]

For that STUN is required. Does QuteCom implement STUN? I don't think so.
However, a registrar SIP server can detect the NAT and store the real source address instead of the Contact address. This is a working NAT solution as server side.

[laurent]

Qutecom implements STUN with Wengo type account. With sipaccount, search in the mailing-list,there is a patch.

[cavedon]

Replying to ibc:

For that STUN is required.

Not necessarily, IMHO: you can use the "received=" and "rport=" values stored in the Via header of response SIP messages (http://www.faqs.org/rfcs/rfc3581.html).

[ibc]

That just solves NAT for signalling, not for media :(

[cavedon]

Yes, I agree.
I opened this ticket only for the "Contact:" address. Fixing this would allow registering on ekiga.net.

[gazambuja]

Some news here?
I try use qutecom to connect in my ekiga or Gizmo account without result :-(
(I am in a LAN).

I have Linux Ubuntu 9.04 whit this deb: qutecom 2.2~rc3.dfsg1-7~jaunty1~ppa1

exist any workarround?

Wireshark logs here:
REGISTER sip:proxy01.sipphone.com SIP/2.0

Via: SIP/2.0/UDP 192.168.1.2:5060;rport;branch=1115090933

Route: <sip:proxy01.sipphone.com;lr>

From: nobody <sip:17471327123@proxy01.sipphone.com>;tag=347753924

To: <sip:17471327123@proxy01.sipphone.com>

Call-ID: 1579599952

Contact: <sip:17471327123@192.168.1.2>

CSeq: 1565762393 REGISTER

X-Wengo-Ping: network test

Content-Length: 0

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.168.1.2:5060;rport=5060;branch=1115090933

From: nobody <sip:17471327123@proxy01.sipphone.com>;tag=347753924

To: <sip:17471327123@proxy01.sipphone.com>;tag=92390300a369f0d75803e369c733575e.2b2c

Call-ID: 1579599952

CSeq: 1565762393 REGISTER

WWW-Authenticate: Digest realm="proxy01.sipphone.com", nonce="4a105dcc6d6add4c20fdeb71705438382917e6f1"

Content-Length: 0

[ibc]

It's easy: some providers (as Ekiga) don't allow private address in Contact, this means that the provider doesn't help when the client is behind NAT. This meants that the provider doesn't fix the signalling (by using received public address instead of private "Contact") but that the provider doesn't offer a RTP tunnel (proxy RTP).

In this case the only solution is in the client side which could be:

a) STUN support: If the client is behind a non symmetric NAT router and supports STUN, it can solve *by itlsef* the signalling and media (by setting public addresses in "Contact" and SDP (retrieved using STUN).

b) Manual port forwarding in the router and setting these values *manually* in the signalling and SDP sent by the client.

These both solutions would fix signalling and media, but unfortunatelly Qutecom don't support them (well, it supports STUN just for Wengo provider).

So in conclusion, I think that the best solution would be to ask for global STUN support in Qutecom.

[cavedon]

Replying to ibc:

In this case the only solution is in the client side which could be:
...

For SIP signaling, what about setting the Contact headers to the "received=" and "rport=" values stored in the Via header of response SIP messages? (http://www.faqs.org/rfcs/rfc3581.html)

[ibc]

There is no a standard specifying it, and it doesn't seem very robust for me.
For example: the workaround you suggest would require Qutecom to send some OPTIONS (or whatever request) prior to the REGISTER. Of course, you cannot rely on the 407/401 reply for the first REGISTER since the registrar could instead reply a "403 Forbidden" due to the private address in Contact.

But sincerelly I don't understand why you insist on this workaround that just solves signalling (and not media). Qutecom *alreay* supports STUN, even if it only uses it for Wengo acounts. This is what doesn't make sense at all, it should (since it already can) use STUN for any kind of SIP account.

[cavedon]

Replying to ibc:

There is no a standard specifying it, and it doesn't seem very robust for me.

RFC3581 mentions that in section 9.

For example: the workaround you suggest would require Qutecom to send some OPTIONS (or whatever request) prior to the REGISTER. Of course, you cannot rely on the 407/401 reply for the first REGISTER since the registrar could instead reply a "403 Forbidden" due to the private address in Contact.

I never suggested sending OPTIONS. I would rely on REGISTER. Does not a 403 reply have a proper Via header?

But sincerelly I don't understand why you insist on this workaround that just solves signalling (and not media).

LOL, now I noticed we had the same conversation 1 month ago.

Actually the rport/received way has an advantage: if you are behind a symmetric NAT and the SIP server does not have a STUN server on the same port as the SIP protocol; using a separate STUN server won't work.

That said, I agree with you that having proper client and server STUN support is better!

[ibc]

Replying to cavedon:

Replying to ibc:

There is no a standard specifying it, and it doesn't seem very robust for me.

RFC3581 mentions that in section 9.

Right, I didn't read it :)

For example: the workaround you suggest would require Qutecom to send some OPTIONS (or whatever request) prior to the REGISTER. Of course, you cannot rely on the 407/401 reply for the first REGISTER since the registrar could instead reply a "403 Forbidden" due to the private address in Contact.

I never suggested sending OPTIONS. I would rely on REGISTER. Does not a 403 reply have a proper Via header?

Yes, it's also valid.

But sincerelly I don't understand why you insist on this workaround that just solves signalling (and not media).

LOL, now I noticed we had the same conversation 1 month ago.

Hummm, yes... sorry XD

Actually the rport/received way has an advantage: if you are behind a symmetric NAT and the SIP server does not have a STUN server on the same port as the SIP protocol; using a separate STUN server won't work.

Yes, in fact draft-outbound requires the SIP proxy having a STUN server running in port 5060 :)

That said, I agree with you that having proper client and server STUN support is better!

I insist on it isnce it's already implemented (or pseudo-implemented) in Qutecom.

[mike3050]

Replying to ibc:

Replying to cavedon:

Replying to ibc:

There is no a standard specifying it, and it doesn't seem very robust for me.

RFC3581 mentions that in section 9.

Right, I didn't read it :)

For example: the workaround you suggest would require Qutecom to send some OPTIONS (or whatever request) prior to the REGISTER. Of course, you cannot rely on the 407/401 reply for the first online auto insurance quotes REGISTER since the registrar could instead reply a "403 Forbidden" due to the private address in Contact.

I never suggested sending OPTIONS. I would rely on REGISTER. Does not a 403 reply have a proper Via header?

Yes, it's also valid.

But sincerelly I don't understand why you insist on this workaround that just solves signalling (and not media).

LOL, now I noticed we had the same conversation 1 month ago.

Hummm, yes... sorry XD

Actually the rport/received way has an advantage: if you are behind a symmetric NAT and the SIP server does not have a STUN server on the same port as the SIP protocol; using a separate STUN server won't work.

Yes, in fact draft-outbound requires the SIP proxy having a STUN server running in port 5060 :)

That said, I agree with you that having proper client and server STUN support is better!

I insist on it isnce it's already implemented (or pseudo-implemented) in Qutecom.

Thank you.I agree with you.

[cavedon]

In which was this issue fixed? I tried to find the changeset, but I could not...

[e_defranco]

I am sorry, but I don't understand: how and when this bug will be fixed ?? Now on the downladable version (linux and Win) not working.

[mikeqw]

Replying to ibc:

Replying to cavedon:

Replying to ibc:

There is no a standard specifying it, and it doesn't seem very robust for me.

RFC3581 mentions that in section 9.

Right, I didn't read it :)

For example: the cheap car insuranceworkaround you suggest would require Qutecom to send some OPTIONS (or whatever request) prior to the REGISTER. Of course, you cannot rely on the 407/401 reply for the first REGISTER since the registrar could instead reply a "403 Forbidden" due to the private buy adipex onlineaddress in Contact.

I never suggested sending OPTIONS. I would rely on REGISTER. Does not a 403 reply have a proper Via header?

Yes, it's also valid.

But sincerelly I don't understand why you insist on this workaround that just solves signalling (and not media).

LOL, now I noticed we had the same conversation 1 month ago.

Hummm, yes... sorry XD

Actually the rport/received way has an advantage: if you are behind a symmetric NAT and the cheap auto insurance SIP server does not have a STUN server on the same port as the SIP protocol; using a separate STUN server won't work.

Yes, in fact draft-outbound requires the SIP proxy having a STUN server running in port 5060 :)

That said, I agree with you that having proper client and server STUN support is better!

I insist on it isnce it's already implemented (or pseudo-implemented) in Qutecom.

Thank you.

[swatbolish]

I insist on it isnce it's already implemented (or pseudo-implemented) in Qutecom. registry cleaners