Re: [MMUSIC] SCTP-Based Media Transport in SDP

Salvatore Loreto <salvatore.loreto@ericsson.com> Mon, 07 July 2008 08:31 UTC

Return-Path: <mmusic-bounces@ietf.org>
X-Original-To: mmusic-archive@megatron.ietf.org
Delivered-To: ietfarch-mmusic-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777CE28C152; Mon, 7 Jul 2008 01:31:45 -0700 (PDT)
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CA328C154 for <mmusic@core3.amsl.com>; Mon, 7 Jul 2008 01:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level:
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq7+X-oNfQl6 for <mmusic@core3.amsl.com>; Mon, 7 Jul 2008 01:31:43 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 199F128C151 for <mmusic@ietf.org>; Mon, 7 Jul 2008 01:31:43 -0700 (PDT)
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A043E20F87; Mon, 7 Jul 2008 10:31:47 +0200 (CEST)
X-AuditID: c1b4fb3e-ad196bb000004ec0-c5-4871d47371b8
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C8DD20B87; Mon, 7 Jul 2008 10:31:47 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 10:32:30 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 10:32:30 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 582B32461; Mon, 7 Jul 2008 11:31:43 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1D77B4DC75; Mon, 7 Jul 2008 11:31:43 +0300 (EEST)
Received: from n68.nomadiclab.com (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C3F514DB19; Mon, 7 Jul 2008 11:31:42 +0300 (EEST)
Message-ID: <4871D46E.7040902@ericsson.com>
Date: Mon, 07 Jul 2008 11:31:42 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
References: <486CDC37.40606@ericsson.com> <200807031716.47915.remi.denis-courmont@nokia.com>
In-Reply-To: <200807031716.47915.remi.denis-courmont@nokia.com>
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 07 Jul 2008 08:32:30.0670 (UTC) FILETIME=[FEF39EE0:01C8E00B]
X-Brightmail-Tracker: AAAAAA==
Cc: mmusic@ietf.org, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [MMUSIC] SCTP-Based Media Transport in SDP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org

Hi Denis,

thanks for your comments, please see my answer inline below

/Sal

Rémi Denis-Courmont wrote:
> 	Hello,
>
> On Thursday 03 July 2008 17:03:35 ext Salvatore Loreto, you wrote:
>   
>> I'd like start a discussion on the following draft:
>> http://tools.ietf.org/id/draft-loreto-mmusic-sctp-sdp-00.txt
>>
>> The draft describes how to express media transport over SCTP using SDP
>> It also defines the SDP 'SCTP' protocol identifier: the aim to define
>> this identifier is to give the possibility to protocol like SIP to
>> establish a SCTP association other then a TCP connection.
>>     
>
> The use of SCTP in declarative SDP cases seems to be missing. At least, 
> connection:new + setup:passive would seem possible to deal with.
>   
[Sal] exactly we have notice the same, the use of SCTP is missing and we 
are trying to fix it.
actually the SCTP is not the only missing, also DCCP is missing... maybe 
we could fix both at same time.
> Is port 9 reserved for the discard service with SCTP? If not, there might be a 
> small problem with using it blindly in the active case (I have always 
> wondered why COMEDIA does not use the real source port instead of dummy port 
> 9?!).
>   
[Sal] yes it is. as you can read at 
http://tools.ietf.org/html/rfc4960#page-135

      This document registers the following ports.  (These registrations
      should be considered models to follow for future allocation
      requests.)

         discard    9/sctp  Discard  # IETF TSVWG
                                     # Randall Stewart <rrs@cisco.com>
                                     # [RFC4960 <http://tools.ietf.org/html/rfc4960>]

            The discard service, which accepts SCTP connections on port
            9, discards all incoming application data and sends no data
            in response.  Thus, SCTP's discard port is analogous to
            TCP's discard port, and might be used to check the health
            of an SCTP stack.

so even I agree with you that should be better use the real source port 
instead of dummy port 9,
we do not need to change the behavior for SCTP.

> Finally, is it legal or not to put a different address in the c= field of a 
> connection reuse offer, considering SCTP multi-homing capabilities?
>   
[Sal] It is not possible to *reuse* a media description putting a 
different address in the c= field;
in fact  according to RFC 3264 section 8.3.1 to modify an Address, Port 
or Transport, the offerer
have to create a new media description. In the case of Address 
modification the connection line must to be update.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic