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

From: Adam Roach <[email-masked]>
Date: Tue, 29 Aug 2006 09:59:03 -0500

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.

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

   3. Disallowing forked requests for the event package seems an
      eccentric choice to me. Since there are necessarily no state
      agents in the network for this event package, it is EXTREMELY
      likely that subscribe requests will end up getting forked to
      multiple terminals. The prospect that CCBS/CCNR can apply to only
      one terminal seems really counterintuitive. I can't imagine how
      this will ever seem like the right behavior to users. For example,
      if I have two phones (one at my office in Dallas, where I spend
      most of my time, and one at my office in Denver, where I spend
      three weeks a year), and you call my number, but give up and
      activate the CCNR service: does it make sense that you will
      establish a CCNR relationship with my the phone in Colorado (which
      won't be used for another month or so), and REJECT the
      relationship with my phone in Dallas (which I'll probably use
      within an hour or two)?

I also have some minor issues with the "P-Service-Indication" header. In 
this case, an RFC 3087-based solution will suit your purposes just fine 
(that is, the called party generates a GRUU with a GRID that it 
recognizes as a CCBS/CCNR service request, and provides it to the 
caller. When the caller uses this GRUU, the called party will recognize 
the GRID as being related to the CCBS/CCNR service, and know that the 
request is a CCBS/CCNR request.) You'll need to use a GRUU anyway, since 
the service as you've defined it is very specific to the called device, 
not to the user's AOR in general.

I'll outline a solution that I think is much closer to the intention of 
RFC 3265 and other SIP documents:

    * Called parties, when returning any provisional response (180, 181,
      182, 183, any others), or any other indication that the called
      party is currently unavailable (486, 480, 600) can indicate
      support for the CCBS extension using the "Supported" header field
      (NOT the "Allow-Events" header field). They also include a new
      header field which contains a GRUU that routes back to the device;
      this GRUU contains a GRID that the device recognizes as being
      related to the CCBS/CCNR service.

    * Called parties can react to such provisional or busy responses by
      sending a message that is an explicit request to insert themselves
      in the queue. These requests are sent to the service request GRUU.
      I'm not yet certain specifically what this looks like (that is,
      what method to use), but the request to insert the caller into the
      queue (and to pause and unpause the position in the queue, as is
      described in section 5 of the current call completion document)
      needs to be EXPLICIT and consistent with the meaning of the method
      in which it is carried -- not IMPLICIT as a side effect of
      requesting a subscription. This likely means that you'll either
      want a new method or you'll want to use INVITE to set up a queue
      management session.

    * Given the above, there are several ways to complete the service.
      One such option would be:

      The caller now subscribes to the state of the queue, and receives
      periodic notifications about the position and disposition of his
      request in the queue. The NOTIFYs would look something like this:

      NOTIFY sip:[email-masked];grid=58sjgf SIP/2.0
      From: <sip:[email-masked]>;tag=4598d-fg8
      To: <sip:[email-masked];
          opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
          grid=99a;gruu>;tag=f85lkfi-28s
      Call-ID: 30awvs09xmvf90325ax0932kgz0gnj20
      CSeq: 58721 NOTIFY
      Via: SIP/2.0/UDP proxy.estacado.net:5060;branch=z9hg4bkg09832gnjz095
      Via: SIP/2.0/UDP 172.17.16.52:5060;branch=z9hg4bks582fd0gk109d
      Contact: <sip:[email-masked];
               opaque=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;
               grid=99a;gruu>
      Event: cc-queuestate
      Content-Type: application/queue-state+xml

      <queue-state>
        <requests>
          <request id="k83l56s9" state="paused" position="3" />
          <request id="g83lgadk" state="queued" position="2" />
          <request id="2085kgsf" state="queued" position="1" />
        </requests>
      </queue-state>

      (the exact syntax and contents of this message aren't terribly
      important for the purpose of understanding what I'm proposing, and
      probably need more than a little tweaking). When the user's
      request becomes active, the body of the notify will indicate
      "ready" instead of "queued" for the request. At this point, the
      caller can then use the GRUU that it received before to initiate
      the call. (The called party can reject the call if the GRID in the
      INVITE doesn't match the GRID for the call marked as "ready" in
      the queue). 

Finally, I would suggest that you consider the ability to deploy a 
system in which some non-terminal server handles queue management 
instead of the endpoints -- doing so would allow the "Dallas/Denver" 
example I provide above to work in a more sane fashion. The non-terminal 
server could either track dialog state by being call stateful, or it 
could subscribe to the dialog state for each of the user's registered 
devices.

/a

