One difficulty with Max-Breadth or any similar feature is: When
forking, how do I allocate the incoming Max-Breadth to the outgoing
forks? The obvious solution is to split it equally, but the result is
that the depth of the tree is limited to log(Max-Breadth) forks. One
can easily construct somewhat realistic examples that demand a large
Max-Breadth in order to succeed:
UAC Max-Breadth = 16
/ \
/ \ Max-Breadth = 8
v v
404 proxy
/ \
/ \ Max-Breadth = 4
v v
404 proxy
/ \
/ \ Max-Breadth = 2
v v
proxy 404
/ \
/ \ Max-Breadth = 1
v v
200 404
That generates only 5 forks but requires a Max-Breadth of 16 to
succeed. And under Option 2, even using serial forking has this
problem, though the message load is rather light.
However, if we choose Option 1, so that the Max-Breadth allocated to a
canceled fork can be reclaimed for use on other forks, then a proxy
can always fall back from parallel forking to serial forking. This
allows the forking tree to be explored to Max-Forwards depth, although
extreme cases will explore the deeper leaves serially rather than
parallely, which is a user-visible performance impact (if the UASs do
not respond promptly) but doesn't cause call failure.
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
