Ok, thanks, but what about this paragraph? If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously. The client SHOULD try the first record. If an attempt should fail, based on the definition of failure in Section 4.3, the next SHOULD be tried, and if that should fail, the next SHOULD be tried, and so on.
Nancy -----Original Message----- From: Paul Kyzivat [mailto:[email protected]] Sent: March-15-10 10:42 AM To: Nancy Greene Cc: SIP-implementors mailing list Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? switching to sip-implementors list Nancy Greene wrote: > Thanks for the answer, but I'd like to know why the RFC is written the way it > is. > > What if there is an intermediate SIP proxy between the target in the > Request-URI and the proxy trying to reach it? That intermediate SIP proxy > does not allow traffic on the port mentioned in the Request-URI, so the > request fails to reach the target. This does not seem right. Shouldn't the > RFC at the very least require a retry at the port that the intermediate proxy > expects traffic on? I think you must be missing something fundamental. I think the following describes what you are asking about: C ----- P ------ S where the message from C is something like: INVITE sip:[email protected]:12345 Route: sip:p.com ... In the above case C would be sending the request to P using the result of SRV lookup on p.com. The port number in the R-URI is irrelevant to how the request is sent to P. Once the request reaches P, it will then use the R-URI to decide where to forward the request. So then the port number 12345 will be relevant. Thanks, Paul > Nancy > > -----Original Message----- > From: Paul Kyzivat [mailto:[email protected]] > Sent: March-15-10 9:08 AM > To: Nancy Greene > Cc: [email protected] > Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? > > Nancy, > > Questions such as this should be brought to > <[email protected]>. > > To answer your question... > > The port from the URI is to be used *if* it is present in the URI. > (Would you prefer to *ignore* it?) > > If the the port is *not* present in the URI, then the port is obtained from > DNS via the SRV query. That is explained further on in the same section of > the document. > > Thanks, > Paul > > > Nancy Greene wrote: >> I have a question on section 4.2 of RFC 3263: >> >> Why is it that the port of the Request-URI is required to be used for an >> intermediate proxy? Is the issue that it is not known whether the next hop >> proxy is intermediate or is the actual destination in the Request-URI? >> >> If so shouldn't there at least be a procedure described to use the port from >> DNS instead of the one in the Request-URI if sending to the one in the >> Request-URI fails? >> >> Section 4.2 from RFC 3263 (locating SIP servers): >> >> If the TARGET was not a numeric IP address, but a port is present >> in the URI, the client performs an A or AAAA record lookup of the >> domain name. The result will be a list of IP addresses, each of which >> can be contacted at the specific port from the URI and transport >> protocol determined previously. >> >> Nancy >> >> >> _______________________________________________ >> sipcore mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
