Subject: [Sipping] Re: Comments on draft-ietf-sipping-cc-conferencing-01

From: Alan Johnston <[email-masked]>
Date: Wed, 16 Jul 2003 13:51:22 -0500

Eric,

Thanks for your comments.  See mine below.

Thanks,
Alan Johnston
MCI

At 11:09 AM 7/14/2003 -0400, Eric Burger wrote:
>[on XCON list, even though a SIPPING draft]

[Moved to SIPPING where the discussion belongs]

>Section 3.4:
>I'm hesitant to say a conference aware UA SHOULD subscribe to conference 
>state.  That's really an application decision.  One might suggest it, 
>e.g., "the UA can subscribe to the conference state."  A similar sentiment 
>goes for the following paragraph.  Why would or why would not a UA want to 
>display information gleaned from SIP?  In any event, it is not a protocol 
>issue, so it doesn't really merit a MAY (or SHOULD).

The choice of strength of the statement stems from the fact that 
subscription to the conference package is a necessary first step if any 
conference policy, media policy, or floor control is to take place.  (The 
NOTIFY contains the conference policy, media policy, and floor control 
URIs)  Perhaps dropping the normative but explaining the importance of this 
step unless no further conferencing interaction/services are going to be 
used by the participant.

>Section 4.2:
>How else, in the SIP world, would a focus bring a user agent into the 
>conference other than by INVITE?  Maybe the SHOULD here is the inclusion 
>of the ;isfocus parameter.  That said, why is it not MUST?

Yes, the SHOULD relates to the isfocus parameter.  It is not a MUST because 
a focus may wish to conceal the fact that it is a focus.

>Section 4.3:
>Having the scars of Early Media from netann, I would suggest not going 
>down the path of IVR interactions before session establishment 
>completes.  There are a lot of ugly corner cases to think of and work 
>around.  I would drop the paragraph.

OK.  I'm not a huge fan either.

>Section 4.6:
>Same as 4.2, but with REFER.  Is the SHOULD that REFER is preferred to a 
>new INVITE or that ;isfocus SHOULD be in the contact.  If the former, this 
>is the SIPPING work group, the only thing we can spec is SIP stuff, and 
>thus this is redundant.  If it is the latter, then is there a reason 
>including ;isfocus is not mandatory?

Again, it does relate to the isfocus tag and the same argument as above 
applies.

We'll work on rewording some of these requirements to make them more clear.

>_______________________________________________
>XCON mailing list
>[email-masked]
>http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
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: Michael Hammer <[email-masked]>
Date: Thu, 17 Jul 2003 11:36:09 -0400

At 01:51 PM 7/16/2003 -0500, Alan Johnston wrote:
>Yes, the SHOULD relates to the isfocus parameter.  It is not a MUST 
>because a focus may wish to conceal the fact that it is a focus.

Some places have requirements that a participant in a call be notified if 
there are others eavesdropping on the call.  This strikes me as a form of 
wire-tapping.  Could you elaborate on why a focus would want to conceal 
that fact?

Mike

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 23 Jul 2003 16:21:19 +0200

Concealing the fact that you are in a conference does not meet the 
IETF-definition of wiretapping, as one of the parties on the 
communication is aware of what is going on.    Please, see my 
discussion on this in the Join draft (snippet provided below).

thanks,
-rohan

This primitive can be used to create services which are used for 
monitoring purposes, however these services do not meet the definition 
of a wiretap according to RFC2804[14]. The definition from RFC2804 is 
included here:

    Wiretapping is what occurs when information passed across the
    Internet from one party to one or more other parties is delivered
    to a third party:

    1. Without the sending party knowing about the third party

    2. Without any of the recipient parties knowing about the delivery
       to the third party

    3. When the normal expectation of the sender is that the
       transmitted information will only be seen by the recipient
       parties or parties obliged to keep the information in
       confidence

    4. When the third party acts deliberately to target the
       transmission of the first party, either because he is of
       interest, or because the second party's reception is of
       interest.

Specifically, item 2 of this definition does not apply to this 
extension, as one party is always aware of a Join request and can even 
decline such requests. In addition, in many applications of this 
primitive, some or all of the other items may not apply. For example, 
in many call centers which handle financial transactions, all 
conversations are recorded with the full knowledge and expectation of 
all parties involved.

On Thursday, July 17, 2003, at 05:36 PM, Michael Hammer wrote:

> conference other than by INVITE?  Maybe the SHOULD here is the 
> inclusion of the ;isfocus parameter.  That said, why is it not MUST?
>
>
> Some places have requirements that a participant in a call be notified 
> if there are others eavesdropping on the call.  This strikes me as a 
> form of wire-tapping.  Could you elaborate on why a focus would want 
> to conceal that fact?
>
> Mike