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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 31 Aug 2006 11:08:16 -0400

Martin,

If the queue management presentity is co-located on the PSTN GW with the UA tied to the IWF to the PSTN, does that effectively achieve the same effect?

Also, the reason I used PUBLISH versus SUBSCRIBE to push data to the presentity, is that I was thinking the queue was a composite of the presence of the contributing callers.  So, SUBSCRIBE is used just to watch the resulting composite queue state.  I had thought that SUBs could send filter bodies, but was not sure if they can push data into the presence as well.  Perhaps others could comment on that.

In the past (emulation), Notifies would be sent only when the head of queue is reached, but it might be useful to see ones request progress up the queue, in case one wants to cancel.

Mike

> -----Original Message-----
> From: Huelsemann, Martin [mailto:[email-masked]] 
> Sent: Thursday, August 31, 2006 6:50 AM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]
> Subject: AW: [Sipping] Re: WG: draft-poetzl-sipping-call-completion-01
> 
> 
> 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,
> 
> 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
> 

_______________________________________________
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: [email-masked]
Date: Thu, 31 Aug 2006 18:16:19 -0400

I've only started looking at this document.  It presents some
interesting questions.  Here are a number of observations.

1. Having a definitions section is useful, but the current one needs
to be revised.  The verbs "completed" and "executed" seem to be used
to refer to the same thing, the establishemnt of a call by the
CCBS/CCNR mechanism.  The terms "call-completion user" and
"call-completion target" are not defined.  The term "destination B
queue" is utterly mysterious, and is associated with the "retain
option", which is left undescribed.

2. A caller's UA could perform most of the CCBS/CCNR operations by
subscribing to the dialog event package of the callee.  What is gained
by having the service is the queuing of multiple callers in the case
of high contention.  But this fact is nowhere discussed, despite that
it is the true value-add of this feature.

3. The philosophy of this document is to identify calls by caller and
callee AOR.  This is a mistake and will cause endless trouble at some
point in the future (in various weird circumstances where multiple
calls can pass between the same From AOR and To AOR).  Calls must be
identified by Call-Id/from-tag/to-tag to avoid mabiguity.

4. Supported, Allow-*, and Accept-* headers are intended for use by a
UA to describe its capabilities, not properties of an individual call
or request.  So using Allow-Events to indicate the availability of
CCBS works only if *all calls* to that UA support CCBS.

5. In regard to forking, all features should be carefully vetted for
support of forking, because in *any* INVITE, the request may have been
arbitrarily forked before it got to a proxy which understands the new
feature.  Additionally, the request-URI at the input to the proxy
bears no discernable relationship to the From AOR that the caller
used, and unless the UAS provides a proper contact address, the caller
has no URI which is assured of reaching the UAS again.  All of these
militate against any design which assumes that the caller and callee
are unique and are aware of each other's "real" addresses.

6.  The use of SUBSCRIBE and NOTIFY is very non-standard.  Certainly,
putting status-reporting data in the Event header of a NOTIFY instead
of the body of the message is very strange.  And it's not a wise idea
to have a SUBSCRIBE dialog *affect* anything other than the SUBSCRIBE
dialog status in the UAS.  People assume that subscription information
can be cached, proxied, and redistributed without a problem.  I would
recommend using INFO or PUBLISH to carry what is essentially RPC
operations, and use SUBSCRIBE only for retrieving status information.

7. On the other hand, what is wanted here is to implement "standing in
a queue", and the server that implements the queue wants to know that
the caller's UAs are continuing to pay attention to their position in
the queue.  In that regard, the SUBSCRIBE "soft state" mechanism
implements a lot of what we want -- the UA can maintain its presence
in the queue indefinitely, but it must periodically refresh its
notification to the UAS that it is paying attention.

Dale