SIP Parity Actvity Group & Video Interoperability Review Charles Eckel - Technical Leader II, Media Experience and Analytics at Cisco, and the IMTC SIP Parity Activity Group Leader.

1. SIP
Parity
Ac,vity
Group
&
Video
Interoperability
Review
1
Charles
Eckel
(eckelcu@cisco.com)
IMTC
SIP
Parity
AG
Chair
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability

2. What
is
the
IMTC?
• Interna,onal
Mul,media
Telecommunica,ons
Consor,um
• Mission:
Promote
and
facilitate
the
development
and
use
of
interoperable,
real-­‐7me,
mul7media
telecommunica7ons
products
and
services
based
on
open
interna7onal
standards.
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
2

3. Problem
Statement
Standards
interpreted
differently
Solu,ons
are
compe,,ve
Interoperability
is
hard
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
3

4. SIP
Parity
Ac,vity
Group
Focus
• Provide
video
profile
for
SIP
that
matches
capabili,es
of
H.323
– Enable
migra,on
from
H.323
to
SIP
What
We
Do
• Provide
forum
for
members
to
agree
on
best
prac,ces
• Develop
and
advocate
requirements
to
standards
making
organiza,ons
• Organize
and
par,cipate
in
interoperability
tes,ng
events
(e.g.
SuperOp!)
– Par,cipate
in
external
interoperability
events
(e.g.
SIPit)
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
4

5. Best
Prac,ce
Documents
• SIP
Video
Profile
– Extending
SIP
based
audio
telephony
to
accommodate
video
(H.264)
• Role
Based
Video
– Extending
SIP
based
video
conferencing
to
support
content
sharing
(a.k.a.
presenta,on)
• SIP
Security
– Increasing
adop,on
of
secure
signaling
(TLS)
and
media
(SRTP)
in
SIP
based
video
conferencing
deployments
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
5

6. SIP
Video
Profile
• Asymmetric
nego,a,on
– Bandwidth,
Video
Coding
Complexity
• Bandwidth
Indica,ons
-­‐
Session
level
vs.
media
level
• RTP/AVPF
profile
–
SDP
offer/answer
nego,a,on
• Flow
control
-­‐
SDP
vs.
RTCP
feedback
(TMMBR)
• Intra
frame
request
-­‐
SIP
INFO
vs.
RTCP
feedback
(PLI/FIR)
• H.264
–
Recommended
set
of
parameters
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
6

7. Asymmetric
Video
• Receive
higher
bandwidth/resolu,on
than
send
• Bandwidth
in
SDP
(TIAS/AS)
– Declara,ve,
indicates
maximum
“receive”
bandwidth,
NOT
nego,ated
call
bandwidth
– Bandwidth
in
SDP
answer
may
exceed
that
in
SDP
offer
• Video
Coding
Complexity
– Codec
parameters
(e.g.,
profile-­‐level,
max-­‐br,
max-­‐mbps
etc.)
are
“receive”
capability,
NOT
nego,ated
capability
– Level
in
profile-­‐level-­‐id
of
SDP
answer
may
exceed
that
of
SDP
offer
v Not
allowed
by
RFC
3984,
later
allowed
by
RFC
6184
7
High
Def
Std
Def
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability

8. Session
and
Media
Bandwidth
• Offer
mul,ple
audio
codecs
• Bandwidth
varies
per
codec
– E.g.
64
kbps
for
G.711,
8
kbps
for
G.729
• Don’t
waste
bandwidth
by
specifying
maximum
at
audio
level
• Bandwidth
at
video
media
level
same
as
at
session
level
– E.g.
512
kbps
for
session
AND
for
video
m-­‐line,
meaning
video
bandwidth
=
512
kbps
–
(bandwidth
used
for
audio)
8
audio
video
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability

9. Example
(simplified
SDP)
Offer
b=TIAS:256000
m=audio
21000
RTP/AVP
9
8
0
18
m=video
21002
RTP/AVP
96
b=TIAS:256000
a=rtpmap:96
H264/90000
a=fmtp:96
profile-­‐level-­‐id=42801d
Answer
b=TIAS:512000
m=audio
32000
RTP/AVP
0
m=video
32002
RTP/AVP
96
b=TIAS:512000
a=rtpmap:96
H264/90000
a=fmtp:96
profile-­‐level-­‐id=42801f
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
9

10. RTP/AVPF
Profile
Nego,a,on
• Audio/Video
Profile
(AVP),
AVP
with
Feedback
(AVPF)
• Problem:
If
offer
AVFP
and
other
side
does
not
support,
call
fails
• Standards
Solu,on
-­‐
SDP
Capabili,es
Nego,a,on
[RFC
5939]
– But
no
one
implements
• Interoperable
Solu,on-­‐
Implementa,ons
may
specify
profile
as
RTP/AVP
yet
include
RTP/AVPF
amributes
– Violates
RFC
4585
but
needed
for
backward
compa,bility
– Receivers
of
such
signaling
should
be
lenient
in
accep,ng
it
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
10

