Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Roman Shpount <> Wed, 02 May 2012 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AC7311E809A for <>; Wed, 2 May 2012 14:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.841
X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=0.135, 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 KReoLpuyK2Ie for <>; Wed, 2 May 2012 14:13:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A85EF11E808F for <>; Wed, 2 May 2012 14:13:23 -0700 (PDT)
Received: by dadz9 with SMTP id z9so599345dad.39 for <>; Wed, 02 May 2012 14:13:23 -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=nJqNJJYHx/v1fWSmJevpB262DBuj/5fKugSovQzHUlk=; b=doW28RcNKR6YDs0pPWfqqL0VXgmyEj3YAViNDNsv2A4IDE+uyzm5jPjrn6cBFQTAvd /5U3VWY9jFzWW8lxZTv+1QkyK2QK0FEFGHYHcU3BnheYDQIraRC5HtVN5+EMyPfPCrXj Em2NEMTeeie9zTS1WsrAmPLPk8OP6b5dm5u9cjjAnkVlD4klkq8eWeD3i+qGgdtlsAiS OB/NalhsvJlHSjLulVVHt0TpUZI88p6EoSi7DNxr1a8cZdpXjK2XjKIdM27S0J5uqGCt m/TrLJ9pQixHhA6ZNDCCwWlmFZQMM4bAJkOdCUlxBM9xAQOsZWHSYnzqTX6fhTrULUup cmIQ==
Received: by with SMTP id sd2mr1028594pbc.49.1335993203371; Wed, 02 May 2012 14:13:23 -0700 (PDT)
Received: from ( []) by with ESMTPS id x1sm2988287pbp.50.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 14:13:22 -0700 (PDT)
Received: by dadz9 with SMTP id z9so599297dad.39 for <>; Wed, 02 May 2012 14:13:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id re3mr930168pbc.90.1335993201296; Wed, 02 May 2012 14:13:21 -0700 (PDT)
Received: by with HTTP; Wed, 2 May 2012 14:13:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 02 May 2012 17:13:21 -0400
Message-ID: <>
From: Roman Shpount <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="e89a8ff24a9b2f833304bf14286e"
X-Gm-Message-State: ALoCoQkvx4sPNfczMSjMP+6+ALU3s2DxV689+43bShoTe6haOXwtxrDnz1HOeWPQBWIEclWuzlB4
Cc: "" <>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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: Wed, 02 May 2012 21:13:24 -0000

On Wed, May 2, 2012 at 4:41 PM, Christer Holmberg <> wrote:

> I think that is unlikely to happen, as forking is normally done in a
> serial manner (to avoid other issues associated with parallel forking).

I am not sure why you would say that most forking is serial. It is quite
often parallel. What is commonly done to avoid support for multiple
parallel media streams is playing media from the newest received RTP
stream. In either case there is no guarantee that you picked the winning
stream, and you always need to make sure that you use the SDP received in
the dialog that got 200 OK and that media playback switches to RTP stream
that remains. Making this work is often problematic in SIP since there is
no way to associate received RTP with received SDP information due to RTP
being sent from a different IP/port from the one used in SDP. It should be
easier with WebRTC since ICE support is required and remote party IP/port
can be determined for each flow.

Finally, when you are dealing with forking you need to keep track of the
remote IP/ports and ICE candidates for each dialog. You can play media from
only one of them, but this remote connection state is required to complete
the call setup when 200 OK is received.
Roman Shpount