Re: [BLISS] Call-completion issue 1010: The event model

Like Dale has already said there are a lot of privacy issues, and with the potential modifying of the Contact URI by SBC this would be difficult to deploy in practice.

And on the other hand the information we want to provide is the call completion state of the subscriber, which might be different from the queue position (even though it shouldn't be). Anyway the information 'queued' or 'ready for recall' is exactly what we need, so my proposal is to leave it at that and work on Dale's porposal to subscribe to slightly different resources. As some CC implementations are advanced meanwhile we should alos consider some 'backward compatibility' if possible.

Because of the mentioned issue with request URI parameters I am also in favour for a event header parameter based solution. At 3G we also experianced a problem with the m-parameter, due to a TEL URI conversion it isn't conveyed e2e. There we decided to add a Call-Info header to CC requests, which repeats the Request URI incl the m-parameter. If this fits also for our BLISS CC solution we could even define a unique URI parameter.

For the uniqueness: I've also been notified that I have won a 10 000 000 $ price at the National Lottery, so this event can't be very seldom. Therefore it seems we have to spring for some other decimal powers, probably 2^128 values would be okay.

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Freitag, 9. Juli 2010 20:02
> An: WORLEY, Dale R (Dale)
> Cc: bliss@ietf.org
> Betreff: Re: [BLISS] Call-completion issue 1010: The event model
> 
> 
> 
> WORLEY, Dale R (Dale) wrote:
> > ________________________________________
> > From: bliss-bounces@ietf.org [bliss-bounces@ietf.org] On Behalf Of 
> > Scott Lawrence [xmlscott@gmail.com]
> > 
> > Why not send the notification to all subscribers, but 
> include in the 
> > notice an explicit indication of which is active?  Rather than send 
> > 'active', send 'active sip:subscriber@domain' where 
> > 'sip:subscriber@domain' is the contact URI from the head of 
> the queue?
> > _______________________________________________
> > 
> > It certainly simplifies the situation.  In principle there 
> might be privacy problems.  In practice, SBCs modify the 
> Contact URI, so the agent doesn't know what Contact URI the 
> monitor sees.
> 
> Would I then be able to subscribe, monitor the notifications, 
> and send INVITEs to the contacts I see?
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> BLISS mailing list
> BLISS@ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
> 