Subject: [XCON] RE: Wireless Systems do not flee XML

From: Markus.Isomaki at nokia.com ([email-masked])
Date: Wed Jul 16 10:23:42 2003

Hi,

I agree that for certain floor control operations latency is clearly the most important issue in wireless networks. Push to talk type of applications require some very efficient mechanism to compete for the "floor", in which case some other enconding than XML would seem reasonable.

Actually, for some applications it would be enough just to do the contention with the media (i.e. the RTP packets carrying the talkburst), and then just to learn if you did NOT get the floor through some simple protocol message (in which case the person talking would get some negative indication). In other words this means that you always don't need to first explicitly reserve the floor for you before starting to send the media. I believe this is how it works in most of the proprietary push to talk apps.

I think it would make sense to include the support for this kind of scenario also under the "floor control" work item in XCON. First we would ofcourse need some more specifric requirements text. 

Markus   

> -----Original Message-----
> From: ext Dean Willis [mailto:[email-masked]]
> Sent: 16 July, 2003 11:12
> To: Mayer Georg (NMP/Helsinki); [email-masked]
> Subject: [XCON] RE: Wireless Systems do not flee XML
> 
> 
> Georg said:
> 
> > Dean made a statement during the XCON BOF that the wireless 
> > guys (to which I count myself) do not want XML as it would 
> > use to much bandwidth. That is in fact not true - there were 
> > requirements expressed that XML is the preferred solution for 
> > coding e.g. CPCP, as this would allow us XML also for XCON 
> > purposes and we would not need to implement the next encoder 
> > in our devices. This was actually a requirement that clearly 
> > came out from the last 3G CN1 meeting.
> 
> 
> I was specifically worried about XML for floor management in 
> a conference.
> 
> Within the "other" mobile community (3GPP2 -- CDMA) everybody 
> that I've
> talked is of the belief that the floor control messages for 
> PoC (push talk
> over cellular) will need to be down in the 20-30 byte range (including
> headers after ROHC) to work optimally with CDMA2000. This 
> allows them to
> transmit in a single short data burst. 
> 
> XML for configuration and other non-real-time data seems to be ok.
> 
> --
> Dean
> 
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
>

---

From: petri.koskelainen at nokia.com ([email-masked])
Date: Wed Jul 16 13:45:37 2003

Hi,

I agree with Markus.

Floor control protocol (at least the floor claim/grant/deny part of it) should 
not be used in time-critical applications like push to talk.

Typical floor controlled application scenarios involve floor chair (human being)
who grants or denies the floor claim. There is also claim queue management
involved as there may several floor claims waiting for turn. 
This is not very time-critical (and often there are couple of people ahead of 
you in the floor claim queue anyway).
Floor claim request may include additional information, e.g. priority or 
topic of your comment (chair can better control the floor queue if he knows
in advance what is the topic of the comment).
XML (and SOAP) is logical solution for this, as defined in draft-wu-sipping-floor-control.

Push to talk like applications definitely should not use floor chairs or floor claim requests
as it would be too slow. Instead, they should use fixed media and floor policies 
(something like "no floor control protocol for media X, first speaker is passed through"). 
In the rare case that this did not work out (e.g. two persons starts speaking at the same time) 
then there may be negative notification, as markus pointed out. So this kind of application might 
utilize XML/SOAP only for floor creation. Anyway, this specific example is a service 
and IETF does not specify services.

> I think it would make sense to include the support for this kind of scenario also under 
> the "floor control" work item in XCON.

We tried to support this in floor control draft (e.g. create_floor defines the floor policy 
which says whether floor claims are used) but it seems that this work must be better aligned 
with media policy work. 

--
Petri

> From: ext [mailto:[email-masked]]
> Sent: 16 July, 2003 18:24
> To: [email-masked]; Mayer Georg (NMP/Helsinki);
> [email-masked]
> Subject: RE: [XCON] RE: Wireless Systems do not flee XML
> 
> 
> Hi,
> 
> I agree that for certain floor control operations latency is 
> clearly the most important issue in wireless networks. Push 
> to talk type of applications require some very efficient 
> mechanism to compete for the "floor", in which case some 
> other enconding than XML would seem reasonable.
> 
> Actually, for some applications it would be enough just to do 
> the contention with the media (i.e. the RTP packets carrying 
> the talkburst), and then just to learn if you did NOT get the 
> floor through some simple protocol message (in which case the 
> person talking would get some negative indication). In other 
> words this means that you always don't need to first 
> explicitly reserve the floor for you before starting to send 
> the media. I believe this is how it works in most of the 
> proprietary push to talk apps.
> 
> I think it would make sense to include the support for this 
> kind of scenario also under the "floor control" work item in 
> XCON. First we would ofcourse need some more specifric 
> requirements text. 
> 
> Markus   
>