title: SIP dialog established via UDP - what is the transport AFTER a large SIP request has been sent via TCP?
body: <p>Given a SIP dialog (INVITE, 200 OK, ACK) has been established via UDP; And a large message gets sent that requires TCP as transport.
  <strong>What is the applied transport protocol after the large message has been sent for all other following (and normal sized) messages?</strong></p>
  <p><em>Does the protocol switch to TCP for all further request/responses or does it keep using the initially negotiated transport - UDP - for standard sized (NOT large) messages?</em></p>
  <hr />
  <p>What I found (based on RFC 3261):</p>
  <blockquote>
  <p>All SIP elements MUST implement UDP and TCP.  SIP elements MAY<br />
  implement other protocols.
  <em>- from <a href="https://datatracker.ietf.org/doc/html/rfc3261#section-18" rel="nofollow noreferrer">rfc3261#18</a></em></p>
  </blockquote>
  <blockquote>
  <p>The ACK MUST be sent to the same address,
  port, and transport to which the original request was sent.
  <em>- from <a href="https://datatracker.ietf.org/doc/html/rfc3261#section-18" rel="nofollow noreferrer">rfc3261#18</a></em></p>
  </blockquote>
  <p>Okay that says NOT all requests (especially ACK) are able to choose the transport independently.</p>
  <blockquote>
  <p>Making TCP mandatory for the UA is a substantial change from RFC
  2543.  It has arisen out of the need to handle larger messages,
  which MUST use TCP, as discussed below.  Thus, even if an element
  never sends large messages, it may receive one and needs to be
  able to handle them.
  <em>- from <a href="https://datatracker.ietf.org/doc/html/rfc3261#section-18" rel="nofollow noreferrer">rfc3261#18</a></em></p>
  </blockquote>
  <p>During an established dialog a UAS/UAC never knows if the need for a large message arises - switching from UDP to TCP is just fine (without any RE-INVITE that changes the transport in advance to the actual request).</p>
  <blockquote>
  <p>A 301 (Moved Permanently) or 302 (Moved Temporarily)    response may
  also give the same location and username that was    targeted by the
  initial request but specify additional transport    parameters such as
  a different server or multicast address to try, or    a change of SIP
  transport from UDP to TCP or vice versa.
  <em>- from <a href="https://datatracker.ietf.org/doc/html/rfc3261#section-8.3" rel="nofollow noreferrer">rfc3261#8.3</a></em></p>
  </blockquote>
  <p>not really relevant - the UAS may want to change the transport suggested by the UAC; but that is based on the reaction onto some INVITE (or RE-INVITE) only</p>
  <blockquote>
  <p>The destination address,
  port, and transport for the CANCEL MUST be identical to those used to
  send the original request.
  <em>- from <a href="https://datatracker.ietf.org/doc/html/rfc3261#section-9.1" rel="nofollow noreferrer">rfc3261#9.1</a></em></p>
  </blockquote>
  <p>Okay CANCEL (like ACK) also must NOT independently choose the transport.</p>
  <blockquote>
  <p>If a request is within 200 bytes of the path MTU, or if it is larger
  than 1300 bytes and the path MTU is unknown, the request MUST be sent
  using an RFC 2914 [43] congestion controlled transport protocol, such
  as TCP. If this causes a change in the transport protocol from the one
  indicated in the top Via, the value in the top Via MUST be changed.</p>
  </blockquote>
  <p>That says if the SIP dialog was established via UDP, it has to be able to receive TCP requests also.</p>
  <blockquote>
  <p>For any port and interface
  that a server listens on for UDP, it MUST listen on that same port and
  interface for TCP.  This is because a message may need to be sent
  using TCP, rather than UDP, if it is too large.  As a result, the
  converse is not true.  A server need not listen for UDP on a
  particular address and port just because it is listening on that same
  address and port for TCP.  There may, of course, be other reasons why
  a server needs to listen for UDP on a particular address and port.</p>
  </blockquote>
  <p>Okay that explains how switching from UDP to TCP works seamless. - And for the other direction it is just not required, but (I understand like: it still MAY work).</p>