[Sip] Questions about request message larger than 1300 bytes

Hello,

        I have some questions about handling SIP msgs that are larger than 1300 bytes. RFC 3261, chapter 18 as listed, mentions that
if request message is larger than 1300 bytes, it MUST be sent using TCP because of the meesage size constraints. But I don’t know
how to handle the following scenarios, could anyone help me? 

1. The UA1 registers to Proxy/Registrar with “transport=udp” or without “transport” parameter. According to RFC3261, the proxy
should try to send the request message to UA1 using default transport, which means UDP. Now suppose that a request comes and is
larger than 1500, what should the proxy do? Still try UDP first or always use TCP to send the request to UA1? If the proxy selects
the first stretagy, and, unfortunately, the message is splitted into more than one pieces and only the first one is received by UA1.
The received message is incorrect and might cause UA1 to do incorrect response. Can the proxy select the second stretagy, i.e, using
TCP, even the client only registers with “transport=udp”? Which stretagy is correct or better?

2. The UA2 sends the request to proxy using UDP with request message size smaller than 1300 bytes. The Via header in the request is
UDP. But the response backs to the proxy is larger than 1500 bytes. What should the proxy do? Using TCP or UDP to transmit the
response to UA2?

Any acknowledgement will be deeply appreciated.

Sincerely,

Fish

“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. This prevents fragmentation of messages
over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the
maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers.

The 200 byte "buffer" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the
request. This happens due to the addition of Record-Route header field values to the responses to INVITE, for example. With the
extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes is
consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet
MTU.

If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent
over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the
element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations
that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification.”