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 <sip:a.g.bell@bell-tel.com>
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