The transport parameter in some headers of the message will need to be updated to TCP, as well, when the transport changes. VIA and ReqUri MUST be updated. If a Route set is in use, it should probably be updated so that subsequent transactions will continue to use the TCP connection. On an established dialog without a Route set, the Contact header transport also SHOULD be updated for ensuring the UAS will use the TCP connection for subsequent requests.
Then, if the TCP connection cannot be established (for SRV scenario, the tcp server can be selected; for non-SRV scenarios, it is possible the server does not support TCP; in either case, the attempted server may be down), the packet should be sent on UDP after all the affected headers are updated back to UDP. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Penfield Sent: Tuesday, April 04, 2006 6:46 AM To: Markus Hofmann; Jeroen van Bemmel; [email protected] Subject: Re: [Sip-implementors] Transport layer changes transport. 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
