Re: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)

Christian Groves <Christian.Groves@nteczone.com> Sun, 06 October 2013 10:41 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BEC21F9FC7 for <mmusic@ietfa.amsl.com>; Sun, 6 Oct 2013 03:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hToF8Ppz6lQ9 for <mmusic@ietfa.amsl.com>; Sun, 6 Oct 2013 03:41:31 -0700 (PDT)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id F11D111E80E6 for <mmusic@ietf.org>; Sun, 6 Oct 2013 03:41:19 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApQBAJs9UVJ20Uup/2dsb2JhbAANTIM/wSBKgSmDGQEBAQQBAQE1GxsKARALDgoJFgQEBwkDAgECARUfEQYNAQUCAQEFiAmoJZJrj1EHhCMDmTCSN4FS
Received: from ppp118-209-75-169.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.75.169]) by ipmail07.adl2.internode.on.net with ESMTP; 06 Oct 2013 21:11:17 +1030
Message-ID: <52513E4B.6080006@nteczone.com>
Date: Sun, 06 Oct 2013 21:41:15 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Richard Barnes <rlb@ipv.sx>
References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <CAL02cgTqRsiYcQNeGW3aKKoD5aRM1pz8G9vVuVVqH7KmO3gG=g@mail.gmail.com>
In-Reply-To: <CAL02cgTqRsiYcQNeGW3aKKoD5aRM1pz8G9vVuVVqH7KmO3gG=g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic mailing list <mmusic@ietf.org>
Subject: Re: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Oct 2013 10:41:32 -0000

Hello Richard,

I guess you mean the "ATM" or "PSTN" nettype? If you assume "c=" line 
scopes then in theory there's not an issue. However I'm not aware of any 
other parameters/values in that registry that are duplicated. This 
essential means no other SDP parameter/value is scoped to understand the 
syntax except E164.

Regards, Christian

On 5/10/2013 12:36 AM, Richard Barnes wrote:
> Is this really a conflict?  In the "c=" line, the addrtype is scoped 
> to either the "ATM" or "E164" nettype, so it's clear which one is 
> meant.  I think the only thing to do here is just have both RFC 3108 
> and this document as references in the registry.
>
> --Richard
>
>
> On Thu, Sep 19, 2013 at 8:22 AM, Christian Groves 
> <Christian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com>> 
> wrote:
>
>     FYI, I was looking at the IANA registry for SDP parameters (
>     http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml)
>     and noticed that there was a registration for addrtype E164 linked
>     to this CS draft.
>
>     There's a problem that there's already an addrtype E164 in
>     RFC3108. This earlier usage of E164 should have been registered
>     with IANA but seems to have been missed. To complicate things the
>     format of the RFC3108 E164 addrtype is different to the one in the
>     CS draft.
>
>     I've already raised this with IANA but I thought it would be worth
>     mentioning in MMUSIC.
>
>     Christian
>
>
>
>     On 2/07/2013 4:56 AM, The IESG wrote:
>
>         The IESG has approved the following document:
>         - 'Session Description Protocol (SDP) Extension For Setting
>         Audio and
>             Video Media Streams Over Circuit-Switched Bearers In The
>         Public
>             Switched Telephone Network (PSTN)'
>            (draft-ietf-mmusic-sdp-cs-21.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 Richard Barnes.
>
>         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
>         _______________________________________________
>         mmusic mailing list
>         mmusic@ietf.org <mailto:mmusic@ietf.org>
>         https://www.ietf.org/mailman/listinfo/mmusic
>
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>