Re: 答复: Defining forking to mult iple destinations better

On Thu, 2009-04-09 at 11:55 +0800, fanyanping wrote:
> 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. 

Yes, if "no-cancel" is to be of any use, the UAC must be prepared to
receive multiple 2xx responses to its request.  And so its SIP stack
must have a way to return those multiple 2xx responses to the the higher
layers of the code.

When "cancel" (ordinary) processing is used, the UAC receives only one
final response, and when that response is received, the UAC knows the
transaction is done.  With "no-cancel" processing, the UAC never knows
(except for time-out) when it has seen the last final response.

Dale


_______________________________________________
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