25 Aug
2009
25 Aug
'09
6:30 p.m.
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