INTERNET DRAFT                                            FUJIKAWA Kenji
draft-fujikawa-iphone-url-01.txt                        Kyoto University
                                                           OHTA Masataka
                                           Tokyo Institute of Technology
                                                         12 October 2001

                               IPhone URL

Status of this Memo

   This document is an Internet-Draft and is subject to 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   This memo describes IPhone URL, which is employed for Internet
   telephone using NOTASIP protocol.

1. Introduction

   In NOTASIP protocol [NOTASIP], end hosts does not negotiate each
   other for information on CODEC, UDP port number of a callee host,
   etc.  Such information is written in Internet Phone (IPhone) URL in
   advance.  IPhone URL provides NOTASIP with sufficient information for

   IPhone URL is defined with referring to Session Description Protocol
   (SDP) [RFC2327] and simplifying SDP.

FUJIKAWA & OHTA         Expires on 12 April 2001                [Page 1]

INTERNET DRAFT                 IPhone URL                   October 2001

2. Syntax

    iphoneurl    = "iphone:" hostport [ "/" [ formats | media *[ "," media ] ]

    formats      = format | formats "," format
    format       = digits | encodingname [ ":" clockrate
                                            [ ":" encodingparameter ] ]

    media        = medium *[ "&" attribute ] *[ "&" medium *[ "&" attribute ] ]

    medium       = rtpmedium
    rtpmedium    = "m=rtp:" port ":" payloadtype
    payloadtype  = format | dynamicpayloadtype ":" format
    dynamicpayloadtype  = digits

    encodingname = 1*unreserved
    clockrate    = digits
    encodingparameter = digits

    attribute    = dtmfattr

    dtmfattr     = "a=dtmf:" dtmfdigits
    dtmfdigits   = 1*[ digit | "*" | "#" | "u" | "p" ]

   Refer to [RFC1738] for undefined symbols.

3. Semantics

   "hostport" indicates an IP address or DNS name of a callee host, and
   can also indicate a port number.  A port number specified by
   "hostport" is used as long as "medium" indicates no port number.  If
   a port number is not specified in "hostport" or "medium", XXXX (to be
   defined by IANA) is used instead.

   There are two types of indications. One uses just "formats" and the
   other uses "media".

   If both of "formats" and "media" that follow "/" are omitted, formats
   0(PCMU=G.711mulaw, 64Kbps) and 5(DVI4=DVI ADPCM Wave Type, 32Kbps)
   are regarded to be available.

3.1 Simple Indication Just by "formats"

   "formats" indicates one or more formats (payload types, encoding
   methods) determined by a callee.  A caller specifies one of them when

FUJIKAWA & OHTA         Expires on 12 April 2001                [Page 2]

INTERNET DRAFT                 IPhone URL                   October 2001

   "format" is one of the formats defined in RTP/AVP [RFC1890], and it
   is specified by digit", or by "encodingname", "clockrate" and
   "encodingparameter"s. When digits are used, the value must be from 0
   to 127. (Note that there is the name "1016" as a encoding name, this
   is distinguished from the range of the value.)  "clockrate" is a
   clock rate, and the meanings of "encodingparameter"s are depend on
   "encodingname."  However, for audio streams, the first
   "encodingparameter" is the number of channels by default, according
   to RFC2327.  If "encodingname" cannot uniquely identify a encoding
   method (e.g. DVI4), "clockrate" and/or "encodingparameter" must be
   also specified.

   When "format" is used as an encoding method, the payload type is set
   to the value of the encoding method indicated by "format", which is
   defined in RFC2327.

3.2 Advanced Indication by "Media"

   "Media" consists of "medium" and 0 or more "attribute"s.  When
   multiple "media" are specified with divided by ",", the caller
   selects one of "media" and makes a call.  The URL must be written so
   that the callee can judge which "media" is specified by the port
   number and/or the payload type that the caller specified.

   "Medium" makes a port number to correspond to an encoding method.
   "rtpmedium" that employs RTP is currently defined.

   "Rtpmedium" means that the payload type is set to the value indicated
   by "payloadtype" and send at the port number indicated by "port".

   "Paylaodtype" consists of just "format" or a pair of
   "dynamicpayloadtype" and "format". The latter is the way to assign a
   payload type dynamically.

   If just "format" is specified, then the encoding method is what the
   format indicates, and the payload type in RTP packets is the value of
   the format.

   If "dynamicpayloadtype" and "format" are specified, the encoding
   method is what "format" indicates, and the payload type in RTP
   packets is "dynamicpayloadtype".

   "attribute" is an attribute of "media", and "dtmfattr" are currently

   If "dtmfattr" exists, after a stream of a "media" that precedes the
   "dtmfattr" is established, "dtmfdigits" are sent by DTMF tone using
   one of "format"s in the "media".  There are special tones represented

FUJIKAWA & OHTA         Expires on 12 April 2001                [Page 3]

INTERNET DRAFT                 IPhone URL                   October 2001

   by "u" and "p".  "u" means a user number, and "p" means a PIN,
   respectively.  If these numbers are registered in a caller host, and
   the caller host finds "u" and/or "p" in a URL, then it sends these
   numbers by DTMF tone.

4. Examples

      1. iphone://
      2. iphone://,5
      3. iphone://,m=rtp:10000:5
      4. iphone://
      5. iphone://
      6. iphone://
      7. iphone://
      8. iphone://,

   Both of #1 and #2 examples mean that an IP address is,
   a port number is 10000, and encoding methods are PCMU (0) and DVI4

   #3 is the same as the 1st and the 2nd, except that a DNS name is
   applied instead of an IP address, and different notation is used.

   #4 specifies to send 1234 by DTMF tone after stream establishment.

   #5 an #6 is the same.  They send JPEG stream.  Here, payload type 26
   means JPEG.  The default clockrate is 90kHz according to RFC2035.
   Note that the frame rate can be determined by means of checking the
   received RTP packets.

   #7 sends JPEG stream with setting the payload type number to 100 and
   the clock rate to 30.

   #8 enables to select an audio stream only or both of audio and video
   streams.  In the case of an audio stream only, the stream is sent to
   the port number of 9000 with the payload type of 5.  In the case of
   both audio and video streams, the audio stream is sent with the port
   number of 9000, the payload type of 99 and the format of DVI4 8kHz,
   and the video stream is sent with the port number of 9001, the
   payload type of 100 and the format of JPEG.  (Here, for
   synchronization, the clock rate of JPEG stream is adjusted to 8kHz.
   For instance, a JPEG stream becomes 29.96 fps by means of adding 267
   to the time stamp for each frame.)

9. References

FUJIKAWA & OHTA         Expires on 12 April 2001                [Page 4]

INTERNET DRAFT                 IPhone URL                   October 2001

[NOTASIP] Ohta, M., and Fujikawa, K., "Nothing Other Than A Simple
          Internet Phone (NOTASIP)", Internet Draft draft-ohta-
          notasip-03.txt (work in progress), October 2001.

[RFC2327] Handley, M. and Jacobson, V., ``SDP: Session Description Pro-
          tocol,'' RFC 2327, November 1997.

[RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource
          Locators (URL)", RFC 1738, December 1994.

[RFC1890] Schulzrinne. H., "RTP Profile for Audio and Video Conferences
          with Minimal Control", RFC 1890, January 1996.

Security Considerations

   No security issues are addressed in this document.

Authors' Addresses

   Graduate School of Informatics
   Kyoto University
   Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN
   Phone: +81-75-753-5387
   Fax: +81-75-751-0482

   OHTA Masataka
   Computer Center
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN
   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3415

FUJIKAWA & OHTA         Expires on 12 April 2001                [Page 5]