Hi,
Your code cannot tell one definite case. I would suggest using the
logging facility to debug/troubleshoot your code.
?Benny
On Tue, Oct 11, 2011 at 6:06 PM, Thomas Martin <tmemail at gmx.de> wrote:
> (... re-posting, the original post doesn't seem to have made it into the list - my apologies, in case of a double-posting)
>
> Hi Benny,
>
> thanks for your response and your hint!
>
>> Hence, you should do connect call's media in on_call_media_state()
>> callback instead.
>
>
> Following this suggestion (as I understood it), I spent the past days shifting things around to achieve the desired result
> - unfortunately, with no success.
> Here is the condensed essence (proof-of-concept model) of the current implementation.
>
> // some initialized globals ...
> bool mergeCalls = false;
> pjsua_call_id activeCallID ? ? ? ? ? ? ?= -1;
> pjsua_call_id holdingCallID ? ? = -1;
>
> // the GUI calls "mergeCallButtonPressed()", while "holdingCallID" had been "pjsua_call_set_hold(holdingCallID, NULL)" and ?"activeCallID" is actually talking:
> void mergeCallButtonPressed()
> {
> ? ? ? ?mergeCalls = true;
> ? ? ? ?pjsua_call_reinvite(holdingCallID, PJ_TRUE, NULL);
> }
>
> // pjsua_call_reinvite then triggers:
> void on_call_media_state(pjsua_call_id callID)
> {
> ? ? ? ?pjsua_call_info callInfo;
> ? ? ? ?pjsua_call_get_info(callID, &callInfo);
>
> ? ? ? ?if (callInfo.media_status == PJSUA_CALL_MEDIA_ACTIVE) { // ? ? ?When media is active, connect call to sound device.
> ? ? ? ? ? ? ? ?pjsua_conf_port_id slotOne = callInfo.conf_slot;
> ? ? ? ? ? ? ? ?pjsua_conf_connect(slotOne, 0);
> ? ? ? ? ? ? ? ?pjsua_conf_connect(0, slotOne);
>
> ? ? ? ? ? ? ? ?if (mergeCalls == true) {
> ? ? ? ? ? ? ? ? ? ? ? ?pjsua_conf_port_id slotTwo = pjsua_call_get_conf_port(activeCallID);
> ? ? ? ? ? ? ? ? ? ? ? ?pjsua_conf_connect(slotOne, slotTwo);
> ? ? ? ? ? ? ? ? ? ? ? ?pjsua_conf_connect(slotTwo, slotOne);
>
> ? ? ? ? ? ? ? ? ? ? ? ?// since the "activeCallID" is already ?talking, its conf_port is already connected to "0" (and vice versa) ...
>
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?activeCallID = callID;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?} else if (callInfo.media_status == PJSUA_CALL_MEDIA_LOCAL_HOLD) {
> ? ? ? ? ? ? ? ?// ? callSuspended(callID);
> ? ? ? ?}
> }
>
> While both remote-parties (activeCallID and holdingCallID) can listen and speak to port "0", they can neither listen nor speak to each other.
>
> What am I missing/misunderstanding?
>
> Again, thank you very much in advance for your help!
>
> Best regards,
>
> Thomas
>
>
> On Oct 6, 2011, at 4:55 , Benny Prijono wrote:
>
>> On Sat, Oct 1, 2011 at 5:46 PM, Thomas Martin <tmemail at gmx.de> wrote:
>>> Hello Everybody,
>>>
>>> I am trying to implement a 3-party-conference by connecting the mediastreams as follows:
>>>
>>> void mergeCalls(int callOne, int callTwo) {
>>>
>>> ? ? ? // make sure that both calls are off-hold
>>> ? ? ? pjsua_call_reinvite(callOne, PJ_TRUE, NULL);
>>> ? ? ? pjsua_call_reinvite(callTwo, PJ_TRUE, NULL);
>>>
>>> ? ? ? // obtaining the media-slots
>>> ? ? ? pjsua_conf_port_id slotOne = pjsua_call_get_conf_port(callOne);
>>> ? ? ? pjsua_conf_port_id slotTwo = pjsua_call_get_conf_port(callTwo);
>>>
>>> ? ? ? // connecting everybody
>>> ? ? ? pjsua_conf_connect(0, slotOne);
>>> ? ? ? pjsua_conf_connect(slotOne, 0);
>>>
>>> ? ? ? pjsua_conf_connect(0, slotTwo);
>>> ? ? ? pjsua_conf_connect(slotTwo, 0);
>>>
>>> ? ? ? pjsua_conf_connect(slotOne, slotTwo);
>>> ? ? ? pjsua_conf_connect(slotTwo, slotOne);
>>> }
>>>
>>
>> The pjsua_conf_connect() above may not be useful, depending on what
>> pjsua_call_reinvite() does. If the re-INVITE recreates the media
>> stream (and most likely it does), your conf connection will be lost,
>> so the pjsua_conf_connect() instructions above are useless.
>>
>> Hence, you should do connect call's media in on_call_media_state()
>> callback instead.
>>
>> Benny
>>
>>
>>
>>> "mergeCalls()" is called, while two calls are connected and either callOne or callTwo is "holding" (as in "pjsua_call_set_hold(callID, NULL)").
>>>
>>> Even though the above code might be a bit of "overkill" (inefficient) with respect to re-inviting both calls and (re-)connecting both calls to "slot 0", this should not really be harmful.
>>>
>>> The Log states:
>>>
>>> 12:07:34.115 ? conference.c ?Port 3 (sip:12345 at provider.com;user=phone) transmitting to port 0 (iPhone IO device)
>>> 12:07:34.115 ? conference.c ?Port 0 (iPhone IO device) transmitting to port 3 (sip:12345 at provider.com;user=phone)
>>>
>>> 12:07:37.677 ? conference.c ?Port 4 (sip:54321 at provider.com) transmitting to port 0 (iPhone IO device)
>>> 12:07:37.677 ? conference.c ?Port 0 (iPhone IO device) transmitting to port 4 (sip:54321 at provider.com)
>>>
>>> 12:07:37.736 ? conference.c ?Port 4 (sip:54321 at provider.com) transmitting to port 3 (sip:12345 at provider.com;user=phone)
>>> 12:07:37.736 ? conference.c ?Port 3 (sip:12345 at provider.com;user=phone) transmitting to port 4 (sip:54321 at provider.com)
>>>
>>> However, the mediastreams do not seem to get merged:
>>>
>>> Port 0 can listen and talk to both, Port 3 and Port 4
>>> but:
>>> Port 3 can listen and talk to Port 0 but NOT to Port 4
>>> Port 4 can listen and talk to Port 0 but NOT to Port 3
>>>
>>> (Port 3 seems to be able to hear Port 4 for a fraction of a second)
>>>
>>> Somewhere, I had read about complications regarding re-pjsua_call_set_hold() and pjsua_call_reinvite() but I can't find the reference anymore.
>>>
>>> Any hints are greatly appreciated!
>>>
>>> Thank you very much in advance.
>>>
>>> Best Regards,
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
