Subject: RE: [Sipping] User with multiple sessions in Conference Package

From: [email-masked]
Date: Thu, 8 Apr 2004 15:11:22 +0300

Why do you need the focus to know that it is the same user (human)? I don't understand the use case. Can you elaborate?

Thanks,
Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Cullen Jennings
> Sent: 08.April.2004 03:30
> To: [email-masked]'
> Cc: Orit Levin; Henning Schulzrinne; Jonathan Rosenberg
> Subject: [Sipping] User with multiple sessions in Conference Package
> 
> 
> 
> In a conference, here are many cases where a single user may 
> have set up
> multiple SIP dialogs with the focus. For example, using one 
> UA instance for
> audio and another UA instance for IM. Or connected on both 
> cell phone and on
> desk phone in office. Right now the conference package seems a little
> underspecified in how to deal with this and we need to clear this up.
> 
> I'm tossing out two proposal below. Comments? Ideas? Can we 
> choose one?
> Could be  close something like this on this list?
> 
> --------------------------------------------------------------
> 
> Proposal 1: 
> 
> The User Element gets a new attribute called contact. This attribute
> contains the contact that the focus used for this dialog. Each dialog
> results in a separate User Element instance and the uri is 
> used to correlate
> the fact that they are the same user. For anonymous calls the 
> system needs
> to generate separate anonymous user uri's so they can be 
> separated from one
> another. 
> 
> For Example,
> 
> <conference-info>
>     <user uri="[email-masked]" contact="[email-masked]">
>         <media-stream> <ssrc> 1234 </ssrc> </media-stream>
>     </user>    
>     <user uri="[email-masked]" contact="[email-masked]">
>         <media-stream> <ssrc> 5678 </ssrc> </media-stream>
>     </user>
> </conference-info>
> 
> ---------------------------------------------------------------
> 
> Proposal 2: 
> 
> The data in the User Element gets split between a User 
> Element and a new
> Session Element that is placed inside the User Element. The 
> media stream
> elements are put inside the Session.
> 
> <conference-info>
>     <user uri="[email-masked]">
>         <session contact="[email-masked]">
>             <media-stream> <ssrc> 1234 </ssrc> </media-stream>
>         </session> 
>         <session contact="[email-masked]">
>             <media-stream> <ssrc> 5678 </ssrc> </media-stream>
>         </session>
>     </user>
> </conference-info>
> 
> 
> _______________________________________________
> 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: Cullen Jennings <[email-masked]>
Date: Mon, 12 Apr 2004 10:43:47 -0700

I'll take a stab at explaining :-)

If someone has a roster displayed on some device - they want to see that one
person, Cullen is in the conference they don't want to sees that their are 4
participants, Cullen-Cell-Phone, Cullen-Speaker-Phone,
Cullen-JABBER_GATEWAY, Cullen-VIDEO-ICHAT_GW. More importantly, they want to
be able to use a user interface to boot Cullen out of the conference not
have to go and somehow magically figure out which devices to boot out since
they are being used by Cullen.

If their are 10 participants that are all Anonymous, you still want to be
able to know their are 10 participants not 1 participant called Anonymous
that seems to have dialed in from 10 devices.

Given that SIP AOR correspond to a user and is not a single device. There
are basically three levels off aggregation happening here.

There are users. Each user can have multiple SIP dialogs that got them into
the conference. Each one of these SIP dialogs can be started and terminated
independently. For example one may be dialed out while another dialed in and
one may be active while others may be ongoing. Inside of each SIP dialog,
there can be multiple media stream (audio, video, etc). The three levels are
Users, SIP Sessions or Dialogs, Media Sessions. Unfortunately, the draft as
written supports two things and the User level information and the SIP
session level information is mixed together. I think this needs to get
fixed. 

One more use case, many audio conference systems announce when a user joins
of leaves. This is really annoying when someone transfers from the cell
phone to desk phone. Let me give you a scenario that I think XCON should
support. 

Cullen dials in to conf from cell phone and is announced. Cullen then dials
in from desk phone and is *not* announced because the user Cullen is already
in the conference. Cullen hangs up cell phone and this is *not* announced
because Cullen is still in the conference. Cullen hangs up his desk phone
and the conference announces that "Fluffy has left the building" because he
is no longer in the conference.

On 4/8/04 5:11 AM, "[email-masked]" <[email-masked]>
wrote:

> Why do you need the focus to know that it is the same user (human)? I don't
> understand the use case. Can you elaborate?
> 
> Thanks,
> Hisham
>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 12 Apr 2004 15:02:38 -0500

Cullen,

I agree with your explanation - this is definitely a goal.

However, I don't understand your initial proposals.  The conference package 
should, as you argue, just indicate that Cullen is in the conference, and 
perhaps note the media types used.  Whether these media types are supported 
by a single device, or multiple devices doesn't matter as far as the 
conference package is concerned.  What exactly is the problem you are 
trying to solve with your two proposals?  I don't think that Contact URIs 
belong in the conference package - if a participant wants detailed 
information about the way in which a participant is connected to the 
conference, the dialog package can be used.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 12 Apr 2004 19:41:31 -0700

> The conference package
> perhaps note the media types used.

Right now the conference package seems to have a lot more than that in it.
It has if I dialed in or out, disconnect reasons, on-hold, etc. that are
specific to the session not the user.

BTW. I really like the definition of the uri element in the user. I think
that was the hard problem and it is right.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Apr 2004 09:57:01 -0400

Cullen,

I think what you are trying to achieve is a good thing. But I think the 
focus may need to be psychic to achieve it. How is it supposed to know 
which dialogs to group together? I guess it could group all the things 
that share the same From address, but that won't get all the cases - 
probably not the interesting ones.

	Paul