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

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 6 Apr 2007 11:22:23 +0200

Section 2.3
- Among the advantages of the peer-to-peer approach (ie: REFER msg)
over the 3pcc approach (ie: RFC3725), I would somehow underline that
the peer-to-peer approach allows the creation of a single SIP dialog
directly between the peers. On the contrary, with the 3pcc approach,
there are 2 SIP dialogs connected together by a SIP intermediary, the
controller. This intermediary thus affects, and may even limit, the
communication between the 2 peers. For example, if the controller does
not support a given SIP extension (eg: UPDATE message) whereas the 2
peers support it, the peers won't be able to use this SIP extension.
Similarly, if the controller supports a given SIP extension and only
one of the 2 peers support it, the SIP extension will be used in one
dialog but not in the other dialog, which means that the controller
will need to implement a complex behavior to mitigate this. (For this
later case, the use of OPTIONS before 3pcc could help, but this is
something I haven't seen being implemented.)

Section 2.7.1
- Elaborate on "calendar reminder": is it "just" a type of network
announcement service?

Section 2.7.2
- Replace
  advantage of the fact that the standard SIP URI has a user part.
  Most services may be thought of as user automatons that participate
  in SIP sessions.  It naturally follows that the user address, or the
  left-hand-side of the URI, should be utilized as a service indicator.
with:
  advantage of the fact that the standard the left-hand-side of the
  SIP URI is a user part. Most services may be thought of as user
  automatons that participate in SIP sessions.  It naturally follows
  that the user part should be utilized as a service indicator.

Section 2.7.2
- Replace
 "represents people. However, the URI can also represent services,"
with
 "represents a person. However, the URI can also represent a service,"

Section 3.1
- Rename "3.1. Early Dialog Actions" into "3.1. Remote Call Control
Actions on Early Dialog"

Section 3.2
- Rename "3.2. Single Dialog Actions" into "3.2. Remote Call Control
Actions on Single Dialog"

Section 3.2.
- What does CRM stand for?

Section 3.2.2.
- Replace "be conceptually be" with "conceptually be"

Section 3.2.2.
- It is currently written that "There is no way to distinguish between
the desire to go on or off hold." Reading sip-remote-cc-05, I
understand that placing on-hold or off-old is possible, but that it is
not possible to do it at a "per" media level.

Section 3.3.1
- In case user-A is a "secretary", and user-C is a "boss", it may be
that the SIP URI of user-C must not be revealed to any user-B. This is
something inherent to 3pcc. It should therefore be mentionned that
"the 3pcc helps if privacy is needed for C".

Section 3.3.3
- It's not easy to read the following text:
  "A
  could send the following requests: REFER B Refer-To: conference-URI
  INVITE conference-URI BYE B To add a party to a conference: REFER C
  Refer-To: conference-URI or REFER conference-URI Refer-To: C Using
  the 3pcc approach to transition to centrally mixed, the controller
  would send: INVITE mixer leg 1 (w/SDP of A) INVITE mixer leg 2 (w/SDP
  of B) INVITE C (late SDP) reINVITE A (w/SDP of mixer leg 1) reINVITE
  B (w/SDP of mixer leg 2) INVITE mixer leg3 (w/SDP of C) To add a
  party to a SIP conference: INVITE C (late SDP) INVITE conference-URI
  (w/SDP of C) Features enabled: - standard conference feature - call
  recording - answering-machine style screening (screening)"
Maybe rewrite it with
  "A could send the following requests:
  ° REFER B Refer-To: conference-URI
  ° INVITE conference-URI
  ° BYE B
 To add a party to a conference:
  ° REFER C Refer-To: conference-URI
  ° or REFER conference-URI Refer-To: C
  Using the 3pcc approach to transition to centrally mixed, the
controller would send:
  ° INVITE mixer leg 1 (w/SDP of A)
  ° INVITE mixer leg 2 (w/SDP of B)
  ° INVITE C (late SDP)
  ° reINVITE A (w/SDP of mixer leg 1)
  ° reINVITE B (w/SDP of mixer leg 2)
  °  INVITE mixer leg3 (w/SDP of C)
  To add a party to a SIP conference:
  ° INVITE C (late SDP)
  ° INVITE conference-URI (w/SDP of C)
Features enabled: - standard conference feature - call recording -
answering-machine style screening (screening)"

Section 3.3.4
- Replace "5.3) For" by "5.3).  For"
- There is no Section 5.3

Section 6
- I suggest to list example features by alphabetical order in section
6, 6.1, 6.1.1. ... otherwise it's difficulte to look for a given
feature among the different sections.

Section 6.1
- Update references for [service-examples], [conf-models],
[cc-transfer], [cc-framework], [sip-answer-mode] with [6], .... [28]

Section 6.1.4
- Replace "dialog state" with "dialog event package" ? If yes, add a
reference to [11], RFC 4235

Section 6.1.13
- Replace "Voice Portal Takes" with "Voice Portal takes"

_______________________________________________
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: "Henry Sinnreich" <[email-masked]>
Date: Sat, 7 Apr 2007 14:58:42 -0700

Xavier,

I believe you are right about 3pcc 'as is' not being compatible with P2P SIP.

Alan, what do you think?

Henry

-----Original Message-----
From: Xavier Marjou [mailto:[email-masked]] 
Sent: Friday, April 06, 2007 4:22 AM
To: [email-masked]; [email-masked]
Subject: [Sipping] Comments on draft-ietf-sipping-cc-framework-07

Section 2.3

Section 2.7.1

Section 2.7.2
- Replace

Section 2.7.2
- Replace

Section 3.1

Section 3.2

Section 3.2.

Section 3.2.2.

Section 3.2.2.

Section 3.3.1

Section 3.3.3

Section 3.3.4

Section 6

Section 6.1

Section 6.1.4

Section 6.1.13