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

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 23 May 2002 15:05:58 -0500

I agree with this requirement below. Actually, the requirements draft that I
sent out to the 
list a few days back clearly states a slightly more generic one: 

Reqmt 1.2: There MUST be a mechanism to discover the capabilities and 
resources of conferencing entities (e.g., maximum # of ports that a 
conference server can handle) 

Thanks,
Sanjoy

> -----Original Message-----
> From: Orit Levin [mailto:[email-masked]]
> Sent: Thursday, May 23, 2002 11:34 AM
> To: 'Paul Kyzivat'
> Cc: 'Anders Kristensen'; Rohan Mahy; [email-masked]
> Subject: RE: [Sipping] Thoughts on the conf-info package
> 
> 
> 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
> 
> Orit Levin 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.)
> > 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
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2002 16:55:09 -0400

> Sanjoy Sen wrote:
> 
> 
> I agree with this requirement below. Actually, the requirements draft that I sent out to the

Yeah, that would do it - I forgot you had posted it. This may be needed before there is a conference as well. (If I am in a call with you I might need to know if you can
act as a conference mixer.) But as long as the information is available from the conference package, then this can be handled by trying to subscribe to the package.

	Paul