Pico SIP Feb 2001 Internet Engineering Task Force SIP WG INTERNET-DRAFT Mick OÆDoherty draft-odoherty-pico-sip-00.txt Nortel Networks Feb 2001 Pico SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document defines an extension to the SIP protocol to allow it be used in adhoc networks or Pico Networks. It leverages the direct, client to client session initiation capabilities of SIP, although there may be applications where the redirect and proxying abilities will be important also. Note the intention is not to imply that SIP is inherently the best protocol for such networks, but to recognize that there will likely be many SIP based applications in existence and that it would be good to allow these applications work with as little change as possible in this different type of network. 2. Introduction This document looks at how SIP might be used in Pico or adhoc networks. Two possible approaches are outlined (one using the REGISTER Method and the other introducing a new æHELLOÆ Method). The new approach is then outlined in more depth to: - define a new SIP request method which will be used to indicate that a particular SIP client is present in the local adhoc network and available to take part in sessions - to describe how a SIP client can maintain a list of other clients available in the adhoc network and know when to add and remove clients from the list. 2.1. Pico SIP Overview O'Doherty Internet Draft 1 Pico SIP Feb 2001 The easiest way to describe Pico SIP is to work through a typical usecase. The diagram below shows four SIP clients hosted on devices which together have formed an adhoc network. Assuming each client wants to be available to receive incoming SIP request messages, the client must make other SIP clients in the network aware of its existence. To do this it sends out a message indicating that it exists giving its SIP address and contact address. The message is repeated at an interval specified in the message itself. +------+ +------+ | SIP | ôI existö | SIP | |CLIENT| <----------------------- |CLIENT| | A | | B | | | /| | +------+ ----/ +------+ / \ / \ / \ ôI existö ôI existö / \ / \ / \ ------------------ \ / \ / \ V V +------+ +------+ | SIP | | SIP | |CLIENT| |CLIENT| | D | | C | | | | | +------+ +------+ Figure 1 û SIP Client B makes itself known to other SIP Clients. By monitoring these messages each of the SIP clients in the adhoc network can build up a picture of what other SIP clients exist in the network (or of those SIP clients that are making themselves known at least). If a SIP client has not received an æI existÆ message from a particular other SIP client for a certain amount of time it MAY conclude that that SIP client is no longer available or part of the adhoc network and remove it from its picture of the adhoc SIP network. Initiating a session is now simple and follows standard SIP procedures for direct client to client(s) communication. Once a session is in progress if the session drops and the ôI existö messages have not been received for a certain amount of time, again the client MAY conclude that the other SIP client is no longer part of the adhoc network. 2.2. Which message to use to signal that a client exists ? This document considers two approaches to signaling the existence of a SIP client in an adhoc or Pico network. Potentially either or O'Doherty Internet Draft 2 Pico SIP Feb 2001 both could be used going forward, but it would probably be better to settle on just one approach and capture that in future versions of this or another document. The first approach is to use a request message with a æREGISTERÆ method. The second is to introduce a new method, æHELLOÆ, especially for this purpose, again in a request message (in the rest of the document a reference to a REGISTER message or a HELLO message means a request message with the method set appropriately). There are advantages and disadvantages to both approaches. Using REGISTER -------------- Advantages: - no need to introduce a new method - current implementations could be modified to work with little or no effort (albeit not necessarily very efficiently) Disadvantages: - overloading the meaning of the REGISTER message - may require extra messaging (responses to REGISTER messages) Using HELLO ----------- Advantages: - intent of the message clear - no response required Disadvantages: - new method û requires updating implementations if they want to support this The rest of this document describes how Pico SIP would work using the æHELLOÆ approach (as it is the authorÆs preference). However, all the procedures described below would also apply if the Register method were used instead. Which approach is ultimately chosen should most likely be based on consensus from those interested in this area. 3. The æHELLOÆ SIP method 3.1 Format of the message A new method, ôHELLOö, is defined and it is used to tell other SIP clients that the sending SIP client exists. No response is expected or required for this message. A receiving client MUST not send a response. If the client that has sent a request with a ôHELLOö method does get a response it MUST ignore it. The definition of a request message with a method of HELLO is defined as follows (building on the standard SIP definitions in [2]): generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | Status-Line | Request-Line = Method SP Request-URI SP SIP-Version CRLF O'Doherty Internet Draft 3 Pico SIP Feb 2001 Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "CANCEL" | "REGISTER" | ôHELLOö ;<-- New Method added Request = Request-Line ; *( general-header | request-header | entity-header ) CRLF [ message-body ] ; general-header = Accept ; | Accept-Encoding ; | Accept-Language ; | Call-ID ; | Contact ; <-- contains the | CSeq ; contact address | Date ; | Encryption ; | Expires ; <-- will indicate the | From ; time before the | Record-Route ; next HELLO msg | Timestamp ; | To ; | Via ; entity-header = Content-Encoding ; | Content-Length ; | Content-Type ; request-header = Authorization ; | Contact ; | Hide ; | Max-Forwards ; | Organization ; | Priority ; | Proxy-Authorization ; | Proxy-Require ; | Route ; | Require ; | Response-Key ; | Subject ; | User-Agent ; response-header = Allow ; | Proxy-Authenticate ; | Retry-After ; | Server ; | Unsupported ; | Warning ; | WWW-Authenticate ; Table 3: SIP headers A ôHELLOö SIP message will normally only contain the Request Line, the æFromÆ general Header, the æContactÆ general header and the æexpiresÆ general header. It is important to keep the message size down for adhoc networks that have low bandwidth. The SIP URI must either be set to allow the message to be broadcast to all devices and to have each device accept the SIP message for its SIP client (by setting it to the well known SIP O'Doherty Internet Draft 4 Pico SIP Feb 2001 address sip.mcast.net as with the REGISTER method), or set to the specific URI of the particular neighbouring node that the HELLO message is addressed to in a hop by hop addressing type adhoc network. An example HELLO message is given below C->S: HELLO sip:sip.mcast.net SIP/2.0 From: A. Bell Contact: SIP:abell@47.160.38.48:5060 Expires: 10 3.2 Sending the message How the SIP client decides when to send the message is discussed in the SIP Client Section below. There is also the question of who the message is sent to and how they are addressed. This will be dependant on the type of adhoc network the device that the SIP client is hosted on is part of. For example if the device hosting the SIP client is part of a simple Pico Net with a single broadcast transport system, then it simply broadcasts itÆs message to all devices. The fact that this does not scale is not important as it only aimed at small Pico Nets. If the device hosting the SIP client is part of a larger adhoc network that supports multiple hops in the routing (or even a small adhoc network with this type of routing) then things get a little more complicated. One approach might be to limit the HELLO message to a certain number of routing hops. The disadvantage of this is that the message may not reach all devices on the network which would be a problem if the network was still small enough that reaching every device was a practical possibility. It may be that some of the evolving work on the configuration of adhoc networks (for example the work done by zeroconf group [3]) will provide mechanisms for determining the size of a an adhoc network in terms of the number of attached devices and provide a basis for deciding how far the HELLO message should be sent. This section needs further investigation and will be addressed in future versions of this document. For now, however, in smaller (or Pico) networks with a broadcast transport, broadcasting the HELLO message to all devices will work fine. 4. SIP Client behavior 4.1 Making a Client visible to others on the adhoc network This is simply a matter of sending a SIP HELLO message (a request with the method set to æHELLOÆ) at a regular interval to all known devices on the network. If a particular device does not support Pico SIP it will simply ignore the message. The SIP client itself can decide the interval to send the SIP HELLO message at. If it knows it will be in the adhoc network for O'Doherty Internet Draft 5 Pico SIP Feb 2001 a long time and it is a fairly stable adhoc network it may decide to have a fairly lengthy interval between HELLO messages. If it has just joined and the network is very dynamic it may want to send it more regularly. Additionally if some other client has just joined the network and there is a long time until the existing SIP client is due to send itÆs HELLO message it may decide to send it out sooner. The value in the Expires header of the HELLO message SHOULD usually be an integer specifying how many seconds until the next message. Clients, however, MUST be able to accept this header value in date, time format also as specified in [2]. Note: A SIP client may decide not to make itself known to other SIP clients in the adhoc network, while still maintaining a list of other SIP clients that are available and possibly even while setting up sessions with them. To do this it simply refrains from sending out the HELLO message. 4.2 Receiving an HELLO message from another SIP CLient Upon receipt of an HELLO message from another Client the receiving SIP Client should add the client that sent the message to the list of clients that it knows about in the adhoc network, along with an indication of when the next HELLO messages is expected from that Client. If the Client was already known then all that is necessary is to update the indication of when the next HELLO message is expected. 4.3 Maintaining the picture of the adhoc SIP network This is largely a matter for client implementations, but a general scheme might be to regularly audit the list of known clients and remove clients whose HELLO message is overdue by more than a certain time. The regularity with which this is done might be a function of the stability of the adhoc network and the number of SIP clients present on it. 4.4 Sending and receiving other SIP requests and responses This is standard SIP client to client behaviour. For example to start a voice call one client will send an invite directly to the client(s) it wants to talk with and they will respond directly to the initiating client. There is no proxy or redirect server involvement at the simplest level, however some applications may find uses for this behavior even in Pico or small adhoc networks. 5. Interaction with other SIP networks In certain cases from within the adhoc network there may be access to the Internet or to some other network which contains standard SIP clients and allows communication beyond the local adhoc network. For example if one of the members of the adhoc network can act as a gateway into the Internet, it may be possible for all members to send and receive information routed through this gateway. O'Doherty Internet Draft 6 Pico SIP Feb 2001 If this is the case then a SIP client on a device in the adhoc network can register itself in the normal way with a local SIP registrar accessed through the gateway (the gateway might even act as a SIP registrar itself). The SIP client will then be able to make and receive calls to any SIP URL accessible through the SIP server it is registered with as well as to any of the SIP clients in itÆs local adhoc network. The SIP client must make sure it distinguishes between the two types of address and knows to make calls to members of the PICO net directly and to others via the SIP server (or again directly if it knows and can address them in the outside network). 6. Security Security is an interesting subject in adhoc networks. There are many general security questions which need to be agreed on. It is not clear that Pico SIP itself adds anything unique to this debate, but it may be that this will need to be revisited in the future. 7. Examples Multimedia meeting services --------------------------- A simple example of Pico SIP in operation might be a meeting held in a meeting room where all the participants have the ability to form adhoc networks with one of the emerging technologies that facilitates such networks. Once everyoneÆs machines have been connected to the network, a member of the meeting may wish to show a video while using a pointer or some other form of one screen æsoft markerÆ. This person will set up a SIP session between their machine and all the other machines (either point to point or using a multipoint conferencing/broadcasting scheme). Another couple of attendees may wish to be able to set up a private (possibly encrypted) session between themselves during the meeting, either for their own æsoft markerÆ commentary on the video or, if the size/ format of the meeting allows, for voice discussions. Adhoc chats or discussions --------------------------- In certain circumstances users may wish to simply chat or set up text or other sessions with those around them in an informal adhoc network. Examples of where this might be used would include sporting events where members of the audience may wish to share encouraging thoughts (or otherwise à) with each other. Not knowing who the other people are would not necessarily be a problem in these circumstances. Exhibition tours ---------------- Another simple example might be exhibition, show or museum tours where different parts of the tour might have pre-recorded information that a user using a small device with a SIP client could set up a session with. O'Doherty Internet Draft 7 Pico SIP Feb 2001 In addition there may be a æCall an expertÆ or æCall a SalesmanÆ service so that a user can get extra information or purchase details on some part of the exhibition or show that they find particularly interesting. 8. Acknowledgements The author would like to thank all the people in Nortel Networks who provided input and feedback. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, et al., "RFC 2543 SIP: Session Initiation Protocol March 1999ö 3 M. Hattig et all, "draft-ietf-zeroconf-reqts-04.txt Zeroconf Requirements", AuthorÆs Address Mick OÆDoherty Nortel Networks Concorde Road Maidenhead Berkshire SL6 4AG England mdoherty@nortelnetworks.com O'Doherty Internet Draft 8