Huelsemann, Martin wrote:
>
> Hi all,
>
> a revised version of the Call Completion draft is available at
>
> _http://www.ietf.org/internet-drafts/draft-poetzl-sipping-call-completion-01.txt_. 
>
>
> The intention of the draft is to propose solutions for the 
> requirements for the ETSI TISPAN NGN services Completion of Call to 
> Busy Subscribers and Completion of Call on No reply.
>
> The main change to the previous version is, that there is only one 
> call completion event package now, which can be used for CCBS and 
> CCNR. The indication for CCBS is 'Allow-events: call-completion' in a 
> 486 Busy response, 'Allow-events: call-completion' in a 180 Ringing 
> response is the indication for CCNR.
>
> Then I have added some more explanatory text and signalling flows, I 
> hope that makes the requirements and solutions described in this draft 
> clearer now.
>
>
>
> As you renember from the IETF 66 discussion, the main topic of 
> discussion was, is it appropriate to use SUBSCRIBE/NOTIFY, besides 
> subscribing to a call completion event itself, also for managing the 
> call completion queue, for example for suspend and resume procedures.
>
>
>
> Questions and comments are very welcome.
>
>
> Best regards, Martin
>
>
>

_______________________________________________
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: "Silvia Tessa" <[email-masked]>
Date: Wed, 30 Aug 2006 17:05:30 +0200

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

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.

 >      state, and should be sent in the NOTIFY body (not Event header

It can be baroque, but not in violation, as far as I understand....

 >      relationship with my phone in Dallas (which I'll probably use

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. Being 
centralized, forking could be useless.

 >
 > I also have some minor issues with the "P-Service-Indication" header.
 > In this case, an RFC 3087-based solution will suit your purposes just
 > fine (that is, the called party generates a GRUU with a GRID that it
 > caller. When the caller uses this GRUU, the called party will
 > recognize the GRID as being related to the CCBS/CCNR service, and know
 > that the request is a CCBS/CCNR request.) You'll need to use a GRUU
 > anyway, since the service as you've defined it is very specific to the
 > called device, not to the user's AOR in general.

In the above example, the entity generating the GRID is the UAS, but in 
reality, it would be generated by a centralized entity, that not 
necessarily would be involved in the new incoming call. In that scenario 
the univocally generated grid would not be understood.
Therefore, unfortunately, this mechanism is not sufficient.

 >
 > I'll outline a solution that I think is much closer to the intention
 > of RFC 3265 and other SIP documents:
 
let me understand, are you suggesting the use of the support header, in 
order not to use the SUBSCRIBE method afterwords ?
Regarding the new header, you would see it's necessary any time an error 
response (4xx) is generated since the Contact is not allowed, or were 
you thinking about other gaps ?

 >      want a new method or you'll want to use INVITE to set up a queue

Actually, we are not handling implicit or explicit information, but just 
defining an event package with different notification policies.

 >      [snip]
 > example I provide above to work in a more sane fashion. The
 > non-terminal server could either track dialog state by being call
 > stateful, or it could subscribe to the dialog state for each of the
 > user's registered devices.

The  Call-Completion Event Server was meant to be a non-terminal server
handling queues, that could, as an implementation matter, base itself
upon dialog event package to retrieve the dialog information: what you
are asking for, is just the same server that use MYNEWMETHOD instead of
SUBSCRIBE, following the same apporch as REFER did ?

Best Regards
Silvia
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Aug 2006 11:18:14 -0500

Silvia Tessa wrote:
> 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.
>

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.

> 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

---

From: "Alberto Cuda" <[email-masked]>
Date: Thu, 31 Aug 2006 15:47:46 +0200

Adam Roach wrote:
> does not make this clear, and the implication is otherwise) 
Yes, probably some clarification on this should be added.
> -- however, the issue remains that you are creating and manipulating 
 From my perspective, we can split an event server in different subsystems:
+ A database containing all the subscriptions (updated by SUBSCRIBE 
requests);
+ A database containing all the state documents (updated by PUBLISH 
requests);
+ A subsystem that looks up the subscription DB to send NOTIFY requests when
   some change in the remote state happens.
The third subsystem usually follows a straightforward approach: send a 
NOTIFY
request for each subscription, however what is needed here is to notify 
one watcher
at a time, and sometimes watchers even need to suspend their 
subscriptions without
loosing their place in this queue. Now, what is the best way for 
watchers to perform
these operations? Since their are operating on attributes of their 
subscriptions,
the SUBSCRIBE method looks like the most obvious tool to do this, at 
least for us:
do you think that the SUBSCRIBE body would be a better choice for carrying
the "suspended" information?

> I'm not sure how this could be any clearer.
I agree the body is the best place where to put this information.

>> 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 
> 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:
>
In that case the centralized entity would not be a proxy, but a B2BUA.
> 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.
>
Actually we did not make an explicit reference to the possible 
architectural deployments
to keep the approach as general as possible (the event server can be 
either an UA
or a centralized entity, acting as a B2BUA). The latter case can solve 
the forking problem
you mentioned: the B2BUA is involved in each call and keeps the queue so 
it can both
put the Allow-Events header, and monitor the state of the callee's 
terminals.

    Cheers.
       Alberto.

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it