Subject: [MMUSIC] Better way to not-really-offer constituent media descriptions

From: [email-masked] (Dale R. Worley)
Date: Wed, 27 Feb 2013 16:56:55 -0500 (EST)

This is a revision of how how constituent MDs are presented in the
offer in draft-worley-sdp-bundle.  Instead of offering them with a
non-zero port and null address (as if they were on-hold in the old
manner), offer them with a real port and address (but only provide ICE
candidates that are already known, and don't allocate a TURN relay).

(The idea that we can have the answerer suppress the constituent MDs
rather than the offerer is taken from
draft-ejzak-mmusic-bundle-alternatives-01.)

        o=- 2890844526 2890844526 IN IP4 host.example.com
        c=IN IP4 10.0.1.1

        a=group:KUMQUAT bundle con1 con2

        m=audio 10002 RTP/AVP 0 8 97
        c=IN IP4 0.0.0.0
        a=mid:con1
        a=rtcp-mux
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:97 iLBC/8000
        a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host

        m=video 10004 RTP/AVP 31 32
        c=IN IP4 0.0.0.0
        a=mid:con2
        a=rtcp-mux
        a=rtpmap:31 H261/90000
        a=rtpmap:32 MPV/90000
        a=candidate:0 1 UDP 2113601791 10.0.1.1 10004 typ host

        m=audio 10000 RTP/AVP 127
        a=mid:bundle
        a=rtcp-mux
        a=rtpmap:127 kumquat
        a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host
        a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \
            raddr 10.0.1.1 rport 10000

If the answerer understands bundling, the answer is as before, with a
non-zero port but a null address for the constituent MDs.  (I assume
that intermediate devices realize that a null address means that it
will see no media on that transport flow.)

           o=- 2890844526 2890844526 IN IP4 answer.example.com
           c=IN IP4 10.0.2.1

           a=group:KUMQUAT bundle con1 con2

           m=audio 9 RTP/AVP 0 8 97
           c=IN IP4 0.0.0.0
           a=mid:con1
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000

           m=video 9 RTP/AVP 31 32
           c=IN IP4 0.0.0.0
           a=mid:con2
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000

           m=audio 20000 RTP/AVP 127
           a=mid:bundle
           a=rtcp-mux
           a=rtpmap:127 kumquat
           a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx \
               raddr 10.0.2.1 rport 20000

If the answerer does not understand bundling, since the offer includes
real transport addresses, there is no risk that answerer wil not see
the constituent MDs as being offered.  The answer now has real
transport address information for the constituent MDs, including full
ICE candidates.  But since the offer didn't include the full ICE
candidates, it's possible that media communications won't be
established.  The offerer will have to update its offer with complete
ICE information, which may require allocating more TURN relays.

Non-supporting answer:

           o=- 2890844526 2890844526 IN IP4 answer.example.com
           c=IN IP4 10.0.2.1

           m=audio 20000 RTP/AVP 0 8 97
           c=IN IP4 10.0.2.1
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000
           a=candidate:0 1 UDP 2113601791 10.0.2.1 20000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.35 51090 typ srflx \
               raddr 10.0.2.1 rport 20000

           m=audio 20002 RTP/AVP 31 32
           c=IN IP4 10.0.2.1
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000
           a=candidate:0 1 UDP 2113601791 10.0.2.1 20002 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.35 51092 typ srflx \
               raddr 10.0.2.1 rport 20002

           m=audio 0 RTP/AVP 127

Updated offer, with further ICE candidates:

           o=- 2890844526 2890844527 IN IP4 host.example.com
           c=IN IP4 10.0.1.1

           m=audio 10000 RTP/AVP 0 8 97
           c=IN IP4 10.0.1.1
           a=mid:con1
           a=rtcp-mux
           a=rtpmap:0 PCMU/8000
           a=rtpmap:8 PCMA/8000
           a=rtpmap:97 iLBC/8000
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10000 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51000 typ srflx \
               raddr 10.0.1.1 rport 10000

           m=video 10002 RTP/AVP 31 32
           c=IN IP4 10.0.1.1
           a=mid:con2
           a=rtcp-mux
           a=rtpmap:31 H261/90000
           a=rtpmap:32 MPV/90000
           a=candidate:0 1 UDP 2113601791 10.0.1.1 10002 typ host
           a=candidate:1 1 UDP 1694194431 198.51.100.32 51002 typ srflx \
               raddr 10.0.1.1 rport 10002

           m=audio 0 RTP/AVP 127
           a=mid:bundle

The updated answer is the same as the first answer.

There also a fast-start alternative where the offerer provides full
ICE candidates for the constituent MDs.  This avoids the delay of
updating the offer when interoperating with a non-supporting answerer
and full ICE candidates are needed, but may require pre-allocating
additional TURN relays.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Feb 2013 06:45:45 +0800

> draft-ejzak-mmusic-bundle-alternatives-01.)
...
> will see no media on that transport flow.)

If an O/A exchange has been concluded and the result is that one end has 
a valid address, and the other end has null (zero/.invalid) address, 
can't that be construed as establishing a oneway media stream where RTCP 
is also oneway?

I don't think this has ever been discussed.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 Feb 2013 14:47:58 -0500 (EST)

> From: Paul Kyzivat <[email-masked]>
> 

Aye, that's true, assuming the old model "null address = on-hold".  So
you'd need an SDP update to clear that up after connecting with a
supporting endpoint.  Although the update wouldn't be needed to get
media flowing.

Dale