Re: [MEDIACTRL] Question about draft-ietf-mediactrl-call-flows: Is "a=ctrl-package" OK?

Eric Burger <eburger@standardstrack.com> Thu, 23 May 2013 14:34 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED48C21F94F9 for <mediactrl@ietfa.amsl.com>; Thu, 23 May 2013 07:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.199
X-Spam-Level:
X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, USER_IN_WHITELIST=-100]
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 TsqsG2ChCN42 for <mediactrl@ietfa.amsl.com>; Thu, 23 May 2013 07:34:37 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9021F9360 for <mediactrl@ietf.org>; Thu, 23 May 2013 07:34:37 -0700 (PDT)
Received: from [141.161.20.235] (port=54021) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1UfWbA-0004sk-0P for mediactrl@ietf.org; Thu, 23 May 2013 07:34:34 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_8C166D60-CFD5-42AC-8727-1A73AF7018AA"; protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <4B4AF630-7824-4676-A54B-12793C58C1E0@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Date: Thu, 23 May 2013 10:34:35 -0400
References: <201305091815.r49IFG0i4424540@shell01.TheWorld.com>
To: "mediactrl@ietf.org list mailing" <mediactrl@ietf.org>
In-Reply-To: <201305091815.r49IFG0i4424540@shell01.TheWorld.com>
X-Mailer: Apple Mail (2.1503)
X-OutGoing-Spam-Status: No, score=-0.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [MEDIACTRL] Question about draft-ietf-mediactrl-call-flows: Is "a=ctrl-package" OK?
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 14:34:42 -0000

This question has been open for two weeks, and the consensus of those responding to the list is unanimous to take out the as of now (or perhaps ever) non-standard SDP usage.

Thank you for your participation in the discussion.

On May 9, 2013, at 2:15 PM, Dale R. Worley <worley@ariadne.com> wrote:

> [as chair]
> 
> We're working on finishing up draft-ietf-mediactrl-call-flows and want
> to get the WG's input on an issue:  Should the example call flows show
> uses of the "a=ctrl-package" attribute in the SDP?
> 
> A typical example is in the SDP in the body of this INVITE to
> establish a CFW connection:
> 
>   To: <sip:MediaServer@ms.example.net:5060>
>   From: <sip:ApplicationServer@as.example.com:5060>;tag=4354ec63
>   Call-ID: MDk2YTk1MDU3YmVkZjgzYTQwYmJlNjE5NTA4ZDQ1OGY.
>   CSeq: 1 INVITE
>   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, REGISTER
>   Content-Type: application/sdp
>   Content-Length: 263
> 
>   v=0
>   o=lminiero 2890844526 2890842807 IN IP4 as.example.com
>   s=MediaCtrl
>   c=IN IP4 as.example.com
>   t=0 0
>   m=application 5757 TCP cfw
>   a=connection:new
>   a=setup:active
>   a=cfw-id:5feb6486792a
>   a=ctrl-package:msc-ivr/1.0
>   a=ctrl-package:msc-mixer/1.0
> 
> Historically, this attribute was defined in
> draft-boulton-mmusic-sdp-control-package-attribute, which was intended
> to proceed to standardization.
> 
> But the effort to standardize "a=ctrl-package" has been abandoned and
> the last version of the draft expired in March 2012.
> 
> But at least one vendor has implemented the attribute.
> 
> Should we keep the "a=ctrl-package" attributes in the SDP examples?
> 
> There are a lot of ways that you can look at this situation:
> 
> - Devices that do not understand "a=ctrl-package" can safely ignore
>  it, so examples containing it are upward-compatible with the
>  standards (and probably with the real world).
> 
> - The official examples should conform to the official standards.
> 
> - If we intend to resume the standardization effort (respinning the
>  draft), it is reasonable to presume its eventual success when
>  writing examples.
> 
> - If enough vendors implement it, it is a de-facto standard and should
>  be shown.
> 
> And then there's the problem that implementors don't properly
> distinguish between the specifications of the standard and the details
> of the examples.  As was once stated vigorously, "The problem is
> people will code implementations to the call flows document, NOT the
> actual RFCs that define the protocols. Our choices are to take it out
> altogether or surround the section with lots of all-capital letters
> saying this may not be in the final specifications and is highly
> likely not to be the way it works in the wild."
> 
> How should we handle this situation?
> 
> Dale
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl