Changes between Version 4 and Version 5 of 3rd_Party_Media

Timestamp:

Mar 15, 2008 5:33:30 PM (16 years ago)

Author:

bennylp

Comment:

--

3rd_Party_Media

@@ -1 +1 @@
 = Integrating Third Party Media Stack with PJSIP =
 
+'''Table of Contents'''
+[[PageOutline(2-3,,inline)]]
+
+----
+
+
 == Introduction ==
 
@@ -6 +12 @@
 
 [[Image(diagram.jpg)]]
+
+'''PJSUA-LIB''':
+ This is a library which integrates all other libraries into very high level API. Due to its nature, it is tightly coupled with all of the libraries.
+
+'''SIP Libraries''':
+ This includes PJSIP core library (pjsip-core), SIP user agent client library (pjsip-ua), and SIP presence and instant messaging library (pjsip-simple).
+
+'''Media Stack''':
+ The media stack is PJMEDIA and PJMEDIA-CODEC.
+
+'''SDP components''':
+ Although the SDP components (message representation, parsing, and SDP offer answer negotiation) is packaged with PJMEDIA, actually it is independent from PJMEDIA and it can be (and has been) used independently from PJMEDIA. This is because although media can be optional for some application (for example, a server), SDP and SDP negotiation are needed by the invite session, so it should be able to use these parts without having to use PJMEDIA.
+
+ In fact in Symbian build system, these SDP parts are packaged on separate static library (as '''pjsdp''' library). On GNU build system, both PJMEDIA and PJSDP libraries are built, although only PJMEDIA is linked with the application since unlike the Symbian build system, the PJMEDIA library here also contains PJSDP parts.
+
 
 ----
@@ -183 +204 @@
 
 To use this approach, you need to do the following (more or less):
- * Create a new library which consists of the following files from PJMEDIA directory (note that on GNU and Symbian build systems, a library containing these files has been provided and it's called {{{pjsdp}}} library):
+ 1. Create a new library which consists of the following files from PJMEDIA directory (note that on GNU and Symbian build systems, a library containing these files has been provided and it's called {{{pjsdp}}} library):
     - errno.c
     - sdp.c
     - sdp_cmp.c
     - sdp_neg.c
- * To create a local SDP for the invite session (either when creating the call or when the invite session needs updated offer or answer), you need to build the SDP manually. You cannot use {{{pjmedia_endpt_create_sdp()}}} function since this function is part of PJMEDIA.
- * To create a media session, you need to manually inspect both local and remote SDP (see ''on_media_update()'' pseudo-code above) and create your media session based on the information in both SDP's.
+ 1. To create a local SDP for the invite session (either when creating the call or when the invite session needs updated offer or answer), you need to build the SDP manually. You cannot use {{{pjmedia_endpt_create_sdp()}}} function since this function is part of PJMEDIA.
+ 1. To create a media session, you need to manually inspect both local and remote SDP (see ''on_media_update()'' pseudo-code above) and create your media session based on the information in both SDP's.
 
 
@@ -206 +227 @@
 
 Steps to use this approach:
- * application needs to link with PJMEDIA library to get the SDP parts and the SDP generation/conversion to media session info functionality.
- * implement a codec factory for each codec that the third party media stack supports. The codec factory is needed to register the codec into codec manager's codec list. Note that only the codec factory needs to be implemented (the ''pjmedia_codec_factory_op'' API); no need to implement the codec operation itself (the ''pjmedia_codec_op'' API). Since we will never create PJMEDIA's stream, the codec will never gets instantiated, so there is no need to implement the codec. Only the codec factory is needed. The operations that need to be implemented in ''pjmedia_codec_factory_op'' are:
+ 1. application needs to link with PJMEDIA library to get the SDP parts and the SDP generation/conversion to media session info functionality.
+ 1. implement a codec factory for each codec that the third party media stack supports. The codec factory is needed to register the codec into codec manager's codec list. Note that only the codec factory needs to be implemented (the ''pjmedia_codec_factory_op'' API); no need to implement the codec operation itself (the ''pjmedia_codec_op'' API), since we will never create PJMEDIA's stream so no ever codec will get instantiated.
+ 1. The operations that need to be implemented in ''pjmedia_codec_factory_op'' are:
   - test_alloc()
   - default_attr()
   - enum_info()
- * create a ''pjmedia_endpt'' instance, and registers each of the codec factories into the codec manager (application can query the codec manager instance from the ''pjmedia_endpt'').
- * the code to create a call or to handle media update event is similar to the generic pseudo-code explained earlier, except that application will replace call to ''pjmedia_session_create()'' with the corresponding function provided by the third party media stack to start the media.
-
-
-=== Integrating Third Party Stack into PJMEDIA ===
-
-This is the most advanced 
-
-Pros:
- * 
-
-Cons:
-
-
-
+ 1. create a ''pjmedia_endpt'' instance, and registers each of the codec factories into the codec manager (application can query the codec manager instance from the ''pjmedia_endpt'').
+ 1. the code to create a call or to handle media update event is similar to the generic pseudo-code explained earlier, except that application will replace call to ''pjmedia_session_create()'' with the corresponding function provided by the third party media stack to start the media.
+
+
+=== Integrating Third Party Media Stack into PJMEDIA ===
+
+The basic idea here is to integrate the third party media stack into PJMEDIA, and since the PJMEDIA API stays the same, we can integrate the result with existing application or higher layer library, including PJSUA-LIB. However, since this involves modifying our code/libraries, this approach is not supported.
+
+We never tried this approach (never had the need!), so we can't quite explain the details on how to accomplish this. Also the details will depend on the capability that is offered by the third party media stack, so it varies. But the rough steps probably look something like these:
+ 1. We probably no longer use PJMEDIA to control the media flow, and if this is the case, we'll need to stop the media from running. Follow [wiki:FAQ#pjsua-lib-perf this article on PJSIP FAQ] on how to manage our own media with PJSUA-LIB.
+ 1. Re-implement ''pjmedia_session_create()'' function in PJMEDIA's {{{session.c}}} with your implementation (that uses the third party media stack). Also re-implement:
+  - pjmedia_session_destroy(): to destroy the media session
+  - pjmedia_session_get_port(): just return a dummy media port. This wouldn't matter since media flow is not running in PJSUA-LIB so the media port will never be used.
+  - pjmedia_session_dial_dtmf(), pjmedia_session_check_dtmf(), pjmedia_session_get_dtmf(), and pjmedia_session_set_dtmf_callback()
+ 1. You'd also probably need to re-implement the UDP media transport. The media transport is needed to get its socket address info (to be advertised in SDP), but it needs to be re-implemented to '''not''' actually bind to the specified socket address (otherwise if your media stack tries to bind to the same address, it will fail).
+
+With these installed, I think you can get PJSUA-LIB up and running. You will however lose '''all''' media functionality in PJSUA-LIB, since the media is not running in PJSUA-LIB, such as:
+ 1. conference bridge
+ 1. file playing recording
+ 1. ICE
+ 1. everything else related to media