| 148 | === Subsequent Offer/Answer === |
| 149 | |
| 150 | The invite session provides additional callbacks relating to SDP offer/answer: |
| 151 | * '''on_rx_offer()''': this callback is called when the session has received a new offer from remote, and it needs a local SDP. |
| 152 | * '''on_create_offer()''': this callback is called when the session needs to generate a local offer (for example when it receives incoming re-INVITE without an offer). |
| 153 | |
| 154 | For both of these two callbacks, application MUST provide a local SDP to the invite session. The process of getting local SDP is similar to the one when creating a call/invite session above. |
| 155 | |
| 156 | For a working sample, please see ''pjsua_call_on_rx_offer()'' and ''pjsua_call_on_create_offer()'' functions in {{{pjsua_call.c}}} file of PJSUA-LIB. |
| 157 | |
| 158 | ---- |
| 159 | |
| 160 | == Third Party Integration Strategy == |
| 161 | |
| 162 | We have two approaches on how to integrate your third party media stack with PJSIP: |
| 163 | 1. to completely remove PJMEDIA from application dependency |
| 164 | 1. reuse PJMEDIA's session info |
| 165 | 1. integrating third party stack into PJMEDIA |
| 166 | |
| 167 | Please note than on all approaches, the SDP parts (messaging, parsing, and offer answer negotiation) cannot be excluded from application dependency since SDP is tightly coupled with the invite session (for the reasons explained above). Fortunately the SDP parts are independent from PJMEDIA thus can be taken out from PJMEDIA cleanly. |
| 168 | |
| 169 | Both integration approaches above have their pros and cons which will be discussed below. |
| 170 | |
| 171 | |
| 172 | === Completely Replace PJMEDIA with Third Party Media Stack === |
| 173 | |
| 174 | With this approach, basically we don't link/use PJMEDIA at all. Pros and cons of this approach are: |
| 175 | |
| 176 | Pros: |
| 177 | * the separation is cleaner thus may be easier to understand. Basically application MUST NOT use anything from PJMEDIA except {{{<sdp.h>}}} and {{{<sdp_neg.h>}}} |
| 178 | * using this approach is supported, since it does not require modifications to our codes/libraries. |
| 179 | |
| 180 | Cons: |
| 181 | * This approach can only be used when application uses PJSIP directly (i.e. not PJSUA-LIB), thus it requires significant more efforts to accomplish tasks which otherwise can be done more easily with PJSUA-LIB. But on the positive note, PJSUA-LIB contains ready to use examples on how to do things so one may just need to copy/paste the code into application's code. |
| 182 | * Since we are not allowed to use PJMEDIA's media session info, we need to get the media info directly from the SDP's, and this is tedious! |
| 183 | |
| 184 | To use this approach, you need to do the following (more or less): |
| 185 | * 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): |
| 186 | - errno.c |
| 187 | - sdp.c |
| 188 | - sdp_cmp.c |
| 189 | - sdp_neg.c |
| 190 | * 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. |
| 191 | * 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. |
| 192 | |
| 193 | |
| 194 | === Reusing PJMEDIA's Session Info === |
| 195 | |
| 196 | The idea of this approach is to allow PJMEDIA to deal with SDP for us, since dealing with SDP's manually is quite a tedious operation. With this approach, we can ask PJMEDIA to generate SDP for us (the ''pjmedia_endpt_create_sdp()'' function) based on the capability/codecs that are registered to it, and we can use the ''pjmedia_session_info_from_sdp()'' function to convert local and remote SDP's into the more manageable media session info structure. |
| 197 | |
| 198 | Pros: |
| 199 | * much easier to work with than manipulating SDP's manually |
| 200 | * this approach is supported since it doesn't modify our codes/libraries |
| 201 | |
| 202 | Cos: |
| 203 | * there is a bit of glue code needed to make PJMEDIA works for us. |
| 204 | * it still can only work with PJSIP (and not PJSUA-LIB) |
| 205 | |
| 206 | |
| 207 | Steps to use this approach: |
| 208 | * application needs to link with PJMEDIA library to get the SDP parts and the SDP generation/conversion to media session info functionality. |
| 209 | * 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: |
| 210 | - test_alloc() |
| 211 | - default_attr() |
| 212 | - enum_info() |
| 213 | * 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''). |
| 214 | * 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. |
| 215 | |
| 216 | |
| 217 | === Integrating Third Party Stack into PJMEDIA === |
| 218 | |
| 219 | Pros: |
| 220 | * |
| 221 | |
| 222 | Cons: |
| 223 | |
| 224 | |
| 225 | |