• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: mmusic

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-05-21 17:17 Barry Leiba

[Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba

2013-05-16 08:41 (System)

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

2013-05-16 08:41 Pearl Liang

acker.
IANA Actions - YES

NOTE: This review was based on version -18 of the draft document.

Thank you,

Pearl Liang
ICANN/IANA

On Wed May 15 08:33:51 2013, iesg-secretary@ietf.org wrote:
> Evaluation for can be found at
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>
> Last call to expire on: 2013-02-01 00:00
>
>
> Please return the full line with your position.
>
> Yes No-Objection Discuss Abstain
> Gonzalo Camarillo [ X ] [ ] [ ] [ ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
>
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
> mmusic mailing list ,
> mmusic chair
> Subject: Protocol Action: 'Session Description Protocol (SDP)
> Extension For Setting Up Audio and Video Media Streams Over
> Circuit-Switched Bearers In The Public Switched Telephone Network
> (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-17.txt)
>
> The IESG has approved the following document:
> - 'Session Description Protocol (SDP) Extension For Setting Up Audio
> and
> Video Media Streams Over Circuit-Switched Bearers In The Public
> Switched Telephone Network (PSTN)'
> (draft-ietf-mmusic-sdp-cs-17.txt) as Proposed Standard
>
> This document is the product of the Multiparty Multimedia Session
> Control
> Working Group.
>
> The IESG contact persons are Gonzalo Camarillo and Robert Sparks.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>
>
>
>
> *Technical Summary
> *
>
> The document describes use cases, requirements, and protocol
> extensions
> for using the Session Description Protocol (SDP) Offer/Answer model
> for
> establishing audio and video media streams over circuit-switched
> bearers
> in the Publich Switched Telephone Network (PSTN)
>
> *Working Group Summary
> *
>
> The WG had some discussion around the format to use for E.164 numbers
> and whether to align this with the existing definition in RFC 3108.
> The
> RFC 3108 definition was seen as deficient and the WG agreed it was
> better to align with relevant parts of the tel URI format defined in
> RFC
> 3966, not least since SDP address types are defined in the context of
> a
> particular network type, and hence RFC 3108 compatibility is not a
> concern (the implication is that the "E164" address type may differ
> between network types in SDP).
>
> *Document Quality
> *
>
> There are currently no known implementations of the draft, however the
> draft is a dependency for 3GPP, so future implementations are
> expected.
>
> The document has received good overall review in the WG, some of which
> resulted in changes to the detailed specification. The document has
> been
> reviewed in detail several times, including of the last few versions.
> The major contributors to these as well as earlier discussions are
> listed in the Acknowledgements section of the document.
>
>
> *Personnel
> *
>
> Document Shepherd: Flemming Andreasen
> Responsible AD: Gonzalo Camarillo
>
>

2013-05-15 13:10 (System)

IANA Review state changed to Version Changed - Review Needed from IANA - Review Needed

2013-05-15 08:34 Gonzalo Camarillo

Placed on agenda for telechat - 2013-05-30

2013-05-15 08:33 Gonzalo Camarillo

State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup

2013-05-15 08:33 Gonzalo Camarillo

Ballot has been issued

2013-05-15 08:33 Gonzalo Camarillo

[Ballot Position Update] New position, Yes, has been recorded for Gonzalo Camarillo

2013-05-15 08:33 Gonzalo Camarillo

Created "Approve" ballot

2013-04-24 23:56 (System)

Sub state has been changed to AD Followup from Revised ID Needed

2013-04-24 23:56 Simo Veikkolainen

New revision available

2013-02-20 00:31 Gonzalo Camarillo

State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead

2013-02-01 00:22 (System)

State changed to Waiting for AD Go-Ahead from In Last Call

2013-01-29 12:05 Pearl Liang

IANA has reviewed draft-ietf-mmusic-sdp-cs-17 and has the following comments:

We have questions about one of the actions requested by the authors of
this document.

We understand that, upon approval of this document, there are five actions which we must complete.

First in the SDP att-field (media level only) subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new SDP attribute will be registered as follows:

Type: att-filed (media level only)
SDP Name: cs-correlation
Reference: [ RFC-to-be ]

Second, a new subregistry is to be created called the "cs-correlation" Attribute Values registry. It will be located in the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

Registration and maintenance in this new registry is done by Specification Required as defined in RFC 5226. There are initial registrations in this new registry as follows:

Value of 'cs-correlation' attribute Reference Description
----------------------------------- ------------- -----------
callerid [ RFC-to-be ] Caller ID
uuie [ RFC-to-be ] User-User
Information Element
dtmf [ RFC-to-be ] Dual-tone Multifrequency

Third, in the nettype subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new SDP nettype will be registered as follows:

Type: nettype
SDP Name: PSTN
Reference: [ RFC-to-be ]

Fourth, in the addrtype subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

two new addrtype values will be registered as follows:

Type: addrtype
SDP Name: E164
Reference: [ RFC-to-be ]

Type:
SDP Name: -
Reference: [ RFC-to-be ]

IANA Question -> the authors request that "The current "addrtype" sub-registry structure does not capture the fact that a given addrtype is defined in the context of a particular "nettype". The sub-registry structure should be to correct that as part of this registration."

Should another column be added to the addrtype registry with entries for "context?" If so, should entries be made for the existing registrations? What should these be? As such, please make the "NOTE to IANA' for revising
the sub-registry (in section 8.3) as action items, rather than "NOTE".

Question -> the document describes the two new addrtype values as
depicted below:

Type SDP Name Reference
---- ------------------ ---------
addrtype E164 [RFCxxxx]
- [RFCxxxx]

Should the term 'addrtype' be added to the 2nd addrtype value '-'?

Is the special character '-' for the 2nd addrtype acceptable in
the registry as per RFc4566? Can AD confirm this?

Fifth, in the proto subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new proto will be registered as follows:

Type: proto
SDP Name: PSTN
Reference: [ RFC-to-be ]

We understand that these five actions are the only ones required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

2013-01-18 07:31 Amy Vezza

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call: (Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)) to Proposed Standard

The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Session Description Protocol (SDP) Extension For Setting Up Audio and
Video Media Streams Over Circuit-Switched Bearers In The Public
Switched Telephone Network (PSTN)'
as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN).

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ballot/

No IPR declarations have been submitted directly on this I-D.

2013-01-18 07:31 Amy Vezza

State changed to In Last Call from Last Call Requested

2013-01-18 00:25 Gonzalo Camarillo

Last call was requested

2013-01-18 00:25 Gonzalo Camarillo

Ballot approval text was generated

2013-01-18 00:25 Gonzalo Camarillo

State changed to Last Call Requested from Publication Requested

2013-01-18 00:24 Gonzalo Camarillo

Ballot writeup was changed

Viewing the last 20 entries. Show full log.