Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)

Roman Shpount <> Fri, 12 July 2013 20:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2C1B21F9EDA for <>; Fri, 12 Jul 2013 13:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.856
X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YBAJZMGLufIf for <>; Fri, 12 Jul 2013 13:23:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5762421F9E98 for <>; Fri, 12 Jul 2013 13:23:54 -0700 (PDT)
Received: by with SMTP id y10so963657wgg.0 for <>; Fri, 12 Jul 2013 13:23:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=yXikOyxI/Lek+6A6Aj0AMpU85XB87tCvnHgVA+ZRZhM=; b=MyplBYAGJ5JL4hANcN3At1nPXLom2/u5WZ64v3N95QRpFcBDC/Ga0xIkueIa2hpJGJ VfbBPjjky2jDQpWtpdkeP5/0EuWCD1/yXv+aZVrS9W6GK3U8foh8FzBuqSnmRpGE6pNX WWVyB8+ItvLmFSQgnYKuRZXt6eLcOw+1i6ccafyC5pfB4+Ndk+gZjapTsmA5/F8AeEKn grEUWDzDiLitjzKcwqWbnNsgVvDA66eitfbZkxkia89L4i/qAfVr2pel2dn7q2zWaFbh s6zP6a+S5vsCChNLvBGPMlmlkrbjI7olnhNGXoHOv3J5fwUrGGXWumATd1FyApFHUVqO g7pA==
X-Received: by with SMTP id a16mr2707216wiw.3.1373660629034; Fri, 12 Jul 2013 13:23:49 -0700 (PDT)
Received: from ( [2a00:1450:400c:c03::234]) by with ESMTPSA id b14sm5342898wic.8.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 13:23:48 -0700 (PDT)
Received: by with SMTP id w56so8426740wes.39 for <>; Fri, 12 Jul 2013 13:23:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id x17mr2566568wie.47.1373660626845; Fri, 12 Jul 2013 13:23:46 -0700 (PDT)
Received: by with HTTP; Fri, 12 Jul 2013 13:23:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 12 Jul 2013 16:23:46 -0400
Message-ID: <>
From: Roman Shpount <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="047d7b874000b4895104e15649c5"
X-Gm-Message-State: ALoCoQlNi3TtiuOpA9r6F8fTHPuv+jkwqfIl398Q2RysDj2KTATJAkMCKpdO4S0+y6ivDfHpMkDW
Cc: "Cullen Jennings (fluffy)" <>, "<>" <>
Subject: Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2013 20:24:00 -0000

On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson <>wrote:

> That depends entirely on the nature of the instructions.  Allowing for
> extensibility is always really, really hard, but maybe there is enough
> experience with SDP now that this sort of scenario could be supported.
Unless my past 10 years of experience building SIP systems mislead me, the
current way of dealing with SDP extensibility is to define all features
supported by network or device, go through the interop with every new
network or device you need to connect to, and then, when in doubt, put an
SBC in front of it. We currently need to go through interop testing every
time we setup a new connection with a new VoIP service provider, and this
is for simple PSTN to VoIP G.711+RFC2833 calls. Adding an unusual codec,
like getting a direct interconnect in AMR-WB to cell phone networks, or
SILK to Skype, requires years of testing and still not typically available
commercially. SIP interworking for anything more complex (like even simple
video end points) is virtually non existent. So, I guess, we are building
on a very solid foundation of interprable solutions which require extensive
testing after every sneeze.
Roman Shpount