#27: Unroutable Contact SIP header if behind NAT
----------------------+-----------------------------------------------------
Reporter: cavedon | Owner: vadim
Type: defect | Status: new
Priority: major | Milestone:
Component: phapi | Version: 2.2-RC3
Resolution: | Keywords:
----------------------+-----------------------------------------------------
Comment(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.
--
Ticket URL: <http://trac.qutecom.org/ticket/27#comment:9>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
QuteCom-dev@lists.qutecom.org
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
