The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model
draft-ietf-sipping-transc-conf-03

[Ballot comment]
This is basically just a call flow usage of existing SIP stuff (and I love that). The question is, should this be PS or BCP?

[Ballot discuss]
The security considerations section covers the relevant issues.
  However, the security aspects rely on draft-ietf-sipping-uri-services,
  which does not seem to be moving rapidly.  Is there a reason to move
  this document forward without the companion document?

[Ballot comment]
INTRODUCTION, paragraph 12:

>    This way of invocation meets the
>    requirements for SIP regarding transcoding services invocation to
>    support deaf, hard of hearing and speech-impaired individuals.

  Nit: s/hard of hearing/hard-of-hearing/


Section 1., paragraph 1:

>    The Framework for Transcoding with SIP [8] describes how two SIP [3]
>    UAs (User Agents) can discover imcompatibilities that prevent them

  Nit: s/imcompatibilities/incompatibilities/


Section 1., paragraph 3:

>    The UAs do not exchange any traffic (signalling or media) directly
>    between them.

  Nit: s/them/themselves/


Section 3.2., paragraph 5:

>    If a trancoder receives an INVITE request with a URI-list with more

  Nit: s/trancoder/transcoder/

[Ballot comment]
From Gen-ART review:

nit:
The last paragraph of section 3.2 states that the transcode should return an error if it receives a URI List with more than one URI.  Earlier sections indicated that such multi-party requests were permitted.  Should this paragraph say "If a transcode which supports only two party transcoding receives an INVITE request with a URI-list with more than one URI, it SHOULD ..."

Section 3.4 begins "Figure 3 shows a similar message flow as the one in Figure 3."  I believe that the second "Figure 3" is supposed to be "Figure 2".

Yours,
Joel M. Halpern

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

The draft was reviewed by chairs Rohan Mahy and Dean Willis and
edited by chair Gonzalo Camarillo. We feel that it is ready for
publication.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document is believed to have been adequately reviewed.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

It might have a little heavy-handed use of RFC 2119 requirements
language, but so do most of the drafts these days.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is a good general working group consensus.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

We are unaware of any contention with respect to this draft.

1.g) Have the chairs verified that the document adheres to all of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

The document was checked for id nits by Dean Willis, and (outside of
a debatable usage of 2119 language), none were noted.

1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear
state? (note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until
all such IDs are also ready for publication as RFCs.)

The references are appropriately divided. Teh document does have
normative references to IETF documents that are not yet RFCS but are
either in IETF LC or are expected to be there within two weeks.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

Technical Summary:

This document describes how to invoke transcoding services using the
conference bridge model. This way of invocation meets the
requirements for SIP regarding transcoding services invocation to
support deaf, hard of hearing and speech-impaired individuals.

The Framework for Transcoding with SIP describes how two SIP
UAs (User Agents) can discover imcompatibilities that prevent them
from establishing a session (e.g., lack of support for a common
codec or for a common media type). When such incompatibilities are found,
the UAs need to invoke transcoding services to successfully
establish the session. The transcoding framework introduces two models to
invoke transcoding services: the 3pcc (third-party call control)
model and the conference bridge model. This document specifies
the conference bridge model.

In the conference bridge model for transcoding invocation, a
transcoding server that provides a particular transcoding service
(e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent)
between both UAs and is identified by a URI. The UAs do not exchange
any traffic (signalling or media) directly between them.

Working Group Summary:

This document was developed in the SIPPING working group, in large
part to address requirements raised by related work dealing with
conferencing for the hearing-impaired. The document was initially
presented as an individual contribution, was adopted by the WG, and
went through several iterations as a working group document before
being formally reviewed in a working-group last call and developing a
consensus on publication.

Protocol Quality:

There are believed to be several implementations of this approach
either in-use or demonstrated at interoperability events.