Subject: RE: [Sipping] Re: WG: draft-poetzl-sipping-call-completion-01

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 30 Aug 2006 14:24:33 -0400

Adam, Tessa, Joachim,

If the queue were positioned as an independent presentity with multiple
watchers that could include both the calling and called parties; 

that due to its association with an E.164 number allows an SP to
provision it;

that allows the called party to SUBSCRIBE as watcher of the status and
accept only calls from the head of queue while it contains active
callers;

that allows the called party to call the active party at the head of the
queue in CCBS or CCNA situations; (simulation)
 **OR**
that allows the calling parties to SUBSCRIBE as watchers, get NOTIFIES
of their status (head of queue is ephemeral - call now or get dropped),
which triggers them to call; (emulation)

that allows callers to PUBLISH queue status (based on XML package
definition) of:
- active:  allows moving up in queue as head identities are removed, 
- suspended:  allows moving up, but not to head of queue,
- removed:  drops from queue altogether;

(Note the additional rejection reasons could be added to the responses
to PUBLISH.)

that does not allow callers to see who else is in the queue (filtered
NOTIFYs);

that allows the CCBS/CCNA PUBLISH requests to be charged on a per use or
subscription basis;

would that address the modeling concern?

Mike

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Wednesday, August 30, 2006 12:18 PM
> To: Silvia Tessa
> Cc: [email-masked]; SIPPING WG
> Subject: Re: [Sipping] Re: WG: draft-poetzl-sipping-call-completion-01
> 
> Silvia Tessa wrote:
> > Hi all,
> > comments inline.
> >
> > Adam Roach wrote:
> >
> > > I have a handful of comments on the current call 
> completion document 
> > > as it relates to RFC 3265.
> > >
> > >   1. I have some heartburn with the behavior described 
> for the event
> > >      package. The SUBSCRIBE/NOTIFY mechanism is intended 
> to *subscribe*
> > >      to remote state, not *manipulate* it. Parameters like
> > >      "queue-operation" are obviously intended to act as an RPC
> > >      mechanism. It is important that SUBSCRIBE requests remain
> > >      idempotent: sending the same SUBSCRIBE request over and over
> > >      should not cause users to be inserted into a queue 
> multiple times.
> > >      As this document defines the mechanism, this is not the case.
> >
> > It is not clear to me which exact scenarios you have in 
> mind: if the 
> > SUBSCRIBE is not sent on an existing  dialog, it does create a new 
> > subscription, no matter which event package we are talking about:
> > sending the same SUBSCRIBE request  over and over on 
> different dialogs 
> > tipically cause users to be notified of status changes 
> multiple times.
> >
> > If the SUBSCRIBE is sent on the same dialog but with different 
> > queue-operation it can simply change the internal 
> subscription status 
> > (suspended or not): sending over and over the same SUBSCRIBE with a 
> > different Expires Header value, causes the SUBSCRIPTION to 
> > continuously change its duration attribute, sending it with a 
> > different queue-operation (suspend/resume) makes it change its 
> > suspension attribute.
> >
> > If the SUBSCRIBE is sent on the same dialog with the same 
> > queue-operation value, no action is taken.
> 
> It's good that you view these operations as idempotent (the 
> document does not make this clear, and the implication is 
> otherwise) -- however, the issue remains that you are 
> creating and manipulating NON-SUBSCRIPTION state with 
> SUBSCRIBE messages. That's not what SUBSCRIBE is for, and 
> you'll almost certainly run into implementation issues going 
> down this path.
> 
> > >
> > >   2. I find the choice of event header field parameters to return
> > >      resource state to be both baroque and in violation of the
> > >      description of NOTIFY bodies in section 4.4.5 of RFC 
> 3265. For
> > >      example, "queue-state" and "denial-reason" 
> communicate resource
> > >      state, and should be sent in the NOTIFY body (not 
> Event header
> > >      field parameters).
> >
> > It can be baroque, but not in violation, as far as I understand....
> 
>     "The NOTIFY body is used to report state on the resource being
>     monitored."
> 
> 
> I'm not sure how this could be any clearer.
> 
> > You are raising a good issue! Actually, this is not solvable by 
> > solving the forking or not-forking matter, but introducing a 
> > centralised entity, holding all the queue information. 
> That's actually 
> > the idea behind the draft: the call completion event server is a 
> > centralized entity monitoring (via dialog event package or just 
> > logging users communication, that's out of scope) the user 
> call status.
> 
> If such is the case, then the document has far more problems 
> than I originally determined. Are you expecting this 
> centralized entity to add "Allow-Events" header fields to the 
> 486 and 1xx responses generated by terminals? Section 3.3.7 
> is abundantly clear on this topic:
> 
>     "Note that "Allow-Events" headers MUST NOT be inserted by 
> proxies."
> 
>       
> 
> The signaling flows in section 7 of the current draft 
> certainly imply that the entity processing the INVITE 
> requests is the same entity processing the SUBSCRIBE requests 
> -- and this would be the terminal, not some server in the 
> middle of the network. If the intention is that the mechanism 
> is handled on some centralized server, then the document 
> needs some *serious* rework to make that fact clear.
> 
> Until the model is clearer, there's no use discussing the 
> remainder of my comments.
> 
> /a
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 31 Aug 2006 12:50:07 +0200

Hi Mike,

your idea seems to be good, the only thing we have to keep in mind is the interworking to the PSTN, where the notification 'instance' (on a MGC) has more the behaviour of a normal UA. 
So a solution for call completion should work if the notifier is a UA as well it should work with a centralized server. That we have to check.

Best regards, Martin

-----Ursprüngliche Nachricht-----
Von: Michael Hammer (mhammer) [mailto:[email-masked]] 
Gesendet: Mittwoch, 30. August 2006 20:25
An: Adam Roach; Silvia Tessa
Cc: [email-masked]; SIPPING WG
Betreff: RE: [Sipping] Re: WG: draft-poetzl-sipping-call-completion-01

Adam, Tessa, Joachim,

Mike