Subject: [Sipping] Comments on draft-ietf-sipping-cc-framework-07.txt

From: "Mahendran, AC" <[email-masked]>
Date: Mon, 23 Apr 2007 10:45:53 -0700

Hi all,

Here are my comments in draft-ietf-sipping-cc-framework-07.txt.

1) Section 1

Text: "Primitives should be sufficiently robust that when they are
combined they can be used to build lots of services."

Replace with 

"Primitives should be sufficiently robust, so that when they are
combined with each other, they can be used to build lots of services. "

2) Section 1, in the paragraph starting with "Primitives make full use
of URIs....", replace two instances of "URLs" with "URIs".

Note: there are other places in the document which use URL, where URI is
more appropriate. So, please do a global search and replace of URLs with
URIs.

3) Section 2, describes a bunch of key concepts (e.g., conversational
space, signaling models, mixing etc). It is not clear how these "key
concepts" are tied together. It'd be good to have a brief description
indicating what section 2 trying to achieve.

4) Section 2.1, the second diagram has four participants (A, b, C, D),
however, the entry above it only shows [A, B].

So, replace "[A, B]", with "[A, b, C, D]".

5) In section 2.1, text: "(essentially as a set of participants who
believe they are all
   communicating among one another).", remove the brackets "()".

6) Section 2.2, the title "Comparison with Related Definitions" can be
replaced to "Relationship between Conversation space, SIP Dialogs and
SIP Sessions".

>From the current title, it is not clear what is being compared to what!

7) It is not clear what sigaling models section 2.3 is trying to compare
- is it 3pcc vs peer-to-peer? It would be better to compare
"centralized" and "peer-to-peer" signaling models; 3pcc is one possible
way to realize the centralized model.

8) In section 2.4.1.3, it'd be good to mention that media mixing is done
by the end points.

9) In 2.4.2.2, replace two instances of "SIP" with "Signaling".

10) Section 2.7.1, text: "When a caller sends a request, it can
optionally request Caller Preferences [21], by including the
Accept-Contact and Reject-Contact headers that request certain handling
by the proxy in the target domain."

We should include "Request-Disposition" to the list of Caller
Preferences header.

11) In section 2.7.2, text:  "As we have shown, SIP URIs represent an
ideal, flexible mechanism for describing and naming service resources,
be they queues, conferences, voice dialogs, announcements, voicemail
treatments, or phone features."

"be they queues"? This phrase needs to be replaced.

12) Terminology issues: Section 1 uses the term "primitives", whereas
section 3, uses the term "Call control actions". Are these the same? If
yes, we should try to be consistent with the terminology.

13) Section 3.3.1 was confusing the first time I read it. It would be
better to start out saying that the following section describes how call
transfer can be achieved using 3pcc and REFER, and then describe the
operations/procedures.

Also, the sentence "Features enabled by this action..." can be reworded
as: "The following features can be enabled by the "Transfer" action: " 

14) Section 3.3.5 (Insert), we can add a reference to the "Join" RFC.

15) In section 3, in many of the examples, the messages needed to
achieve a particular service are all shown in a single line (for
example, in 3.3.6, to achieve split, the following messages are sent:
REFER C Refer-To: conference-URI (new URI) REFER D Refer-To:
conference-URI (new URI) BYE C BYE D).

For better readability, it is advisable to split these into multiple
lines.

_______________________________________________
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: "Mahendran, AC" <[email-masked]>
Date: Mon, 23 Apr 2007 18:08:30 -0700

One more comment...

Section 2.1 defines a "Conversation space" model.  According to
Webster's dictionary, conversation means "(1) : ORAL exchange of
sentiments, observations, opinions, or ideas". However, the framework is
equally applicable to media sessions which are not audio/speech. So, may
be, the model can be called "Communication Space" instead of
"Conversation space".

Thanks,
-AC

-----Original Message-----
From: Mahendran, AC [mailto:[email-masked]] 
Sent: Monday, April 23, 2007 10:46 AM
To: [email-masked]
Subject: [Sipping] Comments on draft-ietf-sipping-cc-framework-07.txt

Hi all,

1) Section 1

Replace with 

_______________________________________________
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: "Darshan Bildikar" <[email-masked]>
Date: Tue, 24 Apr 2007 12:50:54 +0530

This is what "draft-ietf-sipping-cc-transfer" says about blind transfer

Section 6: Basic transfer

"If the Transferor's agent does not wish to participate in the remainder of
the REFER process and has no intention of assisting with recovery from
transfer failure, it could emit a BYE to the Transferee as soon as the REFER
transaction completes.  This flow is sometimes known as "unattended
transfer" or "blind transfer"

There are two possible scenarios here

1) REFER within dialog: A REFER obviously creates a dialog usage here. A BYE
will therefore ONLY end the INVITE dialog usage and the dialog with the
REFER usage is still active. This would mean that the transferor would still
receive NOTIFY messages with transfer status in essence NOT making this a
"blind transfer". Is the assumption that a NOTIFY needs to be sent with a
subscription termination implicit?

2) REFER outside dialog: Tdialog and gruu would be used here. But the draft
does not talk about the termination of the subscription created by REFER.

I have two suggestions here

1) Would it not be better to recommend the use of "norefersub - RFC 4488" to
implement blind transfer?

2) I can't actually see an example flow for blind/unattended transfer. Would
it be possible to put one in there?

Darshan