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

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

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 14.April.2004 16:23
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] User with multiple sessions in 
> Conference Package
> 
> 
> 
> 
> [email-masked] wrote:
> > It could based on the asserted identity (unless it is a 
> public conference and no authentication is needed). By 
> asserted identity I mean any authentication method available 
> to the conference server/focus.
> 
> I wonder how often the endpoints will be authenticated. In 
> most of the 
> conference servers I am familiar with today, authentication is simply 
> based on knowing the conference id.

In this case, I don't think it is possible to achieve what Cullen wants. What I had in mind was that either the network hosting the conference server authenticates the user and asserts him/her to the conference server or the conference server itself authenticates the USER.

> 
> And it probably won't be likely that all the devices a user 
> employs will 
> be bound to the the user in a way known to the conference 
> server. (E.g. 
> I am calling in from the phone tel:+1-978-555-1234, which may just be 
> some phone in a conference room, as well as the IM client 
> sip:[email-masked]. How does the phone get associated with me?)

This does not affect the authentication of the user/caller in the manner I described above.

Hisham

> 
> 	Paul
> 
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[mailto:[email-masked]]On Behalf Of
> >>ext Paul Kyzivat
> >>Sent: 13.April.2004 16:57
> >>To: Cullen Jennings
> >>Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]; Orit
> >>Levin; Henning Schulzrinne; Jonathan Rosenberg
> >>Subject: Re: [Sipping] User with multiple sessions in 
> >>Conference Package
> >>
> >>
> >>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
> >>
> >>Cullen Jennings wrote:
> >>
> >>>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
> >>>>
> >>>>
> >>>>
> >>>>>-----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
> >>
> > 
> > 
> > 
> > _______________________________________________
> > 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: Thu, 15 Apr 2004 09:23:39 -0700

I'm very happy with the only correlation to know that two SIP dialogs are
the same user is the definition of the "user" uri in the conference package
today. If I authenticated as some particular user to the conference system
this will work, if not it is not useful. There are several ways this might
of happened:

1) my strong sip identity information (ala IAB, S/MIME, etc)
2) my weak sip identity information (whatever I put in my From header)
3) I entered a PIN code to an IVR system
4) the uri of the conference was specific for me and identifies me

If people are not willing to provide any information correlate or
uncorrelated two different devices then sure this won't work.

It's true that many service provider hosted conference systems do not
separately identify each participant. However it is the opposite for
enterprise based conferencing systems. I have an account on the conference
system I use at work. When I dial in from my office phone it recognizes it
is me and log me in. When I dial in from some other phone, I enter a user id
and pin. It saves all my preferences, what language I want, what time zone I
am in, and does not make me record my name for ever conference. If I plan to
use a particular conference room, I could add that conference room as a
participant to the meeting and it's phone gets placed in the right
conference when it dials in.

Cullen

On 4/15/04 1:43 AM, "[email-masked]"
<[email-masked]> wrote:

> In this case, I don't think it is possible to achieve what Cullen wants. What
> I had in mind was that either the network hosting the conference server
> authenticates the user and asserts him/her to the conference server or the
> conference server itself authenticates the USER.
> 
>>