In fact the issue has been more intutive and logical in the case of
RFC-3263. The RFC expects no port to be attached to a domain name
specification. Why should a port be attached to a domain name? The port
anyway will be available according to the SRV query. Hence if a port is
present, then the name is considered a host.
Hence in the example
sip:[EMAIL PROTECTED]:5060 , example.com is considered a host and not a
domain.
In the RFC-2543 bis also, the SRV query was allowed if a port is present
only if the port was the default port. Even in RFC-2543
sip:[EMAIL PROTECTED]:5062 , example.com is considered a host.
Quoting from RFC-2543-bis02 Section 1.4.2, page 10
" 3. The Request-URI is examined. If it contains no port number
or port 5060, ...........
.............
If the Request-URI contains a port number other than 5060
or if there are no SRV records, the client queries the DNS
server for address records for the destination address. "
Hence this singular condition has been removed, thats all.
I guess this is clarified in RFC-3263 quite sufficiently.
Regards,
Prasanna
Huawei Technologies.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Affan Ahmed
Sent: Monday, December 02, 2002 10:54 AM
To: [EMAIL PROTECTED]
Subject: [Sip-implementors] RFC3263-Section 4.2..confusion
Hello everyone,
I have been confused by the following scenario. Say that a user of a
sofphone enters the following URI: sip:[EMAIL PROTECTED]:5060. Assume
that the transport is already specified. Now RFC has changed the
behavior from rfc 2543 such that client now performs a A/AAAA query of
example.com. Since example.com is a domain (zone with reference to
BIND) it does not posses a valid IP and such a query fails. In my
ignorance it appears to me that the result ( as suggested in section
4.2) of getting a list of IP's isnt logical. I mean making a A or AAAA
query of an entire domain does not make sense specially if we want to
find a SIP proxy in that domain. Why is this specific change suggested
in the newer RFC while in the last one we would have performed an SRV
query which would have resolved us the SIP proxies in the domain.
Could anyone shed some light on this?
Best Regards
Affan Ahmed.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
