From: "DRAGE, Keith \(Keith\)" <[EMAIL PROTECTED]> How does the UAC cancelling the request help.
Surely all we end up with is the CANCEL request desperatly trying to catch up with all the propagated INVITE requests. I see nothing in the transaction model that helps it catch up, and I suspect (based on experience in non-SIP systems) that it never will in most people's implementations. It will always be pretty much the same number of steps behind. By design, the total number of transactions active at any moment will be limited to Max-Forwards times Max-Breadth. In the canonical example, that's 20 times 64 equals 1280. There are 64 active "fingers" that are depth-first-searching the tree of possible forks, and each finger is limited to being 20 forwards long. Of course, there's a lot of activity at the ends of the fingers, but each finger's actions are serial. In the worse case, all 1280 transactions are happening on the same SIP agent, so its work-queue can have 1280 items in it at any moment. But at the same time, the work-queue can have no more than 1280 items in it. Injecting a CANCEL at the top of the tree, the cancel may have to wait for 1280 actions to be processed before it gets processed. The CANCEL stops the (unique) depth = 1 transaction from generating any more requests, and also generates CANCELs that go to all of the depth = 2 transactions. Each of those second-generation CANCELs may have to wait for 1280 work-items ahead of it before they are processed. (Actually, 19 times 64 equals 1216 work-items.) But that won't take horribly long, and you can work out the time-bound by which time all the second-generation CANCELs have been processed, terminated the generation of depth = 3 requests, and caused the sending of the third-generation CANCELs. Etc., for depth = 3 to 20. What saves the day is that Max-Breadth prevents any single SIP agent from becoming totally jammed, so that any CANCEL will be processed within a bounded amount of time. And that Max-Forwards prevents the fork fingers from extending beyond the limit at their tips while their roots are being torn down by CANCELs. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
