Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

[Hadriel Kaplan <HKaplan at acmepacket.com>]

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