Minutes for the SIPTEL (SIP for IP Telephony) BoF
Reported By: Wilhelm Wimmreuter, Carsten Bormann, Jonathan Rosenberg
Prepared By: Jonathan Rosenberg


The SIPTEL BoF met for one session on Wednesday morning. There were
approximately 150 people in attendance. The BoF was chaired by
Jonathan Rosenberg, from Bell Laboratories.

The meeting started with a presentation of the agenda. Allyn Romanow
made a brief statement that the meeting would proceed in two
parts. The first would be a presentation and discussion of the
currently proposed three work items. That would followed by a
"temperature taking" session, where people could express their
opinions on whether they thought development of a lightweight Internet
telephony signaling protocol would be useful.

The BoF started with a presentation of what the possible work items
could be. These include (1) User Location, (2) Call Processing
Language, and (3) Gateway Discovery. The User Location item is to
develop a protocol (likely based on SIP) to allow a client to resolve
the name of someone it wishes to call to an address where the user
currently resides, across the wide area Internet. The resolution would
take into account caller and callee preferences, and possibly call
progression (such as busy). The location would be cross-application,
so that the result of the location process would be both an address
and a service (such as http, h.323, etc.). It could be used in many
ways, including as a back-end for H.323 to allow gatekeepers to
resolve an LRQ request. The call processing language is a syntax
allowing a client to specify to a server (such as a gatekeeper) its
preferences for how it would like the call to be processed, which
might depend on the time of day, caller, etc. The Gateway Discovery
protocol would allow a client (such as a gatekeeper or end system) to
find the address of a gateway towards a telephony number, possibly in
a remote ISP, and such a selection depending on multiple
criteria. A question was asked as to whether gateways included
gateways to frame relay, ATM, etc.; the answer was yes. It was
emphasized that these items are independent and orthogonal to Internet
telephony signaling protocols (such as H.323), but represented missing
pieces in the overall puzzle.

Following this discussion, there was a brief tutorial on SIP by
Henning Schulzrinne. This covered issues like address resolution,
forwarding, call center, parameter modification, etc. Security was
raised here as an issue, including authorization. Concerns were raised
about the growing size of the SIP spec. That discussion was deferred
to mmusic where it was deemed more appropriate. 

There was then a general question and answer session. Many points came
up. Security was raised as a major issue all around. It was clear that
whatever work was done, security would need to be incorporated from
the beginning. The discussion brought up many issues about the three
proposed items. 

For the user location service, several points were made:

1. It was emphasized that what needed to be done was to deal with telephone
numbers, and to provide the "big picture", and to show how users can
be located across a variety of different addresses and address
formats.
2. Would telephone number translation need to occur for the caller as
well? The scenario is a PC to PSTN call. In that case, the gateway
needs to indicate the calling party number to the telephone
network. This number should be the actual caller, not the
gateway. However, the original caller is actually an IP endpoint, so
some kind of translation might be needed. 

There were also comments about the call processing language. Several
issues were raised:

1. The call processing language effectively defines agents which
reside at the server. Will the group define mechanisms for
transporting these agents? For example, they might need to be moved
from server to server for backup reasons.
2. The mass user does not know how to write scripts. Having incorrect
scripts crash servers would be a big problem. The chair pointed out
that a user need not write such a script - it could be generated
automatically by an application, for example.
3. There should be the possibility for different types of
languages. In fact, is there a need for standardization here at all?
The group could potentially define just the identifiers for indicating
which language it is, but not define it. The difficulty with this
approach, however, is that with no baseline specification,
interoperability is impossible.

There was some debate about the nature of the gateway discovery
service:

1. Was multihop being considered?
2. Could the web be used instead to find gateways?
3. Is this routing or service discovery? 
4. There would be tremendous opportunity for spammers and misbehavior
here. Security would need to be top priority.
5. Multicriteria selection specified by the user is a nice service,
but will tremendously complicate routing.

There were many comments, in general, about the scope of the group.
Some concerns were raised about the scope of the group already being
too large. Others expressed concerns that accounting was a key part of
the picture, and should be in the scope of the group. The area
directors emphasized that accounting and billing were definitely NOT
in the scope of the group. One person mentioned that H.323 covers
every one of these issues, and he passed out an informational document
about how H.323 is used on the Internet. Another comment was made that
siptel is not an appropriate name any longer, given that the focus is
not on SIP.

Following the discussion, the IESG wanted to do a temperature
taking on the issue of developing a lightweight Internet
telephony signaling protocol. The area directors stressed that there
was no proposal for a working group to do this; they were interested
in hearing what the constituency felt. The chair presented a few
slides on what "lightweight Internet telephony signaling" might
mean. The analogy of SNMP to CMIP, and TFTP to FTP was made. SIP is
lightweight in the sense that it has few messages, few header fields and
simple parsing. 

As expected, there were mixed responses. Some felt that H.323 was too
heaviweight for non-PC clients, others felt it was too complex, and
was a barrier to entry for smaller companies. Others did not want to
see duplication of work, and were concerned anyway that a lightweight
telephony signaling protocol would prove impossible to develop, based
on experiences with regular telephony. Others expressed concerns about
having multiple protocols, making interoperability more complex. There
was definitely no consensus on the issue. In fact, a subset of the
audience actually applauded when the subject of an alternate signaling
protocol came up. Others felt that Internet telephony signaling could
be done by simply transporting native SS7 and Q.931 on IP.

The group concluded with a restatement of the proposed charter for the
group: User Location (1 standards track RFC), call processing language
(1 standards track RFC), and gateway discovery (1 or 2 standards track
RFC's). 



--------------C7409F1D56420290F19C90DF--