[Serusers] problems with stun using uas

[lorenzo]

Nils Ohlmeier wrote:
> Am 22.08.09 17:50, schrieb lorenzo:

>
> Sorry, but if it runs on a public IP, why do you use STUN at all?
> Or are you just referring with "have" to the fact that your app "has"
> successfully determined the public IP of its router?

yes, what i was trying to say here is that the app correctly
*discovered* the  router's public ip through a query to a stun server.

> The major difference in the messages below which I can spot is the IP
> address in the Via header. Gizmo puts its private IP in the Via header,
> where yours puts the public IP in the Via header.
> SER's NAT support has functions to check the Via header for indications
> of a NAT. It might be that your public IP mis-leads these check to
> believe that your app does not need NAT traversal support (which it
> obviously really does not need if it runs on a public IP anyway). But as
> Martin wrote: we do not have access to sipphone's SER config, so we
> can't tell you which NAT checks they perform.
>
> My guess is, that your app is the classic example of the wrong usage of
> STUN. Your REGISTER request does not contain a single indication any
> more that your app is actually running behind a NAT. So how should SER
> be able to identify you as being behind a NAT?

my understanding of the whole nat/sip issue was that, once i forge my
REGISTER request with a public ip, then the server need not know the uac
is actually residing in a private network. thus, no special actions need
to be taken by the server, as it can simply send packets to my router's
public ip, and the router will route the packets back to the correct
host. as far as ports go, i thought rport solved the issue.
if that's the case, then SER shouldn't even need to know i'm behind a NAT.
am i correct?

one difference i see is that the response to my app's REGISTER request
(rightfully) has no "received" parameter in the VIA field - since the IP
packet's source address matches the "sent-by" parameter - but has an
rport parameter.
could that be the cause of the problem?

> (That you are using the rport parameter is not enough, because as your
> username already suggests: this is just an indication that you are doing
> asymmetric SIP signaling (which is deprecated and totally broken if you
> are behind a NAT anyway).)

my username has nothing to do with sip :)
excuse my ignorance, but what exactly is asymmetric SIP signaling?

> Cheers
>   Nils

thanks a lot for your interest,
asymmetric