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@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@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@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/
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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Gerhard Zweimüller -
Nils Ohlmeier -
Zeus Ng