One document matched: draft-stewart-avt-00.txt

     RTP Payload format for Shared Multicast Virtual Worlds (SMVW).

                        draft-stewart-avt-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   Comments are solicited and should be addressed to the author and/or
   the audio/video transport working group's mailing list rem-
   conf@es.net.

                                Abstract

      This memo defines a method of encapsulating information for the
      creation of multicast shared virtual worlds, possibly consisting
      of an amalgamation of Multicast applications (for example, a VRML
      world, and Multicast Audio with proximity bounds).

















1 Introduction.



  The need for shared virtual worlds has been recognised for some years,
  particularly in the development of DIS/RTI/HLA by DARPA and the US
  DoD. At the same time VRML has emerged as an approach for the 3-D web
  viewer and in parallel a simple method to share such a virtual world
  has been developed with the VRML interchange protocol used by the VNet
  client-server pair. To progress this lite-weight approach to shared
  virtual worlds the shared multicast virtual world protocol (smvwp) is
  being proposed. The approach is seen as complementary to the dis-java-
  vrml and vrtp work in the Web 3D Consortium emphasising service to a
  relatively smaller community of participants and simplicity in
  supporting the amalgamation of multicast applications, for example
  shared VRML with avatars able to talk together via RAT.


  This memo defines a method for encapsulating smvwp information in RTP
  for the creation of multicast shared virtual worlds with the
  possibility of amalgamation with other multicast applications.




2 Discussion.

  There are two classes of data that must be interchanged over a network
  to allow for shared virtual worlds. These are:

  a) Time sensitive data

  b) informational data

  Time sensitive data will flow over RTP; informational data will flow
  over RTCP.

  When one moves in a shared world, others must see this movement, and
  they must know how to map an Avatar, and other services, to this
  movement.

  Thus, position/orientation packets must be sent in a timely manner.
  These packets contain position and orientation parameters (with
  standard VRML meanings) that identify the current location (at time of
  packet generation) of that Avatar.

  Interaction between Avatars can be seen by sending a "clicked" packet.













  The result of this clicked packet is defined by either the Avatars
  themselves, or by the world.

  An avatar can have gestures or other actions, definable and invokable
  by the originator of that Avatar. Such gestures may include facial
  expressions (laugh, smile, frown, etc) or other actions, for example,
  morphing from one shape to another.

  By either including a VRML Route command or an external program, it is
  possible to have a clicked event initiate avatar gestures. An example
  of this may be a button on a display case, that when clicked, changes
  the items in the display.

  Informational data consists of the Avatar info (a reference to a VRML
  file), standard RTCP data such as a CNAME, and special items, for
  instance, a "world" checksum to ensure that all avatars are playing in
  the same world.




3 Payload format definition

  The following outlines the packet types.

  3.1 Time Sensitive Data.

  3.1.1 Position

  Packet type:   1

  A position in x-y-z coordinates; the base  coordinates and references
  supplied by the base world.

       X axis (32 bit float)
       Y axis (32 bit float)
       Z axis (32 bit float)



  3.1.2 Orientation

  Packet type:   2

  An orientation change in x-y-z-angle; the base coordinates and
  references supplied by the base world.  NOTE: the angle is measured in
  radians, as per VRML spec.













       X axis (32 bit float)
       Y axis (32 bit float)
       Z axis (32 bit float)
       angle  (32 bit float)


  3.1.3 Clicked

  Packet type:   3

  This packet contains the SSRC of the object that was clicked on; the
  source of the action can be taken from the RTP payload header.

       Sequence number (32 bit unsigned integer)
       Dest SSRC (32 bit unsigned int)




  3.1.4 Interaction/Gestures

  Packet type:   4

  This packet contains avatar-dependent action information; and is
  generated from a source, and is broadcast to all members of the
  multicast session.

       Sequence number (32 bit unsigned integer)
       Action Information (stream of UTF-8 characters)


3.2 Informational Data.

  These are passed as APP fields in RTCP packets.


  3.2.1 Avatar Information

  Packet type:   ?

  This packet contains the scaling factor for an avatar, and the URL of
  an avatar to represent this SSRC.

       X Scaling (32 bit float)
       Y Scaling (32 bit float)
       Z Scaling (32 bit float)
       URL (UTF-8 String)













  3.2.2 World Checksum


  Packet type:   ?


  A 32 bit checksum to ensure that all players are playing in the same
  virtual world.

  Currently, no algorithm has been selected to generate this checksum.

       Checksum  (32 bit unsigned int)



  3.2.3 Proximity information


  Packet type:   ?

  This information distributes the "personal space" around the avatar,
  for use in non-VRML collisions, audio closeness, and other.

  There are two rings determined by these values, the "inner ring",
  where two entities are considered to be close, and an outer ring, to
  allow a graded approach.

  For instance, Audio would be at full volume when within the inner
  ring, and would fall off to zero from the edge of the inner ring to
  the outer ring.

       X inner axis   (32 bit float)
       Y inner axis   (32 bit float)
       Z inner axis   (32 bit float)
       X outer axis   (32 bit float)
       Y outer axis   (32 bit float)
       Z outer axis   (32 bit float)



  3.2.4 Amalgamation of tools info

  Packet type:   ?

  This allows grouping of different media sources that may be
  independent on the RTCP CNAME parameter.














  The owner of the resource is the SSRC in the originating RTP packet.

  Packets consist of groups of the following tuples:

       SSRC of tool (32 bit integer)
       Mcast address/port (network dependent)


4 example packets


  4.1, a Position update.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |V=2|P|X| CC=0  |M|       PT    |          sequence number      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   timestamp of initial frame                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             synchronization source (SSRC) identifier          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | SVRML PT      |  Version      |     unused                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     X axis  (32 bit float)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Y axis  (32 bit float)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Z axis  (32 bit float)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



  Where:

  V, P, X, CC, M, PT, sequence number, Timestamp, and SSRC are defined
  in the RTP spec.


  SVRML is the Shared VRML Packet Type; this determines the remainder of
  the packet (see above)

  Version is the version of Shared Multicast Virtual World Protocol.

















5 Security considerations

  There are no additional security considerations beyond those noted for
  RTP [1], the RTP profile for audio/video conferences [2] and the RTP
  payload format for redundant audio [4].


6 Author's Addresses


   Dr. John L. Robinson
   john.robinson@crc.ca

   John A. Stewart
   john.stewart@crc.ca

   Communications Research Centre
   3701 Carling Avenue
   P.O. Box 11490, Station H
   Ottawa, Ontario
   Canada
   K2H 8S2

7 References.

  Web3D Consortium:
  http://www.web3d.org/


  The VRML Interchange Protocol: Vnet.
  http://ariadne.iz.net/~jeffs/vnet/


  VRTP and Web3d Working Group:
  http://www.stl.nps.navy.mil/dis-java-vrml/


  DIS/RTI/HLA:
  http://www.dmso.org/


  IEEE Standard for Information Technology:
    - Protocols for Distributed and Interactive Simulation
      IEEE std. 1278-1995