Subject: AW: AW: [BLISS] Call completion

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 1 Nov 2007 19:29:41 +0100

Yes, that would be the prioritization of a CC call, and the monitor would have to have the possibility to reject the call.

Since the last revision the prioritization is not longer part of the Poetzl draft, the proposal was to handle the prioritization of a call independent from the completion. People than can decide if CC call prioritization is part of their CC service.

On the other hand, if rejection of not prioritized CC calls is part of a CC service, as you said this has influences on the capabilities of the monitor, and this has to be descibed in the draft.

Or is there a way to handle the prioritization independent from the monitor capabilities respectively the monitor involvement in the CC call?

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Dienstag, 30. Oktober 2007 19:17
> An: Hülsemann, Martin
> Cc: [email-masked]
> Betreff: Re: AW: [BLISS] Call completion
> 
> 
> 
> 
> Huelsemann, Martin wrote:
> >  
> >>     Question: The CC must be marked in some way as a CC call 
> >> in order for
> >>     the callee's monitor to know that the CC activation is 
> being acted
> >>     upon by the caller's agent.  And the marking must include the
> >>     original Call-Id to allow correlation with the original call.
> >>     Possibilities for a marking are a special URI-parameter on the
> >>     request URI or a special header.
> >>
> >> Its not entirely clear to me that the monitor *needs* to know 
> >> that this 
> >> call is a completion for some missed call. What bad thing 
> >> would happen 
> >> if it didn't know that?
> > If there are still entries in the queue the callee's 
> monitor shouldn't accept calls without this CC indication. 
> Otherwise there could be the situation that immediately after 
> the callee has become available there are other calls which 
> are answered then, and the user who requested CC will never 
> have a chance to complete the call.
> 
> You are making an assumption about the "monitor" that Dale 
> didn't make:
> 
> You are assuming that calls flow through it before reaching 
> the callee, 
> and that the monitor can thus prevent those from being accepted.
> 
> If that is a key part of the mechanism then it needs to be specified 
> somewhere.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bliss
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss