Hi Taisto, please, send an independent mail for each question, if not it will be impossible to understand the thread. I reply here just to question 1:
2009/4/29 Taisto Qvist XX <[email protected]>: > =========== > Question 1. > =========== > > 3263 says: > > If the URI specifies a transport protocol in the transport parameter, > that transport protocol SHOULD be used. > However, another transport, such as TCP, > MAY be used if the guidelines of SIP mandate it for this particular > request. > > 3261 says: > 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. > > So if a client registers a Contact: with "IP:Port;transport=UDP", > does he also have to listen to TCP? According to RFC 3261 it's a MUST. However, if the client is behind NAT it will just receive request using the same transport protocol as the used for the registration. > Since an incoming request just might be bigger than 1300 bytes... If the client registers with "Contact: xxxx;transport=udp" and the incoming message excedes 1300 bytes we have a problem. I don't expect there is an "official" behaviour for it. You could try to send it using TCP, or perhaps reject the request with "4XX Message too big". > ...and vice versa...if he's registered ;transport=TCP, should/MUST he > listen to UDP, in case the incoming proxy is rfc2543 and doesnt support > TCP? It doesn't make sense. It would mean that the user sent the REGISTER using UDP (since the proxy doesn't support TCP) but the Contact of the REGISTER says "transport=tcp". While this is valid according to RFC 3261, it's really strange. The proxy (not supporting TCP) could reject the REGISTER due to "4XX Contact protocol not supported". If not and the proxy accepts such registration, when it receives a request for this user it can: a) Reject the request with "500" error (transport layer sends 503 to the proxy core, and the proxy converts it into 500). b) Try to route the request using UDP to the user. Regards. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
