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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
