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

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 1 Sep 2006 14:19:21 +0200

Hello Dale

Thanks a lot for taking a look at the document and providing comments.

Answers are inline:

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.

--> will be described in the new revision

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.

--> will be appropriately reflected in the new revision

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.

-->The busy state in the CCBS service model is more bounded to the terminal device, and not to the dialog. The problem with the AORs was pointed in the previous comments and the proposal was to use GRUU functionality to identify the device and overcome the problems that are connected to the use of AOR.

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.

--> This is the intention to indicate that CCBS is generally possible, also outside of this call.

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.

--> see the GRUU comment above

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.

--> The same comment was given by Adam Roach. What we are looking is an operation that would provide a mixture of the PUBLISH RPC functionality and the implicit SUBSCRIBE function of the REFER method. In this case an RPC (for example addition to the queue) could be performed and the information about the resulting events (queue states) could be receive in the NOTIFIYs.

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.

--> the operation that we are looking for would definitely benefit from this soft states.

The question is what SIP operation could fit here? 

Denis Alexeitsev

_______________________________________________
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