Opened 4 years ago
Last modified 3 weeks ago
#27 reopened defect
Unroutable Contact SIP header if behind NAT
| Reported by: | cavedon | Owned by: | vadim |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | phapi | Version: | 2.2 |
| Keywords: | Cc: |
Description
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).
Change History (22)
comment:1 Changed 4 years ago by forest
comment:2 Changed 4 years ago by 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.
comment:3 follow-up: ↓ 5 Changed 4 years ago by 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.
comment:4 Changed 4 years ago by laurent
Qutecom implements STUN with Wengo type account. With sipaccount, search in the mailing-list,there is a patch.
comment:5 in reply to: ↑ 3 Changed 4 years ago by 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).
comment:6 Changed 4 years ago by ibc
That just solves NAT for signalling, not for media :(
comment:7 Changed 4 years ago by cavedon
Yes, I agree.
I opened this ticket only for the "Contact:" address. Fixing this would allow registering on ekiga.net.
comment:8 Changed 4 years ago by gazambuja
- Version set to 2.2-RC3
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
comment:9 follow-up: ↓ 10 Changed 4 years ago by 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.
comment:10 in reply to: ↑ 9 Changed 4 years ago by 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)
comment:11 follow-up: ↓ 12 Changed 4 years ago by 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.
comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 4 years ago by 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!
comment:13 in reply to: ↑ 12 Changed 4 years ago by 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.
comment:14 Changed 3 years ago by chris-mac
- Milestone set to QuteCom 2.2-RC4
- Version changed from 2.2-RC3 to 2.2
comment:15 Changed 3 years ago by laurent
- Milestone changed from QuteCom 2.2-RC4 to QuteCom 2.5
comment:17 Changed 3 years ago by cavedon
In which was this issue fixed? I tried to find the changeset, but I could not...
comment:18 Changed 3 years ago by e_defranco
- Status changed from new to reopened
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.
comment:21 Changed 3 years ago by cavedon
comment:26 Changed 2 years ago by cavedon
comment:30 in reply to: ↑ 29 Changed 2 years ago by dneary
Gah. Spam comments now.
Dave.
Replying to capatana:
I insist on it isnce it's already implemented (or pseudo-implemented) in Qutecom
Best practices for dealing with such problems:
http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-09