Framework for Transcoding with the Session Initiation Protocol (SIP)
draft-ietf-sipping-transc-framework-05

[Ballot discuss]
Section 2 implies there is a way for the caller to find out about the callee's capabilities. If the callee has two UAs, one that only does G.711 and one that only has a GSM codec, I don't think the caller can figure out what they need to do beforehand. The problem happens when there is the combination of multiple UAs with different capabilities and parallel forking.

[Ballot discuss]
SIP does not require the the Offer to be in the INVITE, and in these cases it seems like the 3PCC approach will not work. Since this documents defines two approaches, I think it would be worth pointing out that the conferencing approach is preferred or at least some of the limitations of the 3PCC approach.

Section 2 implies there is a way for the caller to find out about the callee's capabilities. If the callee has two UAs, one that only does G.711 and one that only has a GSM codec, I don't think the caller can figure out what they need to do beforehand.

[Ballot comment]
From Gen-ART review by Michael Patton:

...if the document is being changed due to some other
issues, the editors might consider these changes as well.


Minor comments
--------------

I do not believe that all the Normative references are, in fact,
Normative.  In particular, [1] and [8] are only referenced in a "for
example ... could be used" style, which is clearly only Informative.

There is a transcoding case that I think might be a useful example,
but doesn't appear anywhere in the document.  If there is a rewrite,
you may wish to mention it somewhere for additional support.  Perhaps
in the introduction.  The case I'm thinking of is where the two ends
do not support a common bandwidth, perhaps one end only supports high
quality (and therefore high bandwidth) video, but the other end is
bandwidth constrained and requires a different encoding with lower BW
requirements.  For most combinations like this, it would be possible
to have a transcoder that solves the mismatch.  It might even be
offered as a standard option at the ingress to the lower BW portion of
the network.


I note that this document along with references [10] and [11] actually
forms a loosely coupled set, where I understand this document is an
informational overview and the other two are details of the two
approaches.  I applaud this approach, if that's what is intended, but
would like to see that relationship described in this document.  Once
again, a suggestion for better clarity, but not worth holding up the
document if nothing else is being changed.


----------------------------------------------------------------
  The following editorial issues are noted for the convenience
  of possible copy editors but are not part of the technical review.

Clarity
-------

In Section 3 very near the top of Page 5, you have a reference for
3pcc to reference [7].  Would it also be productive to reference [10]
as well there?  Also, that paragraph has no reference for the bridge
model.  Should [11] be referenced?


Typos
-----

Section 3.1: "This model also allows to invoke" => "This model also
allows invoking"

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 document was reviewed by chairs Rohan Mahy and Dean Willis and
authored by chair Gonzalo Camarillo. We believe this document 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 has been well-reviewed by the working group, but has
received little review from outside the working group. Given the
narrow scope of the document and its "framework" nature, this should
be acceptable.

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.)?

I have no concerns of this nature.

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.

I am not aware of any such issues.

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?

It has been fairly thoroughly discussed in the WG over a long period
of time. While there are probably many people who just don't care
about the topic, those who do seem to understand and agree with it.

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.

There have been no indications of discontent with the document or its
processing.

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

Dean Willis performed a NITS review and noted no discrepancies.


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

References are appropriate, and the one non-final reference is both
informational and to a document currently in last call.

Technical Summary:

This document defines a framework for transcoding with SIP. This
framework includes how to discover the need of transcoding services
in a session and how to invoke those transcoding services. Two
models for transcoding services invocation are discussed: the
conference bridge model and the third party call control model.
Both models meet the requirements for SIP regarding transcoding services
invocation to support deaf, hard of hearing, and speech-impaired
individuals.