Hi Siddhartha! Here are some excerpts from rfc's 3261 and 3263:
rfc 3261 Before a request is sent, the client transport MUST insert a value of the "sent-by" field into the Via header field. This field contains an IP address or host name, and port. The usage of an FQDN is RECOMMENDED. This field is used for sending responses under certain conditions, described below. If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. When a response is received, the client transport examines the top Via header field value. If the value of the "sent-by" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response MUST be silently discarded. rfc 3263 When a server is not able to send the response to the source IP it received in the via feild , the server examines the value of the sent-by construction in the topmost Via header. If it contains a numeric IP address, the server attempts to send the response to that address, using the transport protocol from the Via header, and the port from sent-by, if present, else the default for that transport protocol. The transport protocol in the Via header can indicate "TLS", which refers to TLS over TCP. When this value is present, the server MUST use TLS over TCP to send the response. Also there is no restriction on using DNS SRV for maddr ='hostname' pattern in via header but rfc 3261 does not say anything about it but i have the following excerpt from Jonathan Rosenberg: The intent of section 18.2.2 in rfc 3261 is indeed NOT to use the SRV processing. In fact, if you look at 18.1, the only way that the maddr gets set is through multicast, and thus the intent is that maddr is really for multicast. THis need not be an IP address, since DNS names can refer to multicast addresses (sip.mcast.net). Originally, the maddr in the URI was the same - meant just for multicast. However, in the absence of a suitable loose routing mechanism, it got continually abused until the common case was for that, and not for multicast at all. Doing that properly required SRV processing. Now, we have thankfully deprecated the usage of maddr for that purpose, but older rfc2543 elements might construct such URIs, and so RFC3263 continues to perform the SRV processing for the maddr in the request URI, when present. Thus the asymetry. I hope these quotes provides yu some insights. Regards Achint Aggarwal Siddhartha Bhakta <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/22/2006 11:31 PM To [email protected] cc Subject [Sip-implementors] DNS query and Via maddr Hi, Can anybody indicates whether DNS-SRV or DNS-A query shall be made if maddr in Via header is in hostname format and sent-by does not have port? It looks to me that for Via header, DNS-A query is suggested (port 5060 shall be used) whereas for other headers (Request URI, Route, Contact), DNS-SRV query is suggested in this case. Can anybody confirm this? Thanks, Siddhartha __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors *********************** Aricent- Confidential *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
