[rtcweb] POF-iPAN-PAN

[Suhas Nandakumar <[e-mail]>]

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
situation

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

If this is the new m=line that needs to be added,
m=video 30004 RTP/AVP 31
a=mid:third
*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 233.252.0.1/127
        a=rtpmap:100 MP2T/90000
        a=mid:S1
        m=video 30000 RTP/AVP 101
        c=IN IP4 233.252.0.2/127
        a=rtpmap:101 MP2T/90000
        a=mid:S2
        m=application 30000 RTP/AVP 110
        c=IN IP4 233.252.0.3/127
        a=rtpmap:110 1d-interleaved-parityfec/90000
        a=fmtp:110 L=5; D=10; repair-window=200000
        a=mid:R1
        m=application 30000 RTP/AVP 111
        c=IN IP4 233.252.0.4/127
        a=rtpmap:111 1d-interleaved-parityfec/90000
        a=fmtp:111 L=10; D=10; repair-window=400000
        a=mid:R2


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

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

  *      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

m=****

a=mid:one

m=****

a=mid:two


Alice's POF

Add m=line with mid three to BUNDLE

and

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
(a=ssrcs)

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




Cheers

Suhas