Subject: [Sip] Selecting a Transport Protocol

From: Richard Aas <[email-masked]>
Date: Wed, 15 Mar 2006 10:13:22 +0100

Hi all,

I need some clarification regarding message size and transport
protocol selection.

RFC3261 states that requests within 200 bytes of the path MTU MUST
be sent using a reliable transport protocol (eg. TCP).  However, it
also states that if an element sends a request over TCP because of
these message size constraints, and the request would have otherwise
been sent over UDP, if a transport error is detected, the element
SHOULD retry the request, using UDP.

Does the above requirements imply that you (in the worst case) have
to go through the DNS procedures of RFC3263 twice for one request?

Assume you want to send a request to a URI where the domain part is
not an IP-address and the port number is not present. I can come up
with at least three ways of approaching this:

1. Select TCP transport based on message size and do a SRV query
    (_sip._tcp.domain) If a transport error is detected (or transaction
    timeout occurs), for all the candiates resolved, start from scratch
    with a NAPTR (or perhaps an UDP SRV) query.

2. Start with a NAPTR query (as you would have done for a smaller message)
    and exclude resource records representing unreliable transports (UDP)
    from the answer when selecting a transport protocol. Then, if a transport
    error is detected (or transaction timeout occurs) for all the candiates
    resolved, start from scratch with a NAPTR query (and include all
    supported resource records in the answer when selecting transport
    protocol) Or perhaps exclude the reliable transport that just failed.
    Or maybe do an UDP SRV query...

3. Follow the procedure of RFC3263 as normal, and switch the transport protocol
    to TCP, if UDP was resolved, just before sending the request. If this request
    fails, switch back to UDP and use the resource records already resolved for
    redundancy.

I guess approach #3 is somewhat mentioned implicitly in RFC3261 in that the
server must listen on the same ports/interfaces for TCP as for UDP. The
question is; is approach #3 the one to be recommended?

If the transport URI parameter suggests UDP (for a large message), I guess
the proper solution is just to override this?

Regards,
Richard

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Thomas Froment <[email-masked]>
Date: Wed, 15 Mar 2006 10:55:26 +0100

see inline...

> question is; is approach #3 the one to be recommended?

In my opinion, this is the right one, no need to make RFC 3263
resolution twice.
the 3261, section 18.1.1 on  path MTU just "overrides" the resolved
transport for the specific case of messages having size > MTU size-200...

> the proper solution is just to override this?

It seems yes, at first I found it somewhat surprising since it means a
request URI with explicit transport=UDP parameter, can still  lead to
send a request in TCP, but it appears to be the correct behavior...

Thomas