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--