In principle, your point is totally valid. That's the inherit problem of
combining UDP and NAT.
OTOH, human intelligence is important in proper implementation.
Looking closer to the problem, if the UA is capable of detecting what kind
of NAT router it is behind, it SHOULD put the correct connection info for
BOTH SIP and SDP packet, either public IP or FQDN of the NAT router, not
private IP nor FQDN of the device itself.
If the UA is not capable of detecting NAT, the method we just tried could
help. However, those products shall been dump into the bin, as least I will
do so.
If UA is not behind NAT but having FQDN only resolvable internally, it's the
network administrator's fault. That device should not be put on the public
internet. Will you setup a web server for the general public that no one
else can resolve the IP?
Zeus
-----Original Message-----
From: Nils Ohlmeier
Sent: Thursday, 16 June 2005 7:45 AM
To: serusers(a)lists.iptel.org
Cc: Gerhard Zweimüller; Zeus Ng
Subject: Re: [Serusers] DNS Resolution of SDP-"Connection
Address" at SER
Just a short note and/or question: how are FQDN in SDP
suppose to work if the
FQDN is only resolveable in the local network (especially
behind NAT)? And how should or can a UA determine if its FQDN
is only locally resolveable
or not?
IMHO FQDN in SDP only introduces additional trouble with NATs.
Regards
Nils
On Monday 13 June 2005 15:03, Gerhard Zweimüller wrote:
Thanks for your answer.
The funny thing is: I am trying quite hard to convince the vendor
(actually a well-known VoIP-chip/module/appliance maker)
that FQDN in
SDP is a good (and allowed) thing.
Even more funny: In the preceding firmware-release FQDN was no
problem. But in the current release they apparently *removed* the
FQDN-support and now they try to convince me that FQDN in
SDP is not
allowed :-( Although I sent them RFCs and
everything to prove them
wrong.
But there you go.
I tried your suggestion with fix_nated_sdp and so far it seems to
work. Thanks for the tip!
Hopefully the vendor will change its RFC-support policy soon.
Kind regards,
Gerhard
-----Original Message-----
From: Zeus Ng [mailto:zeus.ng@isquare.com.au]
Sent: Sunday, June 12, 2005 8:30 AM
To: Gerhard Zweimüller
Cc: serusers(a)lists.iptel.org
Subject: RE: [Serusers] DNS Resolution of SDP-"Connection
Address" at
SER
Forcing SER to do stuff in order to fix problem UA
implementation, I
don't think this is a good approach. Using
FQDN as connection
information in SDP is the recommended approach in RFC 2327,
though few
UA do this. I would suggest you contact the
vendor to fix
the UA that
can't work with DNS.
Have a look on the fix_nated_sdp() function in nathelper. I haven't
tried this before but it might work. However, there is no
guarantee.
Let us know if it works.
> -----Original Message-----
> From: Gerhard Zweimüller
> Sent: Saturday, 11 June 2005 11:07 PM
> To: serusers(a)lists.iptel.org
> Subject: [Serusers] DNS Resolution of SDP-"Connection Address" at
> SER
>
>
> Hi Serusers,
>
> I have a problem with DNS resolution in SIP/SDP "Connection
> Information" / "ConnectionAddress". Maybe somebody can help me:
>
> In the network we use SIP-UAs that are integrated into
ADSL-Modems
> from Allied Telesyn (AT RG 634). The
SIP-client itself
works OK. But
> when the unit is given a system-name in the
configuration, it will
> always use its DNS-name instead of its
IP-addr as "Connection
> Address" in the "Connection Information" in SDP in INVITE and
> corresponding OK messages.
>
> Now we want to add SIP-UAs that are NOT capable of resolving
> DNS-Names in the "Connection Address" field. Alle messages pass
> through SER of course and the SDP-part so far remains unchanged.
>
> Now my question to the list:
> Is there a simple way of forcing SER to do the
DNS-resolution of in
> incoming message, put in the IP-address in
"Connection
Address" and
forward
it to the other UA?
Thanks a lot in advance!
Gerhard
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_____________________________________________________________
______________
_______ Dieses Mail wurde vom Infotech SecureMail
Service
ueberprueft und
fuer sicher befunden. Fuer weitere Informationen
zu
Infotech SecureMail
Service waehlen Sie bitte:
www.infotech.at/securemail/
This email has been scanned by Infotech SecureMail Service
and it has
been classified as secure. For more information
on Infotech
SecureMail
direct your web browser to:
www.infotech.at/securemail/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers