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

From: Orit Levin <[email-masked]>
Date: Thu, 23 May 2002 11:20:03 -0400

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.)
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.)

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. Of cause, we
need to standardize where we convey this information. This would be a
general approach: not for Conferencing only.
2. If the requirements are for the "User Agent", then the encoding and the
syntax of the conferencing indication MUST be standardized. 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).

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?
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

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 23 May 2002 11:34:49 -0400

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

> 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.

> conference. (The user MAY ignore this information.)
Again, why? I don't get this information when my wife picks up an extension 
line.

> 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.

> 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
> 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.

> 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. :-)

>>>>> 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,
>>>> 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,

-----------------------------------------------------------
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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2002 12:04:16 -0400

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