21 Mar
2006
21 Mar
'06
3:55 p.m.
Hi Arek,
Arek Bekiersz wrote:
Hi Bogdan,
Thanks for all the help.
Bogdan-Andrei Iancu wrote:
it's not about RFC compliance here, but about making it work, about the
logic used to detect and traverse NATS , things that are not specified
by RFC.
I guess it should be reasonable from them to accept to make this auto
NAT detection configurable in order to disable it.
alternative solutions will be (1) to consider all these UAC as nated -
by looking at UA hdr- or (2) to try to remember the NAT flag from the
non-authenticated REGISTER until the auth-ed one - the first
(challenged) register will reveal the true status of the clients (nated
or not) as it's also used by client for nat detection....but I guess it
will be quite complicated
regards,
bogdan
Hi Arek,
looking on the signalling, you cannot detect the call as nated from
proxy point of view, so there is not much you can do. It's a
typically situation where the the phones tries to perform nat
traversal on its sides but does not do a complete job, preventing
also the proxy to do it :(
So what is your final advice about how to speak with German vendor?
They are not violating RFC, but clearly, ther device will NOT work
with SER or OpenSER in NAT-traversal scenario.
They say to us everytime that they "sold approx. 2 milion of those
boxes and nobody, no ISP complained". I do not believe at all - this
is DSL router/modem, so maybe they talk about non-VoIP and VoIP boxes
together. But you will never know, this is marketing talk..
They say that "ITU-T has given them an approval. This approval
described that they are fully compatible with the RFC´s for VoIP".
Well, yes, they do not break RFC. But one flavour of this device is an
ATA box, without DSL modem. Majority of my customers will buy this ATA
to use with existing DSL router, cable modem/router or such. They WILL
have unfriendly NAT there, so what is the sense of ATA box?