*Attendees*
Jill Gemmill, UAB
Tyler Johnson, UNC
Nadim El-Khoury, UNC
Tom Barton, U. Chicago
Ann West, Educause
Jeanette Fielden, Internet2
Lisa Hogeboom, Internet2
Steve Olshansky, Internet2

*Discussion*

Tyler updated the group on the ITU status of H.350. The H.350 series of documents have made it through the alternate approval process and submission has been approved. An implementer's guide will address a minor H.323 issue that was not fully addressed in the standard. H.350 is not officially a standard till some administrative details have been taken care of and the formal announcement is made. Tyler is working with Internet2 on a press release when the ITU H.350 announcement happens. Jill is working on trying to contact Network magazine to get permission for a reprint of an article about Internet2 to include as part of a packet directed at CIO's and network managers highlighting the benefits of H.350.

There are plans to present documents relating to presence, call forwarding, call preferences and address books to the raconteur's meeting in September. These will be continuing refinements to H.350. The purpose of the documents is to give an overview of the interest in an item and why or why not what work should be proposed for it.

UNC-Chapel Hill has received approval and identified funding to join the ITU as a sector member of study group 16.

Options for Authenticated Identity Management in SIP: Jill forwarded an e-mail from the SIPPING list with a link to Jon Peterson's Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-01.txt. What is of interest is the attention to the need for better authentication and the discussion of enterprise-linked authentication for SIP. This might be an opportunity to create a detailed proposal to present to SIP.
[AI] Jill will contact Peterson about how to proceed and if he's interested in attending a conference call on the topic.

Tyler's interpretation is that Peterson's draft seems to gets at a fundamental item in terms of authentication for this type of technology. The recipient of the SIP request has no way to verify that the from header field has been populated appropriately without some sort of cryptographic mechanism. Normally we think of authentication as you authenticate to a server, such as in e-mail. Whoever receives the e-mail has no way to know it's really from you. The draft is meant to address the issue of a recipient of a call being able to have some confidence that the originator of the call is who it says it is. Federation is not addressed specifically but it does point towards the federation model with talk of using an intermediate authentication service. The decision can be made at the user end or at a proxy or something else depending on your policy.

Tom pointed out that Peterson makes a point near the end of the introduction about a model where you can support end-to-end cryptographic authentication. There is an identifier that is a non-local globally unique id for identifying the subject of authentication. Unlike the federations there is no way to make policy by other than identity an option here. One of the nice things about Shib and federation is that using identity as a token for policy is optional not mandatory.

Jill talked about Peterson's draft relating to authorization (http://www.ietf.org/internet-drafts/draft-peterson-sipping-role-authz-00.txt). As proposed, it's an extension of SIP since it involves a particular type of invite message that is not described. The protocol would need to adapt to cover this type of message. Radius lets you solve it anyway you like. If it's hiding behind the protocol the proxy doesn't necessarily need to know. In those scenarios where the call server is in the middle, it’s either trusted, in which case it unpacks the password and repacks it the way the Radius server wants to receive it, or it's not trusted which means the client has to have its password set compatible with whatever the Radius backend is, because that is what's going to unpack the password. Back ending it doesn’t change the protocol. In SIP there is no description for using certificates.

It was agreed that a careful reading of both the authorization draft and the SIP identity draft needs to be made and inquiry about the future of the expired draft needs to be made. It also needs to be determined if it meets our goals for authentication.

Tyler summarized the issues with respect to H.350, LDAP and presence. The use of LDAP for presence in H.350 has been looked at. LDAP works well in terms of being appropriate for read intensive presence lookups. Presence works in a directory in the sense that's where you look to find the person and how to reach them. However, LDAP provides no ability to selectively determine who can see presence information and who can't. Presence is more than just whether or not someone is on-line. The SIP community views it as a dynamic thing that can't be addressed by simply publishing a status. So presence requires it's own protocol and not simply an attribute that can be published in LDAP. If other presence protocols are available they can be represented in H.350 as is already done with SIP. Once the presence protocol is defined then the necessary attributes can be represented in LDAP.

The question for the group is whether or not to take on doing something analogous to enabling presence applications for H.323 equipment. SIP could be used to accomplish that. You could have an H.323 endpoint that also has SIP capabilities and it could use SIP to publish presence information but use H.323 for videoconferencing. The problem is H.323 developers may not want to license and support SIP in their endpoints just to achieve this. H.323 and SIP tend to be thought of as competing protocols to accomplish video/voice over IP. Where H.323 is built to meet a specific application need, SIP is a much more generic signaling protocol that can support a variety of applications.
[AI] Nadim will investigate if we want to take on the work of identifying a presence protocol for use in H.323, either building one or identifying one.

Tyler described a new high quality H.323 soft endpoint called Vpoint that is made by Vcon and uses the Radvision stack (http://www.vcon.com). It has been bundled with other products and hardware previously but is now available as a standalone. It's particularly nice for people who use both SIP and H.323 since it doesn't lock you into a particular set of hardware. There is interest in exploring if Vcon could be persuaded to expand it to include H.350 and other VC work.

Internet2 Fall Member meeting: It would be beneficial if there were a greater vendor presence at the VC session Tyler has at the fall meeting.
[AI]Tyler and Jill will coordinate involving vendors in the VC session at the fall Internet2 member meeting.

Ben Teitelbaum is working on a SIP MCU for VoIP. He's hoping to use it to replace Internet2 conference calls.
[AI] Steve Olshansky will invite Ben to a VC call to talk about what he's learned.

The next call is Monday August 25, 2003.