Subject: RE: [Sipping] Thoughts on the conf-info package

From: Orit Levin <[email-masked]>
Date: Thu, 23 May 2002 12:08:19 -0400

Answers are below.
BR,
Orit .

 -----Original Message-----
From: 	David R. Oran [mailto:[email-masked]] 
Sent:	Thursday, May 23, 2002 11:35 AM
To:	[email-masked]
Subject:	RE: [Sipping] Thoughts on the conf-info package

--On Thursday, May 23, 2002 11:20 AM -0400 Orit Levin <[email-masked]> 
wrote:

> Hi guys!
> I think that Rohan's "thoughts about conferencing" hit a number of crucial
> missing points.
> Before arguing about the implementation, I will try to summarize the
> implicitly disputed requirements:
>
> 1. When a user is invited to a session, which is a part of a conference,
> information MUST be provided to the user informing him that he is a part
> of the conference. (The user MAY ignore this information.)
Excuse me, but I must be naive. Why is this a MUST? How is this any 
different from multiple people in the same room sharing an instrument? I'm 
not saying the information isnot useful, but I see no reason why it MUST be 
providedin all circumstances.
OL: My phrasing was a mistake. I meant: "standard SIP means for providing
information MUST be defined". Use of these means is a local policy.

> 2. When a point-to-point session is expanded to a conference, information
> MUST be provided to the user informing him that he becomes a part of the
> conference. (The user MAY ignore this information.)
>
Again, why? I don't get this information when my wife picks up an extension 
line.
OL: Same correction as above.

> I see two separate cases for these requirements (which makes them 4
> requirements):
> 1. If the requirements are for the human "user", then the provided
> conferencing information is mostly for "display" and I don't see reason
> for standardizing the syntax and the semantics of the information.
Huh? Then how do I know how to render it?

> Of
> cause, we need to standardize where we convey this information. This
> would be a general approach: not for Conferencing only.
I'm not following this part.
OL: The information itself contains its reason: "You are in a Conference
now" or "Your call has been forwarded".

> 2. If the requirements are for the "User Agent", then the encoding and the
> syntax of the conferencing indication MUST be standardized.
I find your distinction unuseful. The only thing relevant to our work is 
the UA - the user is wetware and is clearly outside the scope of our work. 
:-)

> This is useful
> for "smart" User Agents that are capable of automatic participation in a
> Conference (on behalf of the human user) such as activating additional
> user interface, displaying conferencing information, and much more (for
> example, by automatic activation of UA's Conferencing module). In this
> case the provided information MUST include standard Identification of
> this Conference (BTW another open requirement).
>
Why? Again I'm not arguing tha the informaiton isnot useful, only that the 
system is not broken if it isn't available, and hence "MUST" is way too 
strong a requirement.
OL: Do you mean that if the ID isn't provided, the operations are limited to
the in-band SIP session means? I don't disagree with you if we agree on the
intention. On the other hand, if the ID is provided it MUST be standard.
> I can definitely see place for both sets of requirements. Although, from
> the first sight, it seems that the second case includes the first, they
> can be addressed separately for the sake of really simple (i.e.
> conferencing unaware) User Agents.
>

> Which are we trying to address?
UA's only. Without neruonal interfaces and quantum cognition sensors there 
is no way we can address directly the requirements of human users. :-)
OL: Thanks for the vote :)

> Which would we like to address?
> (I vote for all 4 addressed separately.)
>
> Additional points of view?
> Orit .
>
>  -----Original Message-----
> From: 	Anders Kristensen [mailto:[email-masked]]
> Sent:	Wednesday, May 22, 2002 7:07 PM
> To:	Rohan Mahy
> Cc:	[email-masked]
> Subject:	Re: [Sipping] Thoughts on the conf-info package
>
>
>
> Rohan Mahy wrote:
>>
>> On Wed, 22 May 2002, Anders Kristensen wrote:
>>
>>>>> I think it is simpler. It doesn't require UAs to understand REFER and
>>>>> Call-Info and this particular use of both. It seems a bit odd to me
>>>>> that the exact same information goes into two very different headers,
>>>>> Refer-To and Call-Info, depending on how the receiver gets to join the
>>>>> conference.
>>>>
>>>>
>>>> (aside: to be good SIP citizens I think UAs will need to support REFER
>>>> anyway.)
>>>>
>>>> Specifically, "the exact same information" you are talking about is a
>>>> SIP URI which specifies a request-URI, the SUBSCRIBE method, and a
>>>> specific event package.  The semantics are clear regardless how you
>>>> discovered this URI.  This URI could have been embedded in a web page
>>>> and the semantics are still the same.  It should be apparent to anyone
>>>> that you can put a URI in a Refer-To header, a Call-Info header, a
>>>> Contact
> header,
>>>> the Request-URI, etc.  I understand that it takes a little getting used
>>>> to and might seem odd at first, but this is all very natural SIP
> behavior.
>>>
>>> So you're basically saying it doesn't matter which header this URI is
>>> carried in. You can put SIP URIs many different places, yes, but it
>>> usually means something different. Two different headers being used to
>>> the same effect is BAD.
>>
>>
>> You are confusing the sematics of the mechanism you use to get some
>> information, with the semantics of the information itself.  By analogy,
>> you can send me the same content by email or via an instant message.  The
>> semantics of the information is the same, but the semantics of the
>> two mechanisms are very different.
>
> I absolutely disagree. Well-defined SIP headers should imply semantics.
> They're not for general purpose transport of random information which
> you feel is somehow self identifying in terms of meaning.
>
> I'll go a step further and suggest that any header that lends itself to
> that sort of hijacking may be too vaguely defined.
>
> Anders
>
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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

