Real-time Multi-user Transcoding For Push To Talk Over Cellular
Upcoming SlideShare
Loading in...5
×
 

Real-time Multi-user Transcoding For Push To Talk Over Cellular

on

  • 630 views

 

Statistics

Views

Total Views
630
Views on SlideShare
629
Embed Views
1

Actions

Likes
0
Downloads
18
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Real-time Multi-user Transcoding For Push To Talk Over Cellular Real-time Multi-user Transcoding For Push To Talk Over Cellular Presentation Transcript

  • Real-time multi-user transcoding for push to talk over cellular (PoC) Stéphane Coulombe
    • Interoperability is hurting wireless multimedia applications:
      • Browsing, MMS, content delivery & sharing, etc
    • Main causes:
      • Different device capabilities and products’ evolution
    • Transcoding is a must:
      • Fixes interoperability issues
      • Enables products’ evolution without ‘breaking’ the service
        • New formats (H.264, etc.), increased bitrate & resolution, etc
    • Situation is not different with PoC
    Why transcoding for PoC?
  • Outline
    • What is PoC?
    • What is the problem?
    • How can we fix it?
    • Conclusions and future work
  • What is PoC?
    • PoC service allows mobile users to create group sessions:
      • Voice and data communications
      • 1-to-1 or 1-to-many sessions
    • PoC service feels like walkie-talkie
      • Dedicated «talk» button
      • Short talk bursts are copied from the one who talks to the others
  • What is PoC?
    • PoC service is built on top of a SIP/IP core (e.g. 3GPP or 3GPP2 IMS)
    • Participating PoC function (PPF)
      • Provides PoC session handling (policy enforcement for PoC sessions)
      • Relays TBC messages between the PoC client and the CPF.
      • May also relay RTP media between the PoC client and the CPF.
    • Controlling PoC function (CPF)
      • Centralized PoC session mgmt:
        • RTP media distribution
          • copies of RTP packets
        • Talk Burst Control (TBC)
          • controls who talks
        • Policy enforcement
          • who can participate
  • What is the problem?
    • Interoperability is again the problem:
      • 3GPP mandates AMR speech codec (+AMR wideband if 16kHz supported)
      • 3GPP2 mandates EVRC speech codec
      • Therefore 3GPP and 3GPP2 terminals won’t be able to communicate
      • More problems will emerge with video and products’ evolution
    • PoC standard (v1.0 and v2.0) mention that transcoding is needed:
      • No means for achieving transcoding is provided
    • PoC v2.0 introduces the PoC Interworking Function
      • It may, among other things, perform transcoding
      • But its realization is outside the scope of the OMA
    • Bottom line: PoC has interoperability issues without a solution
  • What is the problem?
    • Currently, the session setup obviously fails
  • How can we fix it?
    • Issues to address:
      • Control plane adaptation
        • SIP INVITES must reflect transcoding capabilities of the system
      • Media transcoding
        • Media packets must travel through a transcoder when needed
      • Efficiency:
        • We want to minimize the number of transcoding operations
      • Multi-user session support
        • Sessions contains many users
        • Sessions are dynamic (people leave and join, talker changes)
      • Compatibility with existing Terminals
        • The solution must not require any change to mobile terminals
        • The network-side will have to deal with the problem!
  • How can we fix it?
    • Solution 1 : Transcoding distributed among the various PPFs
      • Must be performed at each receiving PPF
      • This is how a back to back user agent (B2BUA) solution would be implemented
      • This is sub-optimal from processing perspective
        • The same transcoding may be replicated more than once (for each user)
  • How can we fix it?
      • Solution 2 : Transcoding centralized at the CPF
      • The CPF has two main responsibilities with respect to enabling transcoding:
      • 1. Manage session control operations:
        • Setup:
          • fix codec incompatibilities,
          • manage transcoding server’s (TS) operations
        • Update: update transcoding operations dynamically
          • Different speaker
          • Users leaving and joining the session
      • 2. Manage the flow of media streams between users:
        • Media streams (RTP packets) have to flow through a TS
  • How can we fix it?
      • Solution 2 : Transcoding centralized at the CPF
      • 1. Manage session control operations: Setup
        • Enhance SIP INVITE’s SDP with codecs supported by the TS
        • Use TS’s IP address and ports in SIP INVITEs for routing
  • How can we fix it?
      • Solution 2 : Transcoding centralized at the CPF
      • 1. Manage session control operations: Setup
  • How can we fix it?
      • Solution 2 : Transcoding centralized at the CPF
    • 1. Manage session control operations: Update
      • TS session must be updated as new members join or leave
      • TS session is updated based on who talks (TS ops + routing)
  • How can we fix it?
      • Solution 2 : Transcoding centralized at the CPF
      • 2. Manage the flow of media streams between users:
        • Manage flow of TBC (who speaks) and speech packets
        • 2 options:
          • All the media packets arrive at the CPF
            • speech packets forwarded to TS, TS transcodes media and returns it to CPF or sends it directly to destination
          • All the media packets arrive at the TS
            • TBC packets forwarded to CPF, processed and returned to TS or sent directly to destination
            • From a scalability and general performance perspective, this option is more efficient
  • How can we fix it?
      • Solution 2 : Transcoding centralized at the CPF
      • 2. Manage the flow of media streams between users:
          • 1. All the media packets arrive at the TS
          • 2. All the media packets arrive at the CPF
  • How can we fix it?
    • There are actually more details to consider which can’t be shown here…
      • Precise modifications to SDP messages
        • Codecs and IP addresses & ports
      • Precise messaging flow and content for:
        • Session setup
        • Session update
        • Request for talking
        • TBC and speech packets
      • Precise operations taking place in the TS
    • More details in the paper and in the references
  • Conclusions and future work
    • We proposed a solution to fix the problem!!!
    • Transparent for all PoC clients
      • Only requires changes to PoC servers
    • Compatible with existing PoC specifications
    • Works for all PoC group session scenarios:
      • 1 to 1, 1 to many, 1 to many to 1, ad hoc, etc.
    • Scalable by offloading work to various TSs
    • Extensible to other SIP/SDP-based real-time multi-party applic.
    • Allows minimization of the processing required for transcoding
      • Can perform transcoding once for many destinations
    • Allows transcoding to be customized for each user
      • Select a distinct AMR bitrate for every PoC client
  • Conclusions and future work
    • Future research topics
      • Investigate a proxy-based transcoding solution
        • not requiring any change to PoC servers or to PoC clients already deployed.
      • Study the problem of optimally selecting TSs in a distributed configuration
        • based on transmission and processing costs over the network.
        • Trade-off between quality and processing cost.
  • Thank you for your attention. Questions?
    • Contact:
    • Stéphane Coulombe  Department of Software and IT Engineering    École de technologie supérieure  Montréal, Canada  Phone : (514) 396-8407  e-mail: stephane.coulombe@etsmtl.ca  
    • The author would like to thank Vantrix (www.vantrix.com) corporation for supporting this research.