Upload
imtc
View
193
Download
1
Tags:
Embed Size (px)
Citation preview
SIP Parity Ac,vity Group & Video Interoperability Review
1
Charles Eckel ([email protected]) IMTC SIP Parity AG Chair
IMTC AMM 2014: SIP Parity AG & Video Interoperability
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.
2 IMTC AMM 2014: SIP Parity AG & Video Interoperability
Problem Statement
Standards interpreted differently
Solu,ons are compe,,ve
Interoperability is hard
3 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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)
4 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
5 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
6 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
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
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
9 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
10 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
11 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
12 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
13 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
14 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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 Offer4UDPJbased4BFCP44ReJINVITE4with4TCPJbased4BFCP4if4farJend4doesn’t4support4UDPJbased4BFCP4(optional)4
4
Role Based Video Streams (RBVS)
15 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
16 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
17 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
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”
20 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
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
22 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
24 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
25 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
26 IMTC AMM 2014: SIP Parity AG & Video Interoperability
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
27 IMTC AMM 2014: SIP Parity AG & Video Interoperability