RE: [XCON] CPCP Requirement: Conference package subscribers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [XCON] CPCP Requirement: Conference package subscribers



I didn't read Jari's answer the same way.

I think you could easily have a PC app that was not a "participant",
in that it never sends or receives media, but does:
	Read and Modify Conference Policy
	Read and Modify Media Policy
	Read and Modify whatever floor control mechanism there is

This would be a PC app for a "dumb" phone.  The phone is the "participant".
It would have a dialog with the focus, and send/receive media.  It
would be conference un-aware.

So, the PC app has to be able to subscribe to the conference package,
but is neither a dial in, nor a dial out participant.

Brian

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Monday, December 15, 2003 9:01 AM
> To: Jari.Mutikainen@nokia.com; xcon@ietf.org
> Subject: RE: [XCON] CPCP Requirement: Conference package subscribers
> 
> 
> I think I understand what you're saying now: You are talking 
> about the participant having 2 different identities, one is a 
> SIP URI and the other is a TEL URI. I originally thought you 
> are talking about the conference focus itself having 2 URIs.
> 
> If the dial-out list has your TEL URI, and we use the 
> dial-out and dial-in list as indicators to who is allowed to 
> subscribe to a conference package, then your question is: how 
> does the focus know that the SUBSCRIBE that carries your SIP 
> URI is you when it only has your TEL URI?
> 
> I have 2 solutions:
> 
> 1. Use your TEL URI in the SUBSCRIBE. Why would you use your 
> SIP URI? You certainly don't have to.
> 2. Have the dial-out list carry both your TEL and SIP URIs.
> 
> I think option 1 is far more superior.
> 
> My original question was: are there any scenarios where a 
> conference state subscriber may not be a potential participant? 
> 
> Another question: Are there any scenarios where the 
> participant is not allowed to subscribe to the conference package.
> 
> If the answer to the above 2 questions is yes, then we need a 
> separate privilege list for conference package subscribers.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: Mutikainen Jari (NMP-MSW/Helsinki) 
> > Sent: 15.December.2003 15:49
> > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org
> > Subject: RE: [XCON] CPCP Requirement: Conference package subscribers
> > 
> > 
> > I might want to follow the conference status (and manage it 
> > if I'm the host) from my PC client, and participate from a 
> > legacy mobile/PSTN device. Even if I'm using a single device, 
> > I might have a device that does not support VoIP but supports 
> > non-RT SIP, so I'm using my SIP subscription and it's SIP URI 
> > to subscribe, but Tel URI to join. 
> > 
> > Now, the only way to tie these is that we have a separate 
> > list for participants that are allowed to subscribe? In 
> > dial-in case it could be possible to put both URIs to the 
> > Dial-In list, but in Dial-out case it is impossible, as the 
> > server tries to invite both, even they mean a single participant?
> > 
> > BR,
> > Jari
> > 
> > > -----Original Message-----
> > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On 
> > Behalf Of ext
> > > hisham.khartabil@nokia.com
> > > Sent: 15 December, 2003 15:06
> > > To: Mutikainen Jari (NMP-MSW/Helsinki); xcon@ietf.org
> > > Subject: RE: [XCON] CPCP Requirement: Conference package 
> subscribers
> > > 
> > > 
> > > Jari,
> > > 
> > > You are right, if you use a non-sip protocol to join the 
> conference.
> > > 
> > > In any case, this is not related to the questions I ask that 
> > > are related who is allowed to subscribe to the conference 
> > > state event package.
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > > -----Original Message-----
> > > > From: Mutikainen Jari (NMP-MSW/Helsinki) 
> > > > Sent: 15.December.2003 15:02
> > > > To: Khartabil Hisham (NMP-MSW/Helsinki); xcon@ietf.org
> > > > Subject: RE: [XCON] CPCP Requirement: Conference package 
> > subscribers
> > > > 
> > > > 
> > > > The address from where I subscribe the conference event might 
> > > > be diffrent to the addres from where I'm joining to the 
> > conference.
> > > > 
> > > > BR,
> > > > Jari 
> > > > 
> > > > > -----Original Message-----
> > > > > From: xcon-admin@ietf.org [mailto:xcon-admin@ietf.org]On 
> > > > Behalf Of ext
> > > > > hisham.khartabil@nokia.com
> > > > > Sent: 15 December, 2003 14:55
> > > > > To: xcon@ietf.org
> > > > > Subject: [XCON] CPCP Requirement: Conference package 
> subscribers
> > > > > 
> > > > > 
> > > > > This is in reference to requirement REQ-H5 in 
> > > > > 
> > http://www.ietf.org/internet-drafts/draft-ietf-xcon-cpcp-reqs-00.txt
> > > > 
> > > >    REQ-H5: It SHOULD be possible to define users who are 
> > allowed to
> > > >    subscribe to conference event package [4]
> > > > 
> > > > Should this be a separate list? or should a combination of 
> > > > Dial-out list, Dial-in list be sufficient? i.e. only 
> > > > participants and potential participants can subscribe to the 
> > > > conference event package (outside users not allowed)?
> > > > 
> > > > In any case, I think the requirement needs to stay, but needs 
> > > > rewording according to the conclusions we come up with that 
> > > > answer the above question.
> > > > 
> > > > Regards,
> > > > Hisham
> > > > 
> > > > _______________________________________________
> > > > XCON mailing list
> > > > XCON@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > > 
> > > 
> > 
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> > 
> 
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.