[rtcweb] Relaxing SDP O/A rules?

worley@ariadne.com (Dale R. Worley) Wed, 10 October 2012 20:29 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 535E921F859F for <rtcweb@ietfa.amsl.com>; Wed, 10 Oct 2012 13:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ONENSKjD+4Yb for <rtcweb@ietfa.amsl.com>; Wed, 10 Oct 2012 13:29:08 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com []) by ietfa.amsl.com (Postfix) with ESMTP id B31B121F8534 for <rtcweb@ietf.org>; Wed, 10 Oct 2012 13:29:08 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com []) by TheWorld.com (8.14.5/8.14.5) with ESMTP id q9AKSb5X012070 for <rtcweb@ietf.org>; Wed, 10 Oct 2012 16:28:39 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com []) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id q9AKSaiq4339090 for <rtcweb@ietf.org>; Wed, 10 Oct 2012 16:28:37 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id q9AKSaxu4352980; Wed, 10 Oct 2012 16:28:36 -0400 (EDT)
Date: Wed, 10 Oct 2012 16:28:36 -0400
Message-Id: <201210102028.q9AKSaxu4352980@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: rtcweb@ietf.org
Subject: [rtcweb] 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: Wed, 10 Oct 2012 20:29:09 -0000

> From: Roman Shpount [roman@telurix.com]
> 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.

Strictly speaking, if the first answer is sent reliably (presumably in
a reliable provisional response), then the first O/A cycle is finished
and a second can be initiated.  What makes this situation interesting
is that the second O/A cycle can be done before any dialog is
established, that is, while further early dialogs may be created.

If the first answer is not sent reliably, then the B2BUA may not send
another offer without violating the O/A rules -- until a duplicate
answer is sent reliably (presumably in the 200 response).

> 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.

In practice, almost all SIP systems send media from the address/port
they specify in their SDP as the address/port from which they receive
media.  But if you implement RTP filtering or "consent to receive",
that does not help, as before call establishment, a SIP caller can
receive media from addresses/ports that it has not yet received SDP