Hi Jeroen, "If timer A was started, you would have to cancel it" - excactly this is my problem. How can the transaction layer found out, that the transport was changed?
Regards, Markus Jeroen van Bemmel wrote: > Markus, > > The RFC describes externally observable behavior, so from that > perspective there is no change in transport at the UAC. Also, there is > no concept of a "UDP" transaction or a "TCP" transaction - it is the > same transaction, only the request is sent over a different transport > > That being said, from a software design perspective your scenario is > very well possible - i.e. the UAC layer selects UDP, but the transport > layer ends up using TCP (and modifies the Via header accordingly). If > timer A was started, you would have to cancel it > > Regards, > > Jeroen > > ----- Original Message ----- From: "Markus Hofmann" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, April 03, 2006 6:24 PM > Subject: [Sip-implementors] Transport layer changes transport. > > >> Hi @all, >> >> I have a question about the transport type. >> >> 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. A Via >> header field value is added only after the transport that will be >> used to reach the next hop has been selected (which may involve the >> usage of the procedures in [4]). >> >> So far I understand the User Agent makes an DNS SRV and gets the >> transport type which is used in the Via header. >> >> The transaction layer creates the transaction. >> >> 17.1 Client Transaction >> >> The client transaction provides its functionality through the >> maintenance of a state machine. >> >> The TU communicates with the client transaction through a simple >> interface. When the TU wishes to initiate a new transaction, it >> creates a client transaction and passes it the SIP request to send >> and an IP address, port, and transport to which to send it. The >> client transaction begins execution of its state machine. Valid >> responses are passed up to the TU from the client transaction. >> >> Then I read this in 18. >> >> 18.1.1 Sending Requests >> >> [...] >> >> 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 DNS SRV query found out that UDP and TCP is allowed. The User agent >> decides to use UDP and the transaction layer creates an client INVITE >> transction for UDP (with Timer A for retransmission). >> The transport layer found out that the message is too big and MUST >> change the transport proctol to TCP. What happens with the UDP >> transaction? Did I understand the RFC right that it is possible that the >> transport type (TCP or UDP) could be changed? >> >> Thank you, >> Markus >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
