Hi Jonathan, Do you agree with Paul's interpretation concerning advancement to the next transport (next NAPTR record or set of SRV records)?
My interpretation was that advancing between transports has been removed. There are likely good reasons for and against advancing between transports. I am just trying to understand what rfc3263, rfc2915, and rfc3261 indicate or should have indicated. Thanks in advance, Brett Tate > RFC3263, section 4.1, contains the following text > > If no NAPTR records are found, the client > constructs SRV queries for those transport > protocols it supports, and does a query for > each. Queries are done using the service > identifier "_sip" for SIP URIs and "_sips" > for SIPS URIs. A particular transport is > supported if the query is successful. The > client MAY use any transport protocol it > desires which is supported by the server. > > This means that potentially the set of > SRV records covers multiple protocols in > the case that no NAPTR records are returned. I interpret the text as indicating that one transport should be selected instead of potentially combining the multiple sets of srv records. > It therefore seems only sensible to me > that if multiple transports are indicated > by NAPTR records, that they too should be > tried, in the order indicated by the NAPTR > records. Hopefully there would have been a statement indicating when to advance to the next NAPTR record. Or there could have been a statement indicating the combining of all the SRV records for each NAPTR record. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
