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 toreceive multiple 2xx responses to its request. And so its SIP stackmust have a way to return those multiple 2xx responses to the the higherlayers of the code. When "cancel" (ordinary) processing is used, the UAC receives only onefinal response, and when that response is received, the UAC knows thetransaction 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/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
