#27: Unroutable Contact SIP header if behind NAT
----------------------+-----------------------------------------------------
Reporter: cavedon | Owner: vadim
Type: defect | Status: closed
Priority: major | Milestone: QuteCom 2.5
Component: phapi | Version: 2.2
Resolution: fixed | Keywords:
Field_os: all |
----------------------+-----------------------------------------------------
Changes (by mike3050):
* status: new => closed
* field_os: => all
* resolution: => fixed
Comment:
Replying to [comment:13 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 [http://zolpo.com/auto-
insurance/ 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.
--
Ticket URL: <http://trac.qutecom.org/ticket/27#comment:16>
QuteCom <http://trac.qutecom.org>
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