11. Example
(simplified
SDP)
• m=video
6002
RTP/AVP
96
• b=TIAS:256000
• a=rtpmap:96
H264/90000
• a=fmtp:96
profile-­‐level-­‐id=428014
• a=rtcp-­‐9:*
nack
pli
• a=rtcp-­‐9:*
ccm
tmmbr
• a=rtcp-­‐9:*
ccm
fir
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
11

12. Flow
Control
• Permanent
bandwidth
modifica,on
– State
in
SDP
(e.g.
re-­‐INVITE)
– “b=<bandwidth>”
SDP
amribute
– Middleboxes
able
to
see
change
• Temporary
bitrate
change
– Signal
directly
in
media
path
via
RTCP
feedback
messages
(TMMBR/TMMBN)
[RFC5104]
– Faster
response
than
via
signaling
path
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
12

13. Intra
Frame
Request
• Full
Intra
Request
(FIR)
[RFC
5104]
recommended
• SIP
INFO
[RFC
5168]
for
backward
compa,bility
– Use
if
RTCP
feedback
mechanism
nego,a,on
fails
• Last
resort
-­‐
periodically
send
intra-­‐frame
– Only
if
neither
RTCP
feedback
(FIR)
nor
SIP
INFO
supported
• Picture
Loss
Indica,on
(PLI)
[RFC
4585]
– Requested
to
recover
from
picture
losses
– FIR
only
if
decoder
cannot
recover
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
13

14. H.264
High
Def
Sample
1
m=video
60002
RTP/AVP
96
a=rtpmap:96
H264/90000
a=fmtp:96
profile-­‐level-­‐id=42801f
Sample
2
m=video
60002
RTP/AVP
96
a=rtpmap:96
H264/90000
a=fmtp:96
profile-­‐level-­‐id=428014;
max-­‐fs=3600;
max-­‐mbps=108000
• Many
video
conferencing
implementa,ons
do
not
support
all
capabili,es
of
minimum
profile
required
for
high
defini,on
(HD)
• Instead,
specify
lower
level
but
max-­‐fs
and
max-­‐mbps
necessary
for
HD
• Both
samples
(below)
indicate
ability
to
receive
HD
resolu,on
video
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
14

