[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protocol Action: 'The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model' to Proposed Standard
The IESG has approved the following document:
- 'The Session Initiation Protocol (SIP) Conference Bridge Transcoding
Model '
<draft-ietf-sipping-transc-conf-03.txt> as a Proposed Standard
This document is the product of the Session Initiation Proposal
Investigation Working Group.
The IESG contact persons are Jon Peterson and Cullen Jennings.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-conf-03.txt
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 modeFrom ietf-announce-bounces at ietf.org Mon Aug 21 16:05:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GFFxL-0004lP-G8; Mon, 21 Aug 2006 16:01:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1GFFxJ-0004ew-FW
for ietf-announce at ietf.org; Mon, 21 Aug 2006 16:01:05 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
helo=chiedprmail1.ietf.org)
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFDQb-00024F-9S
for ietf-announce at ietf.org; Mon, 21 Aug 2006 13:19:09 -0400
Received: from ns3.neustar.com ([156.154.24.138])
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFDNS-0005oG-S0
for ietf-announce at ietf.org; Mon, 21 Aug 2006 13:15:57 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9053E175AA;
Mon, 21 Aug 2006 17:15:24 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
id 1GFDMy-0006wm-5k; Mon, 21 Aug 2006 13:15:24 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce <ietf-announce at ietf.org>
Message-Id: <E1GFDMy-0006wm-5k at stiedprstage1.ietf.org>
Date: Mon, 21 Aug 2006 13:15:24 -0400
X-Spam-Score: -5.8 (-----)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: mpls mailing list <mpls at lists.ietf.org>, mpls chair <swallow at cisco.com>,
Internet Architecture Board <iab at iab.org>,
RFC Editor <rfc-editor at rfc-editor.org>
Subject: Document Action: 'OAM Requirements for Point-to-Multipoint
MPLS Networks' to Informational RFC
X-BeenThere: ietf-announce at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce at ietf.org>
List-Help: <mailto:ietf-announce-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces at ietf.org
The IESG has approved the following document:
- 'OAM Requirements for Point-to-Multipoint MPLS Networks '
<draft-ietf-mpls-p2mp-oam-reqs-01.txt> as an Informational RFC
This document is the product of the Multiprotocol Label Switching Working
Group.
The IESG contact persons are Ross Callon and Bill Fenner.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-oam-reqs-01.txt
Technical Summary
This informational document describes requirements for data plane
operations andmanagement for P2MP MPLS LSPs. These requirements apply to
all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs
and multicast LSPs.
Working Group Summary
The chairs have not answered this question after multiple requests. The
authors report that there was no dissent, and that there was review from
multiple experts.
Protocol Quality
Ross Callon has reviewed this for the IESG.
Note to RFC Editor
There are a few Nits identified during the Gen-ART review that should be
corrected prior to publication. I have copied these here (comments by
<Black_David at emc.com>):
This draft is basically ready for publication, but has nits
that should be fixed before publication.
Section 2.1
This requirements draft uses RFC 2119 terminology (MUST, SHOULD, etc.).
In addition to incorporation of the RFC 2119 boilerplate (already done),
please explain that these requirements are being stated as requirements
of OAM mechanism and protocol *development*, as opposed to the usual
application of RFC 2119 requirements to an actual protocol, as this
draft does not specify any protocol.
Section 2.3
OAM: Operations and Management
OA&M: Operations, Administration and Maintenance.
That's an invitation for confusion. The OA&M acronym is not used
in this draft - please remove it from this section.
Section 4.1
The discussion of limits on proactive OAM loading shol. 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
This document was reviewed for the IESG by Jon Peterson. There are
believed to be several implementations of this approach either in-use or
demonstrated at interoperability events.
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
uld probably
explicitly say that reactive OAM (dealing with something that has gone
wrong) may violate these limits (i.e., cause visible traffic
degradation)
if that's necessary or useful to try to fix whatever has gone wrong.
Also, a wording nit:
In practice, of course, the requirements in the previous paragraph
may be overcome by careful specification of the anticipated data
throughput of LSRs or data links,
"overcome" --> "satisfied" or "met"
Thanks,
--David
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce