On Mon, May 18, 2015 at 6:12 AM, Brett Tate <br...@broadsoft.com> wrote:
> Thanks for the response. However, that snippet refers to proxy behavior > instead of the client behavior. It looks RFC 5626 section 4.3 continues to > have the client analyze Record-Route (or Contact) to determine the address, > port, and transport. > > > > “The UAC performs normal DNS resolution on the next hop URI (as > > described in [RFC3263]) to find a protocol, IP address, and port. > > For protocols that don't use TLS, if the UAC has an existing flow to > > this IP address, and port with the correct protocol, then the UAC > > MUST use the existing connection. > > > This is correct. In the RFC 7118 there should have been a SIPS URL in the record route. If it were a SIPS URL with transport WS, then the example would have been cleaner. In practice, though, all the WS SIP clients have a pre-configured WS SIP proxy and they send all the requests, including subsequent in dialog requests, through it. Since WebBrowser based clients can only do simple DNS resolution, they cannot do complete RFC3263 next hop resolution and they have to upload this to a proxy up stream. I think this was the intent of the provided example, but it was not clearly stated in the RFC. In any case, there is no need for WSS URL transport parameter (as there was never a real need for tls URL transport parameter). Is your intent to point the issue with the RFC example or to figure out the correct implementation strategy? _____________ Roman Shpount _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
