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- 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract 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 calling. 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 calling. 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 defined. 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://130.54.0.1:10000 2. iphone://130.54.0.1:10000/0,5 3. iphone://phone.ooi.co.jp/m=rtp:10000:0,m=rtp:10000:5 4. iphone://phone.ooi.co.jp/m=rtp:10000:0&a=dtmf:1234 5. iphone://130.54.0.1/m=rtp:9001:26 6. iphone://130.54.0.1/m=rtp:9001:JPEG 7. iphone://130.54.0.1/m=rtp:9001:100:JPEG:30 8. iphone://130.54.0.1/m=rtp:9000:5, m=rtp:9000:99:DVI4:8000&m=rtp:9001:100:JPEG:8000 Both of #1 and #2 examples mean that an IP address is 192.168.0.250, a port number is 10000, and encoding methods are PCMU (0) and DVI4 (5). #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 FUJIKAWA Kenji Graduate School of Informatics Kyoto University Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN Phone: +81-75-753-5387 Fax: +81-75-751-0482 EMail: fujikawa@kuis.kyoto-u.ac.jp 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 EMail: mohta@necom830.hpcl.titech.ac.jp FUJIKAWA & OHTA Expires on 12 April 2001 [Page 5]