1. Packetizer ® Copyright © 2007 A Concept for the Next Generation Multimedia System (H.325) Paul E. Jones H.325 Editor April 2007

2. www.packetizer.com 1 Packetizer ® My Objective Improve the user experience Enable innovative applications Enable mobility Enable multimedia Make it easy to use Improve productivity

3. www.packetizer.com 2 Packetizer ® Evolution of the Telephone

4. www.packetizer.com 3 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”

5. www.packetizer.com 4 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!

6. www.packetizer.com 5 Packetizer ® Imagine… Making a call and having application sharing effortlessly available as part of the conversation

7. www.packetizer.com 6 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

8. www.packetizer.com 7 Packetizer ® Imagine… Making a call and sending text along with voice or using video with ease

9. www.packetizer.com 8 Packetizer ® Imagine… Holding a conference call with several people and sharing slides or using an electronic whiteboard

10. www.packetizer.com 9 Packetizer ® Imagine… Being able to use your phone to turn any flat panel LCD screen into your video display device

11. www.packetizer.com 10 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

12. www.packetizer.com 11 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

13. www.packetizer.com 12 Packetizer ® Imagine… Being able to use any combination of hardware devices in a conference 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

14. www.packetizer.com 13 Packetizer ® Imagine… A world of interactive, multi-player gaming that is consistently enabled through a real- time IP-communication system

15. www.packetizer.com 14 Packetizer ® Imagine… Allowing new multimedia applications to seamlessly integrate into the network, delivering new innovative real-time communication functionality

16. www.packetizer.com 15 Packetizer ® Realizing the Vision We must recognize that “voice” is just one of many real- time 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

17. www.packetizer.com 16 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

18. www.packetizer.com 17 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

19. www.packetizer.com 18 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”

20. www.packetizer.com 19 Packetizer ® Comparison of 2G and 3G 2G – “Monolithic” 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. 3G – “Distributed” 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

21. www.packetizer.com 20 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

22. www.packetizer.com 21 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”

23. www.packetizer.com 22 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

24. www.packetizer.com 23 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)

25. www.packetizer.com 24 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

26. www.packetizer.com 25 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

27. www.packetizer.com 26 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

28. www.packetizer.com 27 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

29. www.packetizer.com 28 Packetizer ® A “Container” and APEs “Container” “voice_app” Standardized interface(s) between the container and APEs “share_app” 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. Another “Container”, but not being used as part of this conference. “share_app” registered with both containers.

30. www.packetizer.com 29 Packetizer ® Typical Offices “Container” “voice_app” “Container” “voice_app” “share_app”

31. www.packetizer.com 30 Packetizer ® Home Entertainment Equipment = Home Conferencing Equipment “voice_app” “video_app” “audio_app” “Containers” Use of the “audio_app”, rather than “voice_app”, is intentional here Through this interface, the mobile phone now becomes the user’s tool for selecting video programming, while the video appears on the TV

32. www.packetizer.com 31 Packetizer ® Signaling and Media Flows App1 Container App2 Service Node App1 Container App2 Media flows directly between applications, not through the container Application signaling goes from the application, through the container, and to the service nodes Signaling Media These might all be separate physical devices A user-network interface (UNI) is defined between the “container” and the “service node”

33. www.packetizer.com 32 Packetizer ® Example of Network-based Streaming Video Service Service Node Application Server Application Server Application Server Audio and Video Streams do not flow through the phone

34. www.packetizer.com 33 Packetizer ® Example of Network-based Multipoint Data Conferencing Service Application Server Application Server Service Node Application Server

35. www.packetizer.com 34 Packetizer ® Initial Thoughts on Signaling

36. www.packetizer.com 35 Packetizer ® How Might This Be Done? 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 NOTE!!!

37. www.packetizer.com 36 Packetizer ® User Registration RRQ ( “Paul E. Jones”, voice_app, share_app, … ) RCF ( endpoint_id, … ) Signaling similar to H.323 GK or SIP Registrar Security will be addressed NAT/FW Traversal will be addressed –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” “Container” registers the user and registered APEs

38. www.packetizer.com 37 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)

39. www.packetizer.com 38 Packetizer ® Establishing a Conference The user uses the container to initiate a call by providing the destination address (e.g., enter “paulej@packetizer.com”) 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

40. www.packetizer.com 39 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)

41. www.packetizer.com 40 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

42. www.packetizer.com 41 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!

43. www.packetizer.com 42 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 large- screen 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

44. www.packetizer.com 43 Packetizer ® Call Flow Diagram conference_create( paulej@packetizer.com, ape_list, channel_requests(APEs, NAT Info, APE caps) ) conference_accept( plong@packetizer.com, 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 Cone NATOpen NATCone NAT open_port_request() open_port_ack() Media is Flowing End-to-End Container, voice_appshare_appContainer, voice_app, share_app Ring! alerting media_establish_ack( address_info ) Container APE

45. www.packetizer.com 44 Packetizer ® Call Flow Diagram (cont) channel_invoke( channel_id, remote_ape_capabilities, NAT Info )  share_app, NAT Info will include address of “NAT assist” device media_establish( media_capability, address_info, NAT Info )  share_app open_port_request() port_open_ack() Cone NATOpen NATCone NAT Media is Flowing End-to-End open_port_request() open_port_ack() media_establish_ack( address_info ) Container, voice_appshare_appContainer, voice_app, share_app Container APE *

46. www.packetizer.com 45 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

47. www.packetizer.com 46 Packetizer ® ®