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