I appreciate wanting to solve all possible scenarios (who doesn't! :), but I am fairly confident there is no possible solution to solve all possible scenarios. I am also fairly certain we can't even anticipate or document all possible scenarios.
ISTM the only way to solve all possible scenarios is to have all B2BUA's stop changing call-id's and tags - in fact, to not have B2BUA's at all. Because that is the assumption all RFC uses of callid+tags have made so far.
At this most recent IETF there appeared to be consensus that the real world has B2BUA's... LOTS of B2BUA's, of various flavors/roles/behaviors, from many vendors. And there appeared to be consensus that we should try to make things work with them, as much as pragmatically possible.
-----Original Message-----
Having something incomplete may be worse than nothing. We may have a
scenario where the partial solution gets implemented and then it will be
impossible to implement a final solution as you are required to be
backward compatible to the partial solution.
I can't argue that some future mechanism can't be better than the session-id mechanism, obviously. But I would point out the session-id mechanism would not prevent future mechanisms, any more than current call-id+tag usage prevents the session-id mechanism. It would be a "if session-id match fails, then try this new thing if you understand it", or it could even be a "try this new thing first, and only if that fails or you don't understand it then try this session-id thing". Every extension to SIP can have those properties as far as I know. It just may need a parameter or new header to accomplish it.
But I also don't want to spend 4 years trying to come up with and standardize a perfect solution, and have the problem last for those 4 years plus whatever time it takes to actually deploy the new solution. I'd rather have running code in weeks or months, and deployment as soon as possible - even if it means only some of the scenarios are covered but not all scenarios. (and that's not a comment against your comments - I'm just noting that's how long things take when they're anything more than really simple)
-hadriel
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip