Transcript Diapositive 1

SIP/RTSP convergence
draft-whitehead-mmusic-sip-for-streaming-media-05
Authors:
Jan Lindquist
Marie-Jose Montpetit
Xavier Marjou
Sam Ganesan
1
Presentation Outline
• Use Cases + possible solutions
–
–
–
–
–
–
Server Control of Streaming Session
Remote Access to Private/Firewalled Video Content
VOD services that requires resource or QOS-guarantees
Intelligent selectionof media encoding
Voice/video mailbox
Motion Detection
• Considerations for session control protocol
2
Use-Case 1:
Server Control of Streaming Session (1/2)
• Need: The server must be able to indicate the end of session to the
client (e.g. if the server needs to be stopped for administrative
purpose).
• Possible solutions:
– Use a SIP BYE message,
– or, add a new RTSP message (eg draft-stiemerling-rtsp-announce-01)
3
Use-Case 1:
Server Control of Streaming Session (2/2)
SIP
Agent A
Media
NAT(B)
Proxy/Reg(B) Relay
Public side
SIP BYE
SIP 200 OK
Agent B
Private side
SIP BYE
SIP 200 OK
4
Use-Case 2:
Remote Access to Private/Firewalled Video Content (1/3)
• Need: to reach the RTSP server located behind a residential NAT
• Possible solutions:
– A SIP/RTSP-like solution helps, as shown on next slide,
– or, Add an RTSP REGISTER message, and extends RTSP proxy.
5
Use-Case 2:
Remote Access to Private/Firewalled Video Content (2/3)
SIP
Agent A
Media
NAT(B)
Proxy/Reg(B) Relay
Public side
Private side
SIP REGISTER (with outbound)
SIP INVITE
m=application 9 TCP/RTSP-like
c=IN IP4 IP-agent-a a=setup:active
TCP SYN
SIP INVITE
m=application 48000 TCP/RTSP-like
c=IN IP4 IP-media-relay
a=setup:passive
TCP SYN
RTSP-like PLAY
RTP Media
Agent B
RTP Media
6
Use-Case 2:
Remote Access to Private/Firewalled Video Content (3/3)
• Note: In the previous slide, an SBC is used for shorter call-flows, but
similar call-flows can be established with ICE instead of SBC so that
media flows go through NATs.
• A SIP/RTSP solution both allows NAT traversal and authentication of
user A.
7
Use-Case 3:
Intelligent selection of media encoding (1/1)
• Need: perform a negotiation between clients and
server on media formats, media codecs and
bandwidth available.
• Possible Solutions
– The SDP offer/answer can be re-used
• Offer/answer enable a media formats negotiation
(add/remove streams for example for SVC)
• Offer/answer enables the "client" to indicate its media
preferences
– Add offer/answer mechanism to RTSP
8
Use-Case 4: VOD services that requires resource or QOSguarantees (1/2)
• Need: establish an end to end session setup and management in
order to control the network resources and QoS
• Possible Solutions
– Use SIP to setup session and use IMS architecture to ensure available
resources and QoS.
9
Use-Case 4:
VOD services that requires resource or QOS-guarantees
(2/2)
SIP
Agent A
Media
Proxy/Reg(B) Relay
Public side
SIP INVITE (SDP offer)
SIP INVITE (SDP offer)
SIP 200 OK (SDP answer)
SIP 200 OK (SDP answer)
RTSP-like PLAY
RTP Media
RTP Media
10
Agent B
Use-Case 5: Voice/video mailbox (1/1)
• Need: establish a session to a mailbox server and perform playback
control of the voice/video messages with the possibility to save or
delete messages. The mailbox can be in the home or in the network.
• Possible Solutions
– Reuse SIP registration to be able to access mailbox in the home and
add some extensions to be able to control individual voice/video
messages.
11
Use-Case 6: Motion Detection (1/4)
• Need: after being informed of motion detection connect to a home
monitoring equipment and see live video feed plus be able to rewind
the video feed.
• Possible Solutions
– Reuse the SIP registration and get notified of motion detected using SIP
message. Then perform SIP invite to establish a connection to the video
feed.
– A SMTP or SIP message with an RTSP link
• does not always work, as shown on next slide.
– or, a SIP with offer/answer solution
12
Use-Case 6 : Motion Detection (2/4)
• A MESSAGE with link does not suffice because of NATs
SIP
Agent A
Media
Proxy/Reg(B) Relay
Public side
NAT(B)
Agent B
Private side
Waiting For Motion events
SMTP or SIP MESSAGE
SMTP or SIP MESSAGE
Event arises
rtsp://IP-Agent-B/stream, or
rtsp://IP-Agent-B-corrected/stream
rtsp://IP-Agent-B/stream
TCP SYN for RTSP
13
Use-Case 6 : Motion Detection (3/4)
SIP
Agent A
Media
Proxy/Reg(B) Relay
NAT(B)
Public side
Agent B
Private side
Waiting Motion events
SIP INVITE
SIP INVITE
Event arises
m=application 9 TCP/RTSP-like
c=IN IP4 IP-agent-a
a=setup:passive
TCP SYN
m=application 48000 TCP/RTSP-like
c=IN IP4 IP-media-relay
a=setup:active
TCP SYN
RTSP-like PLAY
RTP Media
RTP Media
14
Use-Case 6 : Motion Detection (4/4)
• Note: Again an SBC is used for shorter call-flows, but similar callflows can be drawn with ICE instead of SBC in order to that media
flows go through NATs.
15
Considerations for session control
protocol
1.
The session protocol shall allow server initiated control of streaming sessions such as serverinitiated session terminations. RTSP TEARDOWNs are from client to server only.
2.
RTSP protocol assumes a media server is located in the network and not in the home. The
session protocol shall be possible to establish a relationship that allows for control of media
resoruces in both the home and network.
3.
The session protocol shall be able to handle NAT and not affect the call flows being defined.
4.
If assuming SIP for session protocol there is a well accepted architecture defined called IMS,
IP Multimedia Solution, which is accepted by a number of standard organizations like 3GPP, ETSI
TISPAN, ATIS, etc. There is a number of services have been defined using the architecture like
telephony, push to talk, presence, messaging, chat and IPTV.
5.
In conjunction with IMS there is a resource and admition control architecture called RACS
defined in ETSI TISPAN which helps ensure QoS for services defined over IMS and addresses
reuse of network resources. What is of special interest is bandwidth reservation is addressed for
unicast and multicast media streams as well as handling of multicast addresses used for IPTV.
6.
IMS also provides additional authentication mechanisms which allow alternatives for HTTP
Digest like the Authentication and Key Agreement mechanism (AKA).
16