> -----Original Message-----
> From: Adam Roach [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2008 12:12 PM
> >
> > That's not totally accurate, methinks.  It requires support for the
> dialog-event package on the UAC,
>
> We've established that -- "28% and likely to increase" is a good
> starting point.

Riiiight.  First, it was 28% at an earlier sipit and 16% at the most recent one 
- sounds like a massive decrease to me. ;)  But more seriously, in my 
experience the time between implementation and testing at sipit, and actual 
deployment in the field, is often measured in YEARS for anything but trivial 
features.  Obviously that's just my particular view, but my general point is 
it's a change on the UAC from TODAY, no matter how we spin it.


> > and requires the UAC to allow some random far-end UA outside its domain
> that it does not know about to subscribe to it.
> This isn't some random far-end UA that the calling party has no reason
> to trust -- the dialog event package explicitly talks about
> 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. :)


> > [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.

-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

Reply via email to