-----------------------------------------------------------
David R. Oran                   Phone/Fax: +1 978 264 2048
Cisco Systems                   VoIP: +1 408 571 4576
7 Ladyslipper Lane              Email: [email-masked]
Acton, MA 01720

_______________________________________________
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

_______________________________________________
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: Orit Levin <[email-masked]>
Date: Thu, 23 May 2002 12:33:34 -0400

Requirement:
Means for discovering mixing capabilities of other parties in an active SIP
session SHOULD/MAY be defined.
My point of view:
In practice, not very useful for automatic UA functions, but relatively easy
to add to the protocol.
More related to UA capabilities and Call information than to a Conference
information.
Additional opinions?
Orit .

 -----Original Message-----
From: 	Paul Kyzivat [mailto:[email-masked]] 
Sent:	Thursday, May 23, 2002 12:04 PM
To:	Orit Levin
Cc:	'Anders Kristensen'; Rohan Mahy; [email-masked]
Subject:	Re: [Sipping] Thoughts on the conf-info package

I agree with Dave Oran's comments. Even so, I think the direction Orit is
heading by enunciating requirements is useful.

One way this information is valuable to a UA is when there is a need to
conference in another party. There are many ways to do that, and deciding
which one is most
appropriate is impossible without knowledge of the topology of the existing
call/conference. 

If I want to add another party to the call, and I don't have local mixing
capabilities, and I know nothing of the other parties except their
addresses, then I have a hard
time. I can try various flows that may get one of the other parties to mix
the conference, but I won't know which will work without trying, and trying
will probably give
bad user experience. Or I can seek out an external conference bridge, and
use it to establish a new conference.

But if I knew there were one or more conference bridges already in the call
I would probably try them first, even if I have the capability to mix
locally. It may also be
useful to know about other parties in the call that have mixing capability.

This is a bit more information than is available with the conference
package, even with Rohan's proposed goodies.

	Paul

> information MUST be provided to the user informing him that he is a part
of
> the conference. (The user MAY ignore this information.)
for
> standardizing the syntax and the semantics of the information. Of cause,
we
> need to standardize where we convey this information. This would be a
> general approach: not for Conferencing only.
> syntax of the conferencing indication MUST be standardized. This is useful
user
> interface, displaying conferencing information, and much more (for
example,
> by automatic activation of UA's Conferencing module). In this case the
> provided information MUST include standard Identification of this
Conference
> (BTW another open requirement).
> 
the
> first sight, it seems that the second case includes the first, they can be
> addressed separately for the sake of really simple (i.e. conferencing
> unaware) User Agents.
> 
that
> >>>>the exact same information goes into two very different headers,
and
> >>>the semantics are still the same.  It should be apparent to anyone that
> >>>you can put a URI in a Refer-To header, a Call-Info header, a Contact
> header,

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 23 May 2002 14:46:33 -0500

I'm catching up with the tread here, so my apologies if this has already
been discussed. An implicit Subscription won't work if the participant is
interested in knowing about a sub-set of the conference state. I don't yet
know what the mechanism for this would be (may be multiple Event packages),
but the requirement here is to allow a new participant to be notified on a
subset of the Conference state space.  

> Sent: Wednesday, May 22, 2002 1:00 PM
> To: Rohan Mahy
> Cc: [email-masked]
> > The rule for using these two mechanisms is simple.  If I 
> know that I am
> > inviting someone to a conference and I want to reveal that 
> information, I
> > include a Call-Info header which references a subscription to that
> > information.  If a dialog suddenly becomes involved in a 
> conference and I
> > want to reveal that information, I REFER my peer to 
> SUBSCRIBE to that
> > information.
> 
> Isn't it the case that if a UA is knowledgable about these conference 
> notifications and becomes involved in a conference, it *will* want to 
> receive notifications of membership changes etc. I'm wondering if it 
> would be appropriate for the notifier to consider presence of some 
> "conf-info" Supported token sufficient evidence for it to create an 
> implicit subscription for the sender. Seems somewhat simpler.
> 
> Creation of the implicit subscription could be done even without a 
> Supported tag. In worst case, an extra NOTIFY gets sent (and 
> presumably 
> rejected) per (direct) participant. Seems like a good 
> tradeoff for the 
> simplicity of the scheme.
> 
> Anders
> 
>

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 23 May 2002 14:57:18 -0500

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2002 8:59 PM
> To: [email-masked]
> Subject: [Sipping] Thoughts on the conf-info package
> 
> 
> 
>
> 
> How does A know to subscribe to this package?  The dialog 
> between A and B
> started out as an ordinary 2-party call.  It would be 
> patently ridiculous
> to subscribe to the conference info package for every two way 
> call, so B
> should provide some clue to A that more information is 
> available.  A short
> flow proposing this mechanism is below, where B REFERs A to 
> SUBSCRIBE to
> the conference-info package (at B), and B informs C that it 
> is joining a
> conference by including <sip:B;method=SUBSCRIBE?Event=conf-info> in a
> Call-Info header.
> 
My preference in this case would be to use the same REFER mechanism 
to indicate to C that it can SUBSCRIBE to the conf-info package,
after the call gets set-up. Is that a problem?