Changes between Version 34 and Version 35 of FAQ

Timestamp:

Feb 20, 2008 9:13:56 AM (16 years ago)

Author:

bennylp

Comment:

--

FAQ

@@ -713 +713 @@
 We are currently looking for other design possibilities to make PJSUA-LIB scale better (suggestions are welcome!). In the meantime, perhaps you can use this approach to make the application scale better.
 
-Basically the idea is to manage the in the application, rather than in PJSUA-LIB. Since we manage the media ourselves, we can design the media interconnection to whatever suit the requirements. One possible design is to create one conference bridge for each call, so that each call's media (including anything related to the call, such as WAV files, tone generators, outgoing call leg, etc.) runs on its own thread.
+Basically the idea is to manage the media in the application, rather than in PJSUA-LIB. Since we manage the media ourselves, we can design the media interconnection to whatever suit the requirements. One possible design is to create one conference bridge for each call, so that each call's media (including anything related to the call, such as WAV files, tone generators, outgoing call leg, etc.) runs on its own thread.
 
 Some steps to accomplish this are as follow:
- 1. First thing we should do is to stop the PJSUA-LIB's conference bridge. This can be accomplished by calling [http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__MEDIA.htm#g4b6ffc203b8799f08f072d0921777161 pjsua_set_no_snd_dev()]. With this call, PJSUA-LIB would not connect the conference bridge to any sound devices (including NULL sound device), so basically it would not run.
- 1. Because the main conference bridge is no longer working, we cannot use the usual PJSUA-LIB's API to add media ports (thing such as [http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__MEDIA.htm#g90a2ec9c8516b5ad13b061a46ae1d07a pjsua_player_create()]), since these API adds the media ports to the main bridge, which no longer works of course.
- 1. When a call's media is established (like when the call is CONFIRMED), PJSUA-LIB will still register the call's stream to the main bridge, but we can just ignore this. The main bridge has been stopped, so although the stream is ''registered'' to it, it won't try to retrieve or send any audio to the stream.
+ 1. First thing we should do is to stop the PJSUA-LIB's conference bridge from running. This can be accomplished by calling [http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__MEDIA.htm#g4b6ffc203b8799f08f072d0921777161 pjsua_set_no_snd_dev()]. With this call, PJSUA-LIB would not connect the conference bridge to any sound devices (including NULL sound device), so basically it would not run.
+ 1. Because the main conference bridge is no longer running/working, we cannot use the usual PJSUA-LIB's API to add media ports (functions such as [http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__MEDIA.htm#g90a2ec9c8516b5ad13b061a46ae1d07a pjsua_player_create()]), since these API adds the media ports to the main bridge, which no longer works of course.
+ 1. When a call's media is established (like when the call is CONFIRMED), PJSUA-LIB will still register the call's stream to the main bridge, but we can just ignore this. The main bridge has been stopped, so although the stream is ''registered'' to it, it won't try to retrieve or send any audio frames from/to the stream.
  1. Since we're not using the main bridge anymore, the call's slot number in {{{pjsua_call_info.conf_slot}}} should not be used anymore.
  1. Now that the main bridge has been stopped, we can manage the media ourselves. We can create one conference bridge for each call, and attach it to a master port to make it ''run'':
@@ -751 +751 @@
 }
 }}}
- 1. Add call's media to the conference bridge. Unfortunately call's media is not normally exposed to PJSUA application, so we would need to include {{{<pjsua-lib/pjsua_internal.h>}}} to access it:
-{{{
-#include <pjsua-lib/pjsua_internal.h>
-
-..
-  pjsua_call *call = &pjsua_var.calls[call_id];
-  pjmedia_port *stream;
-
-  pjmedia_session_get_port(call->session, 0, &stream);
-  pjmedia_conf_add_port(cd->conf, cd->pool, stream, NULL, &cd->call_slot);
+ 1. Implement {{{on_stream_created()}}} callback of {{{pjsua_callback}}}. This callback notifies application when a stream has been created and about to be registered to the bridge. We'll use this callback to add the stream's media port to our own conference bridge:
+{{{
+static void on_stream_created(pjsua_call_id call_id, 
+                              pjmedia_session *sess,
+                              unsigned stream_idx, 
+                              pjmedia_port **p_port)
+{
+  pjmedia_conf_add_port(cd->conf, cd->pool, *p_port, NULL, &cd->call_slot);
+}
 }}}
  1. Add other media ports to the conference bridge as necessary.
- 1. Since we're allocating resources for the call, don't forget to release these resources once the call is disconnected:
+ 1. Since stream may be destroyed during a call (for example, when call is put on hold), we need to remove the stream from our conference bridge when the stream is destroyed, otherwise application will crash because the conference bridge tries to retrieve/put audio frames from/to a non-existant stream. This can be done by implementing {{{on_stream_destroyed()}}} callback:
+{{{
+static void on_stream_destroyed(pjsua_call_id call_id,
+                                pjmedia_session *sess, 
+                                unsigned stream_idx)
+{
+  pjmedia_conf_remove_port(cd->conf, &cd->call_slot);
+}
+}}}
+ 1. Finally, don't forget to release the resources when the call is disconnected. 
 {{{
 static void call_media_deinit(pjsua_call_id call_id)