I think it might be worth some effort to attempt an agreement by which
B2BUAs don't have to change callids. For instance, agree on some form of
callid that b2bua's can recognize as "safe" - not including domain names
that might leak some "proprietary" info about the source network.
Thanks,
Paul
Hadriel Kaplan wrote:
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
_______________________________________________
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
