[rtcweb] POF-iPAN-PAN

Suhas Nandakumar <suhasietf@gmail.com> Wed, 16 October 2013 00:10 UTC

Return-Path: <suhasietf@gmail.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 EA94621F9FB0 for <rtcweb@ietfa.amsl.com>; Tue, 15 Oct 2013 17:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.949
X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_33=0.6, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BnFGRf5xOKCM for <rtcweb@ietfa.amsl.com>; Tue, 15 Oct 2013 17:10:57 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8319321F9D09 for <rtcweb@ietf.org>; Tue, 15 Oct 2013 17:10:56 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id l12so6304633wiv.1 for <rtcweb@ietf.org>; Tue, 15 Oct 2013 17:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YFBGebjhDiKae5d76r8U1B2YndCvebj1o+vkWHb5zGk=; b=ftK822aYNzkRdDNoNAGxdASKujJiup0X8kdTf+JDmh3F93Vryt5bhdtqJh85cNjBAI ZfwOTSxF5/BQUD3wKW1M0kKRp5jTPUd5SxIBn0H0+EA4oujSyGv1Uru4pfUDbWkmfSgr TlwXIRIt0F6mCHkJajreDF+ThIF3ep8nVWYxalbqBA6DkmN4OJTTkQYFc7bczz2ir4NH JZCNo/iE5yGnTDOSMYPdDp2H7OMkBs5ippQ+e5E/tVcRZ9owOXEJR9NEhBpBcmUK4d/q Oav0eyvpC0o0FCBNzZcOpJpFpvzpQtm63AN/fkv1KeQd1bWiIvK+GOInppyYAgt0arka KbtA==
MIME-Version: 1.0
X-Received: by with SMTP id fb5mr19708107wic.11.1381882255377; Tue, 15 Oct 2013 17:10:55 -0700 (PDT)
Received: by with HTTP; Tue, 15 Oct 2013 17:10:55 -0700 (PDT)
Date: Tue, 15 Oct 2013 17:10:55 -0700
Message-ID: <CAMRcRGStQAr1igiKpvR37hcykBzmSyetaka5wiOYhAe9aqpWjQ@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, Adam Roach <adam@nostrum.com>, Martin Thomson <martin.thomson@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a11c2448ef4086904e8d0881d"
Subject: [rtcweb] POF-iPAN-PAN
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, 16 Oct 2013 00:10:58 -0000

Hi All

   I changed the subject line to extend and discuss some of the issues
raised with POF/PAN and group membership side-effects

There is a new term - iPAN - Interim Partial Answer - that is introduced to
avoid glare.

But before jumping into iPAN, I have included few examples from Adam's
email earlier on what i also feel as the least ambiguous solution while
dealing with group membership when adding new stream under non-glare

*Original SDP*
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4
t=0 0
a=group:LS first second
m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31

If this is the new m=line that needs to be added,
m=video 30004 RTP/AVP 31
*a=context:group:LS: first second*

( so what ever comes after the context is the one we need to match it
against, in this case, it is the entire group line that gets impacted)

So for another interesting example from RFC595)

        a=group:FEC-FR S1 R1
        a=group:FEC-FR S1 S2 R2
        m=video 30000 RTP/AVP 100
        c=IN IP4
        a=rtpmap:100 MP2T/90000
        m=video 30000 RTP/AVP 101
        c=IN IP4
        a=rtpmap:101 MP2T/90000
        m=application 30000 RTP/AVP 110
        c=IN IP4
        a=rtpmap:110 1d-interleaved-parityfec/90000
        a=fmtp:110 L=5; D=10; repair-window=200000
        m=application 30000 RTP/AVP 111
        c=IN IP4
        a=rtpmap:111 1d-interleaved-parityfec/90000
        a=fmtp:111 L=10; D=10; repair-window=400000

Now if i plan to add following m=line using POF

        m=application 30000 RTP/AVP 110
        c=IN IP4
        a=rtpmap:110 1d-interleaved-parityfec/90000
        a=fmtp:110 L=5; D=10; repair-window=200000

  *      a=context:group:FEC-FR S1 S2 S3*

This would ambiguously identifies the membership to be the second
FEC-FR group line

*Glare Situation*

Now moving to the glare situation,

we define iPAN as "partial expected answer for the POF sent by the Offerer."

Let's say   Originally, we had,

a=group:BUNDLE one two





Alice's POF

Add m=line with mid three to BUNDLE


Bob's POF  (at the same time)

Remove m=line with mid=two from BUNDLE

Now neither Alice or Bob can't process each others POF since they are
awaiting PANs for their POFs

To resolve this , we can use iPAN as given below for Alice

 So Alice -->

              Installs iPAN as the answer that is expected for her POF

              Send her POF to Bob

              On receiving Bob's POF process it as new POF/PAN.

              (Since Bob is also following the same steps, he will
eventually respond

                to Alice's POF)

               On receiving PAN from Bob, verify if it is valid

               if invalid, send a new POF with rejected state

               otherwise, you are good to go

    Bob --> Similar set of procedures are performed to resolve glare.

Also to mention, even when Partial Offers are awaiting Partial Answers
for the same m= section, it might not be a glare situation , say for
example, it the m=lines are updated to included/remove sources

   This situation is directionality sensitive and hence not impacted
by glare as such.