[Serusers] DNS Resolution of SDP-"Connection Address" at SER

Zeus Ng zeus.ng at isquare.com.au
Thu Jun 16 02:00:44 CEST 2005


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 at 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 at isquare.com.au]
> > Sent: Sunday, June 12, 2005 8:30 AM
> > To: Gerhard Zweimüller
> > Cc: serusers at 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 at 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 at 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 at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> 




More information about the sr-users mailing list