search

usnistgov / jsip

JSIP: Java SIP specification Reference Implementation (moved from java.net)
Other
288 stars 131 forks source link

Does the stack automatically upgrade the transport protocol for large messages? #23

Open irevans opened 7 years ago

irevans commented 7 years ago

Section 18.1.1 of RFC 3261 states:

"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."

Does the jsip stack support upgrading the transport protocol of a request from UDP to TCP as per the above text?

vladimirralev commented 7 years ago

If the jsip is on the receiving end and transaction-stateful it should work.

Otherwise no, the jsip stack has no way of knowing the path MTUs or if the remote side can accept tcp, which is optional. It is up to the application to make that decision. I have a lot of problems with this personally, it's very rare that in-call transport change will be accepted. Especially if the remote side is behind a NAT using a UDP hole, the TCP attempt will fail. Another issue is when you need to upgrade a response on existing udp transaction, can't change the Via transport for the response only. Overall, very little practical use for this section of the RFC.

irevans commented 7 years ago

Thanks for the response, its good to know where the stack stands.

However, I do feel there is a case for supporting this in the stack. Support for TCP is mandatory in RFC 3261:

All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.

  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.

Section 18.

Also, there is no need to know the MTU path. As the spec says, if the request "is larger than 1300 bytes and the path MTU is unknown the request MUST be sent using an RFC 2914 congestion control transport protocol...".

I understand your point about not being able to upgrade the transport for responses, but I do not think this warrants not upgrading the transport for requests.

I think it's pretty undesirable to do this from the application since checking whether a Request exceeds a certain size would mean that the application would need to convert the Request object into bytes, which is something that is normally reserved for the stack and something the stack already does to send the request.