> Regarding your following comment;
> 
> "The transport type might not be the reason that they 
> are ignoring the request.  And if it is, there may be 
> a configuration issue."
> 
> Are you trying to say that, irrespective of session is 
> occurred using any transport, if the session termination 
> request (or any other mid-session request) is generated 
> using different transport, then also it shall be 
> entertained? Is such thing mentioned in any RFC?

No; I'm indicating that requests can fail for a variety of reasons which 
includes bad configuration.

However, yes; using the non preferred transport type may be entertained and is 
mentioned within the RFCs.

RFC 3261 section 18.1.1:

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

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

RFC 3263 section 4.1:

"Otherwise, if no transport protocol is specified, but the TARGET is a
 numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
 for a SIPS URI.  Similarly, if no transport protocol is specified,
 and the TARGET is not numeric, but an explicit port is provided, the
 client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI.  This is
 because UDP is the only mandatory transport in RFC 2543 [6], and thus
 the only one guaranteed to be interoperable for a SIP URI.  It was
 also specified as the default transport in RFC 2543 when no transport
 was present in the SIP URI.  However, another transport, such as TCP,
 MAY be used if the guidelines of SIP mandate it for this particular
 request.  That is the case, for example, for requests that exceed the
 path MTU."



_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to