SIP Parity Actvity Group & Video Interoperability Review

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


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)


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


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


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


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


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


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


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


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


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


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


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)


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


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


Token Control Messages


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'

'


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”


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


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


SIP Security Profile


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


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


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


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


Ques,ons


SIP Parity Actvity Group & Video Interoperability Review

Technology

video bandwidth

video media level

audio video imtc amm

bandwidth bandwidth

ce documents sip video

video conferencing deployments

audio level bandwidth

ve interoperability