2008/9/29, Victor Pascual Ávila <[EMAIL PROTECTED]>:
> Iñaki, thanks for such a constructive response. Please, point the
> specification where I can find that using different transport
> protocols is not allowed within a transaction and I'll be more than
> happy to agree with your unreferenced arguments.
Obviously this issue is not well defined in RFC 3261, that's why it's
been handled in SIPit and in some mail threads like this one.
But IMHO a not well defined spec is not a excuse to allow "anything"
that would add complexity to the protocol.
Well, I read this in RFC 3261:
--------------------
18.2.2 Sending Responses
The server transport uses the value of the top Via header field in
order to determine where to send a response. It MUST follow the
following process:
o If the "sent-protocol" is a reliable transport protocol such as
TCP or SCTP, or TLS over those, the response MUST be sent using
the existing connection to the source of the original request
that created the transaction, if that connection is still open.
--------------------
Note that in case of TCP "the response MUST be sent using the existing
connection to the source of the original request that created the
transaction". For me this phrase assumes that the request came via
TCP.
Also:
------------------
8.1.1.7 Via
The Via header field indicates the transport used for the transaction
and identifies the location where the response is to be sent.
------------------
There it talks *clearly* about just ***one*** transport for the entire
transaction and it's obvious that the text expects the request and
responses using the same transport.
There my unreferenced arguments, please give me now your arguments to
allow exotical and useless features that would make SIP more complex
XDDD
(for other readers: Victor an me are friends XD).
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
