On 11/20/08 11:38 AM, Hadriel Kaplan wrote:
authentication based on knowledge of the dialog identifiers.Ahh, ok. My mistake. So you'll only need operators to allow Subscribe's for such a package to get in from other domains. :)
Yes. One would hope this is something they're compelled to do anyway, as it allows the simpler version of the call completion service.
[And it requires the path between the UAC and UAS to not contain b2bua'sthat change call-id or tag, of course]Unless they also accommodate DERIVE. That's a known property of B2BUAs:you tend to need to update them whenever you want to do something new. Presumably, if the market asks for it, B2BUAs will address the issue.As I've tried to explain, it is not technically possible for B2BUA's to "address the issue" to stop changing call-id's, because it's their customers who want them to change it. You might as well ask them to stop being b2bua's. DERIVE will not make that happen.
I'm not saying "stop changing Call-IDs." It's true that that's what I *want* to happen, but it's not the only way this can be made to work.
I'm saying "if you must, for business reasons, change Call-IDs going into and out of a network, make sure you perform the same mapping into and out of the network when you see the dialog event package." Again, this is something with value for the carrier itself, as it allows new services (such as call completion).
/a _______________________________________________ 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