Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hadriel Kaplan <> Fri, 15 March 2013 05:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BF5D21F9195 for <>; Thu, 14 Mar 2013 22:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id irjl16xJsdAg for <>; Thu, 14 Mar 2013 22:38:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C311221F9193 for <>; Thu, 14 Mar 2013 22:38:08 -0700 (PDT)
X-ASG-Debug-ID: 1363325886-03fc217260fae8f0001-mNOVBD
Received: from ( []) by with ESMTP id A9NuMqk69OYhYY1j (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Mar 2013 01:38:06 -0400 (EDT)
Received: from ([]) by ([]) with mapi id 14.02.0283.003; Fri, 15 Mar 2013 01:38:06 -0400
From: Hadriel Kaplan <>
To: "" <>
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-ASG-Orig-Subj: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
Thread-Index: AQHOIT9E3TAO6Xjtq0ONCRsMcgqXQA==
Date: Fri, 15 Mar 2013 05:38:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Start-Time: 1363325886
X-Barracuda-Encrypted: AES128-SHA
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header
Cc: "<>" <>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Mar 2013 05:48:33 -0000

For section 3.1.2, page 9:
  The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

What does that sentence actually mean??  What's a "situation" where an existing mechanism *can* be used?

Does it mean 'ccap' MUST NOT be used if ICE is also used - i.e., they cannot both be in an offer?  
Does it mean 'ccap' MUST NOT be used if it's technically possible to accomplish using ICE, even if the device in question doesn't support ICE?

When is it ok to use a ccap containing an IP4 or IP6 address?


On Mar 13, 2013, at 11:08 AM, wrote:

> Hello,
> We just submitted a new version of the miscellaneous-caps draft, with text that states that if the connection data capability attribute (a=ccap) is used the port number in the resulting SDP MUST be the same as in the original "m=" line, except for PSTN type bearers (when the port number used is 9).
> Regards,
> Simo