The transaction layer would not start Timer A until it was told by the transport layer that the message was sent on UDP.
cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] ----- Original Message ----- From: "Markus Hofmann" <[EMAIL PROTECTED]> To: "Jeroen van Bemmel" <[EMAIL PROTECTED]>; <[email protected]> Sent: Tuesday, April 04, 2006 2:09 AM Subject: Re: [Sip-implementors] Transport layer changes transport. > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
