Transcript papers/h325 - Hive

Packetizer
®
A Concept for the Next Generation
Multimedia System (H.325)
Paul E. Jones
H.325 Editor
April 2007
Copyright © 2007
®
Packetizer
My Objective
•
•
•
•
•
•
Improve the user experience
Enable innovative applications
Enable mobility
Enable multimedia
Make it easy to use
Improve productivity
www.packetizer.com
1
®
Packetizer
Evolution of the Telephone
www.packetizer.com
2
®
Packetizer
What VoIP Delivered
• New devices (IP phones and soft phones)
• Convergence of the voice network and the
data network (great!)
• “Fixed phone” mobility (via the IP network)
• Free calls to other VoIP users
• Reduced toll rates around the world
• The user’s perspective: “yet another
telephone”
www.packetizer.com
3
®
Packetizer
We Can Do More
IP networks hold the potential for so much
more functionality than what was possible
before. We should not be content with
merely enabling functionality that was
already possible with the PSTN!
www.packetizer.com
4
®
Packetizer
Imagine…
Making a call and having application
sharing effortlessly available as part of
the conversation
www.packetizer.com
5
®
Packetizer
Imagine…
Making a call and sharing a file with
the other user, simply by right-clicking
and choosing “Send To” and selecting
the person’s name
www.packetizer.com
6
®
Packetizer
Imagine…
Making a call and sending text along with
voice or using video with ease
www.packetizer.com
7
®
Packetizer
Imagine…
Holding a conference call with several
people and sharing slides or using an
electronic whiteboard
www.packetizer.com
8
®
Packetizer
Imagine…
Being able to use your phone to turn any
flat panel LCD screen into your video
display device
www.packetizer.com
9
®
Packetizer
Imagine…
Being able to use your mobile phone to
select movies and watch them on either
your mobile phone or your HD TV, and
even switch between one device or the
other
www.packetizer.com
10
®
Packetizer
Imagine…
Being able to listen to Internet radio using
your phone to select the “channel” and
speakers across the room to play the music
www.packetizer.com
11
®
Packetizer
Imagine…
Being able to use any combination of
hardware devices in a conference
•
•
•
•
www.packetizer.com
Use your mobile “phone” to
control your call
Use your Bluetooth headset or
your desk phone for voice
Use your PC for sending text and
application sharing
Use an LCD display for
displaying video
12
®
Packetizer
Imagine…
A world of interactive, multi-player gaming
that is consistently enabled through a realtime IP-communication system
www.packetizer.com
13
®
Packetizer
Imagine…
Allowing new multimedia applications to
seamlessly integrate into the network,
delivering new innovative real-time
communication functionality
www.packetizer.com
14
®
Packetizer
Realizing the Vision
• We must recognize that “voice” is just one of many realtime applications
• We must logically separate applications from the user’s
network interface device
– The “phone” is a control tool, but may or may not be the user’s
input device or display device
– Applications may be co-resident with the “phone” or they may be
on separate physical devices
• We must define a system that encourages creation of new
services through integration of new applications
• We must make the system as easy to use as possible,
otherwise it will not be utilized
www.packetizer.com
15
®
Packetizer
History of Multimedia Systems
• First Generation Protocol – H.320
– ISDN videoconferencing
• Second Generation Protocols – H.323, SIP
– Focused on videoconferencing on the LAN
(H.323) and voice over the Internet (SIP)
– Roles expanded for both to address
international voice and video transmission,
presence, and instant messaging
www.packetizer.com
16
®
Packetizer
Why a New System?
• Second generation systems are now 11 years old
– Both H.323 and SIP were introduced in 1996
– Neither were focused on application or device enablement
• Second generation systems only scratched the surface of
what is possible with IP communication
• Second generation systems were limited in scope to
(primarily) delivering voice and video service
• Second generation systems are “monolithic” applications
to which adding any new functionality is quite complicated
• QoS, Security, and NAT/FW traversal issues were an
afterthought in second generation systems, and it shows
www.packetizer.com
17
®
Packetizer
H.325: The Third Generation
• Third Generation – H.325 (in development!)
– Focus on applications
– Truly enable multimedia communication
• Multiple applications
• Multiple communication modes
• Multiple devices
– “Any device, Anywhere, Any time”
www.packetizer.com
18
®
Packetizer
Comparison of 2G and 3G
2G – “Monolithic”
3G – “Distributed”
All features offered by the
user’s device are either
integrated into the software or
are integrated through
proprietary interfaces.
Adding any new feature
means upgrading the device.
The user’s device may sport a
few basic applications, but
many applications can be
added through interfaces with
external devices, including
TVs, PCs, PDAs, and so on
www.packetizer.com
19
®
Packetizer
H.325 Will…
• Enable new applications with minimal or no
changes to deployed infrastructure
– New capabilities for users
– New revenue opportunities for service providers
• Enable third-party application developers to add
new functionality to the system
• Truly enable multimedia communication that goes
well beyond just voice and video
• Address QoS, security, and NAT/FW issues from
the outset
www.packetizer.com
20
®
Packetizer
Sample H.325 Applications
•
•
•
•
•
•
•
•
•
•
Traditional voice and video
Whiteboard
File transfer
Application sharing
Text messaging
Video streaming (e.g., IPTV)
Gaming
Multi-user data conferencing
Streaming audio (e.g., “IP radio”)
“Create your own and plug it in”
www.packetizer.com
21
®
Packetizer
H.325 Architectural Components
• “container”
– This is the device that represents the user to the network (e.g., a
desk phone, mobile phone, or softphone application)
• Application Protocol Entities (APEs)
– These are the applications that register with the container to
provide the user with voice, video, and data collaboration
capabilities
• Service Nodes (SNs)
– These are the network entities that enable the container to establish
communication with a remote entity, facilitate NAT/FW traversal,
and provide other network-based services
• Application Servers (AS)
– These are elements in the network that provide various services,
which might include IPTV, interactive gaming, multipoint
conferencing, and so forth
www.packetizer.com
22
®
Packetizer
The “Container”
• Is the primary contact point for the user
• Handles such functions as user and APE registration with the network
• Is responsible for securing the signaling paths between the container
and the network (or remote parties)
• With secured signaling paths, enables APEs to exchange keys for
media encryption
• Knows nothing about the APEs and what they do
• Knows only how to establish a session between two users
• Is the “control point” for the user
–
–
–
–
Set privacy settings
Manage APEs associations
Invoke applications
Move an active application from one device to another (e.g., “move” a
video stream from a mobile device to an HDTV)
www.packetizer.com
23
®
Packetizer
Service Nodes
• Handle user registration and authentication
• Perform address resolution
• Route signaling and media for the container and APEs
(directly or via a service node)
• Facilitate NAT/FW traversal
• Interface with Application Servers
• Provides a point of network control
It is fair to think of “service nodes” as devices
similar to gatekeepers, SIP proxies, SBCs,
TURN servers, and STUN servers
www.packetizer.com
24
®
Packetizer
Application Protocol Entities
• Responsible for providing a particular application
service
– A standard set of applications will be defined
– Third parties can develop new applications and plug
them into the system
• Depends on the “container” for session
establishment
– Register with the “container”, not the network
– The “container” informs the network of the user’s
capabilities
– There is security between the “container” and APEs
www.packetizer.com
25
®
Packetizer
Application Protocol Entities (cont)
• APEs can register with multiple “containers” on multiple
devices
– Enables your PC to be a “container” and your IP phone to be
another “container”, yet both can utilize the whiteboarding
application on your PC
– Enables your mobile phone to serve as the “container”, your
Bluetooth headset serve for voice, and any HD TV screen to serve
to deliver video
• Applications are invoked through user interaction with the
“container”
• A standard “container” and “APE” interface (over a variety
of access types) will enable a wide variety of applications
that are not possible today
www.packetizer.com
26
®
Packetizer
Application Servers
• Network-based application servers that provide service
• Application servers will have “container” logic, as well as
integrated or distributed application functionality
• Service providers will be able to deliver multimedia
services directly to end users via these network-based
servers, including
–
–
–
–
–
–
IPTV
Broadcast IP radio
News transmission
Stock quotes
Voice and video conferencing
Content distribution
www.packetizer.com
27
®
Packetizer
A “Container” and APEs
“share_app”
Standardized interface(s) between
the container and APEs
“voice_app”
Another “Container”, but
not being used as part of
this conference.
“share_app” registered
with both containers.
“Container”
APEs and “containers” may find each other through static
provisioning, technologies like Bluetooth, dynamic service
discovery protocols, etc. The “container” will identify APEs
and allow the user to authorize the relationship.
www.packetizer.com
28
®
Packetizer
Typical Offices
“share_app”
“share_app”
“Container”
“voice_app”
www.packetizer.com
“Container”
“voice_app”
29
®
Packetizer
Home Entertainment Equipment =
Home Conferencing Equipment
“Containers”
Through this interface, the mobile phone now
becomes the user’s tool for selecting video
programming, while the video appears on the TV
Use of the “audio_app”, rather than “voice_app”, is intentional here
www.packetizer.com
“voice_app”
“video_app”
“audio_app”
30
®
Packetizer
Signaling and Media Flows
App1
App2
Container
These might all
be separate
physical devices
Signaling
Media flows
directly between
applications, not
through the
container
Media
Service
Node
A user-network
interface (UNI) is
defined between
the “container” and
the “service node”
Application
signaling goes
from the
application,
through the
container, and to
the service nodes
App1
www.packetizer.com
Container
App2
31
®
Packetizer
Example of Network-based
Streaming Video Service
Audio and Video Streams do not
flow through the phone
Application
Application
Server
Application
Server
Server
Service
Node
www.packetizer.com
32
®
Example of Network-based
Multipoint Data Conferencing
Service
Packetizer
Application
Application
Server
Application
Server
Server
Service
Node
www.packetizer.com
33
®
Packetizer
Initial Thoughts on Signaling
www.packetizer.com
34
®
Packetizer
NOTE!!!
How Might This Be Done?
www.packetizer.com
Please note that the following slides
merely present a possible means of
enabling what was presented and
does not purport to have all of the
problems solved. It is presented for
discussion purposes only
35
®
Packetizer
User Registration
RRQ (
“Paul E. Jones”,
voice_app,
share_app,
…
)
“Container”
registers the
user and
registered
APEs
www.packetizer.com
•
•
•
Signaling similar to H.323 GK or
SIP Registrar
Security will be addressed
NAT/FW Traversal will be addressed
–
RCF (
endpoint_id,
…
)
–
•
The container will perform a “NAT
test” with each APE individually to
determine what kind of NAT is
employed and where the NAT is
located – this will be used to
determine how to handle media later
Any time the address of an APE
changes, it must inform the container
so a “NAT test” can be performed
A user might have multiple
“containers”, so the service node
must have some logic for selecting
one (or multiple) containers to which
to direct “calls”
36
®
Packetizer
APE Registration and Interaction
• Application protocol entities register with the “container” before or
during a conference
• The user selects (perhaps statically) which applications to invoke when
initiating a conference
• Multiple applications may be available to provide similar functionality
• Applications might not be advertised in all cases unless explicitly
invoked (e.g., a particular game may not be advertised every time a
phone call is made)
• Applications may be invoked during a conference to bring to
capabilities into a conference (games, file transfer, application sharing,
etc.)
• Applications may be removed during or outside a conference;
removing an application during a conference would not terminate the
conference – termination of the conference is dependent on termination
of all APEs or the user’s selected list of APEs (e.g., terminating the
“voice_app” might terminate the entire conference)
www.packetizer.com
37
®
Packetizer
Establishing a Conference
• The user uses the container to initiate a call by providing
the destination address (e.g., enter
“[email protected]”)
• The user also selects the desired application (e.g.,
voice_app), but the container will likely be pre-configured
to use a particular APE
• The container then resolves the remote address or it sends
a message to the service node
– This is similar to H.323 or SIP
– The container sends a conference_request primitive to the service
node
• Contains a list of available APEs
• Transmits a channel_request(APE, NAT Info, APE_Capabilities) for
each APE that should be invoked at the outset
www.packetizer.com
38
®
Packetizer
Establishing a Conference (cont)
• The service node forwards the conference_create
to the remote device
• The remote device returns
– A list of channel_accept or channel_reject messages for
each requested APE
– A list of supported APEs
– Each channel_accept will contain (NAT Info,
APE_Capabilities)
• The calling “container” then notifies the local
“voice_app” to initiate communication (as well as
other APEs requested/configured by the user)
www.packetizer.com
39
®
Packetizer
Establishing a Conference (cont)
• The “voice_app” will then send a media_establish primitive through
the APE-container interface, which gets forwarded to the remote end
– IP address and port information will be inside(!)
• Is there any way to avoid this? I do not think so, but let’s make it something
we can deal with
– Service node might intercept this and request the APE to take steps to
open a pin hole through NAT/FW devices, or
– When the voice_app is behind a symmetric NAT, the Service node might
alter media addresses as it prepares to proxy the media flows and also
indicate that it is providing the proxying function, thereby avoiding
proxying through two service nodes (See AVD-3024)
– The service node should not know or care what kind of media is being
transported, but simply that something will be transmitted and/or received
• The remote side accepts the media_establish primitive, providing
addresses which are similarly inspected and treated by a service node
– Note that even “receive only” media flows will require that a PIN hole is
opened if the APE is behind a NAT
www.packetizer.com
40
®
Packetizer
Establishing a Conference (cont)
• Media is now flowing!
– Media flows directly from the APE to the remote APE
(and proxied by a service node only if required)
– Media does not flow from the APE through the
“container” (this is important!)
• We can use a mobile phone to establish audio calls
• We can use a Bluetooth interface to an LCD video screen (TV
or PC) to see application sharing content
• The mobile device merely handles the channel_request and
media_request messages for the APEs
• We do not consume precious wireless bandwidth!
www.packetizer.com
41
®
Packetizer
Application Handover
• Compatible APEs registered with the same container
should allow for “application handover”
– Handover an IPTV stream from a mobile device to a fixed device
(e.g., HD TV)
– Handover an audio stream from an audio device to a phone
– Handover video functionality from a mobile phone to a largescreen TV
• Application handover is not “call transfer”
– The “container” remains the control point
– Application functionality is merely moved from one device to
another
– Easily managed for stateless media flows (e.g., audio and video),
but perhaps application handover might be complicated for
whiteboarding – perhaps one whiteboard may have to “refresh” its
peer after a handover
www.packetizer.com
42
®
Packetizer
Call Flow Diagram
Open NAT
Cone NAT
Container, voice_app
Cone NAT
share_app
Container, voice_app, share_app
conference_create( [email protected], ape_list, channel_requests(APEs, NAT Info, APE caps) )
conference_accept( [email protected], ape_list, channel_accept(APEs, NAT Info, APE caps) )
channel_invoke( channel_id, remote_ape_capabilities, NAT Info )  voice_app
media_establish( media_capability, address_info, NAT Info )  voice_app
open_port_request()
open_port_ack()
media_establish_ack( address_info )
Media is Flowing End-to-End
alerting
Ring!
Container
APE
www.packetizer.com
43
®
Packetizer
Call Flow Diagram (cont)
Open NAT
Cone NAT
Container, voice_app
Cone NAT
share_app
Container, voice_app, share_app
channel_invoke( channel_id, remote_ape_capabilities, NAT Info )  share_app, NAT Info will include address of “NAT assist” device
* open_port_request()
port_open_ack()
media_establish( media_capability, address_info, NAT Info )  share_app
media_establish( media_capability, address_info, NAT Info )  share_app
open_port_request()
open_port_ack()
media_establish_ack( address_info )
media_establish_ack( address_info )
Container
Media is Flowing End-to-End
APE
www.packetizer.com
44
®
Packetizer
Notes On Flows
•
•
Note that it is not necessary to open ports in each direction explicitly when two APEs
are behind the same NAT or behind two Cone NATs, when one NAT is symmetric and
one is Cone, or when any APE is on an Open NAT; refer to AVD-3024
When creating a conference,
–
–
–
•
•
•
Post-dial delay is reduced by determining the NAT type in advance
Do not alert the called user until the conditions are satisfied for alerting the called party (e.g.,
bi-directional media flows are established)
Keep signaling to a minimum, but more importantly, do not introduce several options (e.g., Fast
Connect and H.245 TCS), as more and more options introduce complexity!
To avoid complexity, we really ought to consider using only a single transport type for
all media (e.g., UDP or DCCP) and signaling (again, datagrams or we could establish
permanent TLS connections like H.460.17)
What the container needs to know about applications should be kept to a minimum,
understanding only that an APE “channel” is opened or closed, some arbitrary
capabilities understood only by the APE, etc. The container passes messages blindly
between the APEs.
The service node needs to understand a little more, understanding that an APE wishes to
open a port or an array of ports, what kind of NAT device is present for the two
communicating APEs, etc. The service node must be able to see the contents of the
signaling flows in order to facilitate NAT traversal, but port information could be
provided “in the clear” while other messages that do not carry port information could be
secured end-to-end
www.packetizer.com
45
®
Packetizer
Packetizer
®
www.packetizer.com
46