15. Role
Based
Video
Streams
(RBVS)
Function( H.239( RBVS(“Best(Practices”(Profile(for(SIP(
Designating(Stream(
Roles((section(3)(
h239ExtendedVideoCapability4roleLabel4 RFC447964content4attribute4
Token(Control(
Messages((section(
4.1)(
H.2394Control4&4Indication4messages4 BFCP4
Token(Control(
Channel((section(4.2)(
H.2454 UDPJbased4BFCP4
Offer/Answer(
Exchange((section(5)(
H.2454 Offer4UDPJbased4BFCP44
ReJINVITE4with4TCPJbased4BFCP4if4farJend4
doesn’t4support4UDPJbased4BFCP4
(optional)4
4
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
15

16. Roles
• Video
-­‐
“main”
vs.
“presenta,on”
• RFC
4796
“content”
amribute
• Mapping:
– “slides”
for
H.239
“presenta,on”
– “alt”
for
H.239
“live”
– “main”
for
the
main
video
stream
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
16

17. Example
(simplified
SDP)
• m=video
52886
RTP/AVP
96
• a=rtpmap:96
H264/90000
• a=content:slides
• m=video
53334
RTP/AVP
96
• a=rtpmap:96
H264/90000
• a=content:main
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
17

18. Token
Control
Messages
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
18

19. Token
Control
Channel
–
BFCP/UDP
19
Function( Required(RFC(
Reliable'transport'of'BFCP'messages'over'UDP'
'
draft9sandbakken9dispatch9bfcp9udp' (replaced' by'
rfc4582bis):' Revision' of' the' Binary' Floor' Control'
Protocol'(BFCP)'for'use'over'an'unreliable'transport''
Association'of'control'channel'with'media'channel(s)' RFC'4583'(replaced'by'rfc4583bis)'floor9id'and'label'SDP'
attributes'
Which' endpoint' is' BFCP' server' (token' control'master)'
and'which'is'BFCP'client'(token'control'slave)'
RFC' 4583' (replaced' by' rfc4583bis)' floorctrl' SDP'
attribute'(e.g.'c9only,'s9only)'
Conference'ID'and'User'IDs'
'
RFC' 4583' (replaced' by' rfc4583bis)' confid' and' userid'
SDP'attributes'
'
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability

20. floorctrl
Offer
• If
client
only:
“c-­‐only”
• If
server
only:
“s-­‐only”
• If
can
be
either:
“c-­‐only
s-­‐only”
– Some
implementa,ons
offer
“c-­‐s”,
but
this
is
not
recommended
Answer
• Offer
is
“c-­‐only”:
Answer
“s-­‐only”.
• Offer
is
“s-­‐only”:
Answer
“c-­‐only”.
• Offer
is
“c-­‐only
s-­‐only”:
– If
want
to
be
server,
answer
“s-­‐only”
– If
want
to
be
client,
answer
“c-­‐only”
• Offer
is
“c-­‐s”:
Interpret
as
“c-­‐only
s-­‐only”
– Devia,on
from
RFC
4583,
recommended
because
some
known
implementa,ons
offer
“c-­‐s”
meaning
“c-­‐only
s-­‐only”
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
20

21. Offer/Answer
21
RBVS
endpoint
RBVS
endpoint
Offer
audio,
“main”
video,
and
BFCP/UDP
applica,on
m-­‐line
establishing
floor
for
video
stream
that
has
not
yet
been
offered
Answer
audio,
“main”
video,
and
BFCP/UDP
applica,on
m-­‐line
establishing
floor
for
video
m-­‐line
that
does
not
yet
exist
-­‐-­‐-­‐
Either
side
may
add
second/presenta7on
video
when
needed
-­‐-­‐-­‐
Offer
second
video
m-­‐line
for
“slides”
associated
with
BFCP
floor
established
previously
Answer
second
video
m-­‐line
for
“slides”
associated
with
BFCP
floor
established
previously
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability

22. Example
–
BFCP/UDP
• m=audio
21000
RTP/AVP
0
• m=video
53334
RTP/AVP
96
• a=rtpmap:96
H264/90000
• a=content:main
• a=label:10
• m=video
52886
RTP/AVP
96
• a=rtpmap:96
H264/90000
• a=content:slides
• a=label:11
• m=applica,on
20000
UDP/BFCP
*
• a=floorctrl:
s-­‐only
• a=floorid:1
mstrm:11
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
22

23. SIP
Security
Profile
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
23

24. TLS
Connec,on
Establishment
• Video
conferencing
end
device
MUST
support
TLS
using
"Server
Supplied
Cer,ficates"
model
• Validate
cer,ficate
iden,fies
target
en,ty
to
which
connec,ng
by
checking:
1. subjectAltName
[RFC
5280,
sec,on
4.2.1.6],
if
present,
else,
2. subject
field
[RFC
5280,
sec,on
4.1.2.6],
specifically
the
commonName
(CN)
amribute
• Accept
a
SIP
URI
or
DNS
name
matching
target
en,ty,
or
a
host
name
obtained
by
applying
RFC
3263
procedures
to
that
target
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
24

25. Iden,ty
• Enhancements
for
Authen7cated
Iden7ty
Management
in
SIP
[RFC
4474]
– Provides
means
to
securely
iden,fy
originators
of
SIP
messages
end
to
end
– Lack
of
deployment
and
known
difficul,es
with
signatures
being
invalidated
by
intermediaries
• Instead
rely
on
hop-­‐by-­‐hop
asser,on
of
iden,ty
– MUST
support
SIP
"Asserted
Iden,ty”
as
specified
in
RFC
3325
and
updated
by
RFC
5876
– MAY
use
either
• P-­‐Asserted-­‐Iden,ty
header
(RFC
5876
Sec,on
3.3)
when
sending
request
in
own
trust
domain
• P-­‐Preferred-­‐Iden,ty
header
in
own
trust
domain
if
wish
proxy
insert
P-­‐Asserted-­‐Iden,ty
header
on
endpoint’s
behalf
– MAY
use
privacy
mechanisms
for
P-­‐Asserted-­‐Iden,ty
(RFC
3325
Sec,on
7
and
RFC
5876
Sec,on
4.5)
– MUST
adhere
to
rules
in
RFC
5876
Sec,on
4.5
when
rendering
P-­‐Asserted-­‐Iden,ty
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
25

26. Nego,a,on
of
SRTP
1. Offerer
requires
use
of
SRTP
(will
not
accept
RTP)
– Offer
SAVP
or
SAVPF
in
'proto'
field
of
the
SDP
m=
line
and
include
a=crypto
amribute
2. Offerer
requires
RTP
(will
not
accept
SRTP)
– Offer
AVP
or
AVPF
in
'proto'
field
of
the
SDP
m=
line
and
NOT
include
a=crypto
amribute
3. Offerer
prefers
SRTP
(will
accept
RTP)
– Offer
AVP
or
AVPF
in
'proto'
field
of
the
SDP
m=
line
and
include
a=crypto
aGribute
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
26

27. Example
(simplified
SDP)
Offer
m=video
50004
RTP/AVP
34
97
101
a=crypto:…
Answer
m=video
50014
RTP/AVP
96
a=crypto:…
or
m=video
50104
RTP/AVP
96
• Presence/absence
of
a=crypto
determines
whether
or
not
SRTP
supported
• Be
lenient
when
receiving
answer,
interpre,ng
either
RTP/AVP
with
crypto
(as
shown)
or
RTP/SAVP
with
crypto
as
suppor,ng
SRTP
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
27

28. Ques,ons
IMTC
AMM
2014:
SIP
Parity
AG
&
Video
Interoperability
28