Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

Roman Shpount <roman@telurix.com> Fri, 05 October 2012 17:46 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC67621F87C9 for <rtcweb@ietfa.amsl.com>; Fri, 5 Oct 2012 10:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHo-p97J4RTg for <rtcweb@ietfa.amsl.com>; Fri, 5 Oct 2012 10:46:30 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBDAF21F87C1 for <rtcweb@ietf.org>; Fri, 5 Oct 2012 10:46:29 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id ro8so2160002pbb.31 for <rtcweb@ietf.org>; Fri, 05 Oct 2012 10:46:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZmTn0Hnq31UY7BsLS+2RZvBsXmNAgjxWBkwfNHUxeJ4=; b=ePla3lhPz2aOVovLEGIus49hbZsU5ULZWdC6GPIuxKc3Mbn9L+TR4Ii94s41/rDJ7/ x390gfcrjBzd0vOdT5g82grb206zGIS4ylGfHg3+GEfJLBC/clR8k8PcgKZnE1KdCj8T +i3VgwZJgQHqXaGtfOhPlb+00YDUpGHsfTUZT0B15uqxbqUXVM82SJMCy2a2V1mjQEOI KIhXGRSvLwTxq8XT06WJE9Dp43kR4rwmFTkUVW5wpgXSfelD2VrqgP5eM8+n77ZHFXtz +lXCjb9c6CQc7cJrslxhHCvc8P4m6Zd166G+UFAq4kvF96GO4sjXUwIi5vP8CThlkHOl Wx0A==
Received: by 10.68.213.138 with SMTP id ns10mr32460184pbc.157.1349459186032; Fri, 05 Oct 2012 10:46:26 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id f9sm6340134paz.1.2012.10.05.10.46.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 10:46:25 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb11so2090525pad.31 for <rtcweb@ietf.org>; Fri, 05 Oct 2012 10:46:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.73.6 with SMTP id h6mr23311181pav.69.1349459183548; Fri, 05 Oct 2012 10:46:23 -0700 (PDT)
Received: by 10.68.42.8 with HTTP; Fri, 5 Oct 2012 10:46:23 -0700 (PDT)
In-Reply-To: <506F1526.4050306@alvestrand.no>
References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <CABkgnnUFvw_J2+tvVBoHrzR9ZRkPT-6LhXvbaz_U1P7gqtJ4xw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <CABkgnnV6NcTeh=L_fpkpLv5UpkUSuacmQUtYwNKKwAfcb5+JQA@mail.gmail.com> <506D4F7A.5020109@alvestrand.no> <CABkgnnUgHRw4dtihk2fZppmzVWuV4hpvWtXt70N1HWQpJ+KsZw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se> <506F1526.4050306@alvestrand.no>
Date: Fri, 5 Oct 2012 13:46:23 -0400
Message-ID: <CAD5OKxuM_q3CsOQt+huH6o=Yg+XufwhOc8pBxDjux48_AFbmAw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary=f46d042f9f2a4639ea04cb5373d7
X-Gm-Message-State: ALoCoQl9NqyHfdB4bum+NmO00JgMvusKXijpQc6FR6NSQyMBbTLgwIZmNIFd3+WBSh+zChdLfV1F
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2012 17:46:31 -0000

On Fri, Oct 5, 2012 at 1:13 PM, Harald Alvestrand <harald@alvestrand.no>wrote;wrote:

> I've asked that question before, but I don't remember seeing an answer
> from people who know what they're talking about:
>
> Does serial forking, as practiced by SIP UAs, violate the SDP O/A model,
> or does it not violate the SDP O/A model?
>
> I don't understand how it, in the form that has been described as "what we
> have to support", can be SDP O/A compatible, but then there are many things
> about SIP that I don't understand, so I may understand it when it's
> explained to me.
>
>
O/A does not describe multiple answers to a single offer. Nothing
explicitly prohibits it there but I would argue this is not part of this
specification. No standard document that I am aware of describes how serial
O/A is supposed to work. Serial forking as practiced by SIP UA does violate
SIP RFC 3261 which states that each dialog can only have one answer to each
offer. If answer is sent in both provisional and final response, it should
be the same. You can, however, create multiple dialogs with the same offer.
This normally implies parallel forking, but the most common use case is
with early media, where you end up with multiple early dialogs. For
instance you call a phone number, phone network sends you SDP in early
media and plays a dial tone, then the called number does not answer, and
you get connected to a voice mail which uses a completely different SDP in
final answer. According to SIP these answers should come with different
to-tags and technically would be parts of two different dialogs. What makes
this a bit tricky is when the phone network and the voice mail are behind
SBC (or some other sort of B2BUA) you only see one dialog which send you
multiple answers to the same offer. This scenario is so common that it is
more likely to be implemented then parallel forking. This is why PRANSWER
was suggested.

If cloning can be implemented in WebRTC it would be more standard compliant
then PRANSWER and would allow for a lot more use cases. Typical difficulty
in parallel forking implementation in SIP is due to RTP from multiple
sources coming to the same IP and port with no consent or notification to
the receiving side. This makes it very difficult to present this media to
the user. There is no way to tie media to actual dialogs since RTP can come
from different IP and ports then specified in answer SDPs. This is not an
issue with WebRTC where consent to receive media is required. I would argue
let's implement cloning and not waste any more time on PRANSWER which in my
opinion will always stay a half working hack.
_____________
Roman Shpount