Hi, DaleIn the new forking mechanism, UAC will wait for all the final responses,but when does the client transaction pass the response up to the TU? doesit have any impact to the INVITE client transaction handling?according to RFC 3261 ，if the UAC receives a non-2xx response, the clienttransaction enters the "completed" state, and passes the received responseup to the TU. any responses received later will be viewed as retransmissionsof the first response. they MUST NOT be passed up to the TU. In this case,even though the later response is 2xx, the dialog will not be created. If there is any problem, please correct me. Detailed description in RFC 326117.1.1.2“When in either the "Calling" or "Proceeding" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to "Completed". The client transaction MUST pass the received response up to the TU“ And “Any retransmissions of the final response that are received while in the "Completed" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU“ 17.1.3“If a request is sent via multicast, it is possible that it will generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To tag. The first response received, based on the rules above, will be used, and others will be viewed as retransmissions.“ -----邮件原件-----发件人: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] 代表 DaleWorley发送时间: 2009年3月5日 2:24收件人: SIPPING主题: Defining forking to multiple destinations better I've refreshed my I-D regarding "Request-Disposition: no-cancel,parallel": A new version of I-D, draft-worley-sipping-forking-03.txt has beensuccessfuly submitted by Dale Worley and posted to the IETF repository. Filename: draft-worley-sipping-forkingRevision: 03Title: A New Forking Mechanism for Session Initiation Protocol(SIP)Creation_date: 2009-03-03WG ID: Independent SubmissionNumber_of_pages: 17 Abstract:The rules for SIP proxies are organized so that when a UAC sends anout-of-dialog request, even if the request is forked to a number of UASs,(usually) only one UAS will accept the request, and only the final responsefrom that UAS will be returned to the UAC. This forking mechanism isoptimal for an INVITE intended to connect one human user with another humanuses, but is poor for requests that have a "one to many" nature, especiallyPUBLISH and SUBSCRIBE requests, but also including some INVITEs. Thisdocument proposes an alternative forking mechanism that better supports "oneto many"requests, and that mechanism be the standardized meaning of the (existingbut weakly specified) "Request-Disposition: no-cancel, parallel" header. The IETF Secretariat. _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIP Usesip-implementors@xxxxxxxxxxxxxxx for questions on current sip Usesip@xxxxxxxx for new developments of core SIP _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
