#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):
Replying to [comment:12 cavedon]:
> Replying to [comment:11 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.
--
Ticket URL: <http://trac.qutecom.org/ticket/27#comment:13>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
QuteCom-dev@lists.qutecom.org
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
