Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Justin Uberti <> Mon, 04 November 2013 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0652B11E8114 for <>; Sun, 3 Nov 2013 22:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YECKdZMW12Mj for <>; Sun, 3 Nov 2013 22:55:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::236]) by (Postfix) with ESMTP id A8A9521E80B3 for <>; Sun, 3 Nov 2013 22:55:56 -0800 (PST)
Received: by with SMTP id c14so1144266vea.41 for <>; Sun, 03 Nov 2013 22:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qjgz5bcCsIA+ry5joUHrXQYBj6ohuLUdxVPs7WP55Mg=; b=eUtAXoLykKknogplPvwQUKhcKZvSPaTyVLbm29Nc0+/iPVUpTqJMGhQPDwLABMi0Vd 8qLsGH9xUo3f5fLoxe22kXJpC5roX5+YO9SStkRkL9gEPcdkrPfFXFFE9BZvuRCTyIWU /GOLDa5pO5BIO+6XQh3TwCxKXuhtCgbNFjcCbWCXTD7ZqH5Tf7IjV+CULJ2OWq8X2ZlR aURDBjsCLuomTGORVxp36xdwkHgZ3A3b9W4YutQyjEbSbJDaQrA4DChU0Mq2L0T60prP lU5kydpZiGYyDvrj9K2p4Wif65kVVy1ZwrLPup6vjf/+d7VXSimAUYIxkrZIogkNYet0 0oqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qjgz5bcCsIA+ry5joUHrXQYBj6ohuLUdxVPs7WP55Mg=; b=VkxJjn4UEWlRlrQLWfqqThu6zwLJWANwg29ExlaBF9LtzdK4f5vchg88NEltao8zB+ fkhX1wyUP0jWbuZ55N+zyKJJaqrZsyaSUQBKk2Vh0o60btWtYoriKEsMzMgCDpyLxP3r yMj/+ZGEXSa9m3jESgIlVuLFMVq3P6Viq2k+LseCboMb0XxT4nf8Adag+rrPnGsOKJDZ CBTNvtBd2+rcHcHTGh8F+deca7tVKtdRh2zBaqWWWNmtjOknDx248quaiK02RZCu1CuH gsA3uSCIGhbK/5tQ9N9SAmm6xN87ZCqvGwJIKhq5M+WWGlJvgjH8D67qFlcI9oJmJvab JLEA==
X-Gm-Message-State: ALoCoQlRZQ4zD7oi2QFM1ABktn+rMzIlWkgUz+/REJLe0cyOJ5PN8gVUT0QtR24zKtKvu4S9vUbFlDaGhnUCytn/W0mexMJrck5Weph+1ZeisTtstEbX09m+tXPjM9Xt7AdL4Vo3Tg1tNFUR2LYPVOBpOiV0Sbp+RrnePMAgEVt4HOYAJOQecUJWD8BR8cz6rxAAZeuBiqJi
X-Received: by with SMTP id g5mr35990veh.38.1383548155845; Sun, 03 Nov 2013 22:55:55 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Nov 2013 22:55:35 -0800 (PST)
In-Reply-To: <>
References: <>
From: Justin Uberti <>
Date: Sun, 3 Nov 2013 22:55:35 -0800
Message-ID: <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary=047d7b6786fe5c0b3204ea546837
Cc: "" <>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
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: Mon, 04 Nov 2013 06:55:59 -0000

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <> wrote:

> Section 5.2.2 (Subsequent Offers) says:
>    o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
>       only include codecs present in the remote description.
>    o  The RTP header extensions MUST only include those that are present
>       in the remote description.
>    o  The RTCP feedback extensions MUST only include those that are
>       present in the remote description.
>    o  The "a=rtcp-mux" line MUST only be added if present in the remote
>       description.
>    o  The "a=rtcp-rsize" line MUST only be added if present in the
>       remote description.
> Including only codecs that were present in the prior answer is a bad idea.
> It doesn't play well with SIP. There is no harm in continuing to include
> all the codecs you support. And it keeps options open for changing codecs
> later.
> The same is true for most other things that are being restricted based on
> what was in the last answer. (But I won't say that with certainty without
> checking the semantics of each one.)
> For further info, see RFC 6337, especially section 5.1.

According to section 5.2.5, it seems that this is only the cases for offers
triggered by offerless reINVITEs. I don't think we want to be re-allocating
and negotiating codecs every time we want to make a change to the session
descriptions in use.

Generally I think we should consider that the capabilities of the remote
side will not change unexpectedly during the call, and so full
renegotiation is not needed with each reINVITE. If full renegotiation is
needed, use an INVITE-with-replaces, as Cullen has suggested. This avoids
complicated cases like having to unBUNDLE in mid-call, or re-reserve codecs
that are unlikely to be used.

>         Thanks,
>         Paul
> _______________________________________________
> rtcweb mailing list