BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

18
BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver

Transcript of BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

Page 1: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

BUNDLE

Christer Holmberg, EricssonHarald Alvestrand, Google

IETF#84, Vancouver

Page 2: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

2

ICEPEER-REFLEXIVE CANDIDATES

Page 3: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

3

USE-CASE

• Alice supports BUNDLE• Bob does not support BUNDLE• Alice and Bob support ICE

• Alice sends offer with identical address:port information for each m- line

• Bob sends answer with different address:port information for each m- line

• Alice and Bob exchange ICE candidate information

Page 4: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

4

USE-CASE

p1

p2

p3

AUDIO

VIDEO

AUDIOVIDEO

ALICE (BUNDLE) BOB

OFFER:m=audio p1candidatesm=video p1candidates

ANSWER:m=audio p2candidatesm=video p3candidates

NOTE: SDP does notcontain peer-reflexivecandidates.

Page 5: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

5

PROBLEM

• Bob sends STUN Connectivity Check (SCC) request to Alice

• Source address:port of SCC is unknown to Alice– Creates PEER-REFLEXIVE CANDIDATE

• Alice does not know from which m- line SCC is sent– SCC does not contain component id, base candidate, etc.

• Not a problem if both Alice and Bob support BUNDLE– SCC will be sent for whole BUNDLE group

Page 6: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

6

SOLUTION

• Alice offers separate ufrag values for each m- line

• SCC contains ufrag– Alice can map SCC to correct m- line

Page 7: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

7

SOLUTION

p1

p2

p3

AUDIO

VIDEO

AUDIOVIDEO

ALICE (BUNDLE) BOB

OFFER:m=audio p1candidatesa=ufrag:xxxm=video p1candidatesa=ufrag:yyy

SCCufrag:yyy

Page 8: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

8

USE-CASE with RTCP-MUX

• Alice includes a=rtcp-mux attribute• Alice includes a=rtcp attribute, with RTP port

value• Bob does not support rtcp-mux– Creates separate ports for RTP and RTCP

• Assume that Bob supports a=rtcp attribute, and can send RTP and RTCP to same port

Page 9: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

9

PROBLEM with RTCP-MUX

• Bob sends STUN Connectivity Check (SCC) request to Alice

• Source address:port of SCC is unknown to Alice– Creates PEER-REFLEXIVE CANDIDATE

• Alice does not know whether SCC is sent for RTP or RTCP– SCC does not contain component id, base candidate, etc.

• Not a problem if both Alice and Bob support rtcp-mux

Page 10: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

10

SOLUTION with RTCP-MUX

• ALT 1: – Use different ufrag values for RTP and RTCP• Connectivity check request contains ufrag

– Q1: How to provide separate ufrag values?• Q2: Allowed, for a given m- line, to include two a=ufrag

attribute instances?• Q2a:Even if, how to indicate which is for RTP and which

is for RTCP?

Page 11: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

11

SOLUTION with RTCP-MUX

• ALT 2: – Use different ports for RTP and RTCP• Unless both Alice and Bob support rtcp-mux

– Alice can still use same RTP port, and same RTCP port, for all m- lines associated with the BUNDLE group• Separate ufrag per m- line

Page 12: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

12

SOLUTION with RTCP-MUX (Alt 2)

RTP

RTCP

RTP

RTCP

RTP

RTCP

AUDIO

VIDEO

AUDIOVIDEO

ALICE (BUNDLE) BOB

Page 13: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

13

SDP RESTRICTIONS

Page 14: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

14

INTRODUCTION

• BUNDLE follows general RFC 3264 rules for SDP offer/answer

• Some restrictions due to usage of identical IP address:port for multiple m- lines– Transport related– RTP session related (single vs multiple RTP sessions)

• RTP session related restrctions outside the scope of this presentation

Page 15: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

15

IDENTICAL INFORMATION

• The following information must be identical in every m- line associated with a BUNDLE group.– Information sharing, or describing, properties of

the 5-tuple transport connection• ICE candidate IP address:port• Transport encryption information

Page 16: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

16

NON-IDENTICAL INFORMATION

• The following information does not need to be identical in every m- line associated with a BUNDLE group.– Media description specific information• Codec/payload type properties• Direction attributes• ICE ufrag• Bandwidth (more about bandwidth on next slide)

Page 17: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

17

BANDWIDTH

• Bandwidth parameters are set as in a non-BUNDLE case

• Total bandwidth for a BUNDLE group: – Sum of all media description specific bandwidth

values of the BUNDLE group• b=AS

Page 18: BUNDLE Christer Holmberg, Ericsson Harald Alvestrand, Google IETF#84, Vancouver.

18

THANK YOU FOR LISTENING!