答复: Defining forking to multip le destinations better

Hi, Dale
In 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? does
it have any impact to the INVITE client transaction handling?
according to  RFC 3261 ，if the UAC receives a non-2xx response, the client
transaction enters the "completed" state, and passes the received response
up to the TU. any responses received later will be viewed as retransmissions
of  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 3261
17.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.“


-----邮件原件-----
发件人: [email protected] [mailto:[email protected]] 代表 Dale
Worley
发送时间: 2009年3月5日 2:24
收件人: SIPPING
主题: [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 been
successfuly submitted by Dale Worley and posted to the IETF repository.

Filename:        draft-worley-sipping-forking
Revision:        03
Title:           A New Forking Mechanism for Session Initiation Protocol
(SIP)
Creation_date:   2009-03-03
WG ID:           Independent Submission
Number_of_pages: 17

Abstract:
The rules for SIP proxies are organized so that when a UAC sends an
out-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 response
from that UAS will be returned to the UAC.  This forking mechanism is
optimal for an INVITE intended to connect one human user with another human
uses, but is poor for requests that have a "one to many" nature, especially
PUBLISH and SUBSCRIBE requests, but also including some INVITEs.  This
document proposes an alternative forking mechanism that better supports "one
to many"
requests, and that mechanism be the standardized meaning of the (existing
but weakly specified) "Request-Disposition: no-cancel, parallel" header.
 



The IETF Secretariat.




_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email protected] for questions on current sip Use
[email protected] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP