Nancy Greene wrote:
> 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.
When there is an intermediate hop before reaching the R-URI (your
assumption), then the URI for that intermediate hop is the *target*, not
the R-URI. This would typically by in the Route header, though you can
choose an intermediate destination by configuration as well if you wish.
In any case, it is only when the *next* hop is what is present in the
R-URI that the port number in the R-URI is of concern.
You will find a long section on target selection in 3261.
You might want to ask one of the other Ericsson people that participate
in ietf for help on this. (E.g. Christer Holmberg, Gonzalo Camarillo)
Thanks,
Paul
> Nancy
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> 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:f...@s.com: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:pkyzi...@cisco.com]
>> Sent: March-15-10 9:08 AM
>> To: Nancy Greene
>> Cc: sipc...@ietf.org
>> Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI?
>>
>> Nancy,
>>
>> Questions such as this should be brought to
>> <sip-implementors@lists.cs.columbia.edu>.
>>
>> 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
>>> sipc...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
