Hi Benny,
again, thanks for you response!
> Your code cannot tell one definite case. I would suggest using the
> logging facility to debug/troubleshoot your code.
Attached is a (unfortunately rather lengthy) briefly commented log-snippet of a definite case.
While the big picture is understandable, I am unable to grasp the nature of the problem.
I can see two sections (and marked them) that look a bit suspicious - however, they might as well just be right.
It would be very nice, if you could try enlightening me a bit ...
Thank you very much in advance!
Best regards,
Thomas
---------------------------------------------
In the beginning: callID[0] is holding, while callID[1] is talking ...
16:48:01.373 strm0xbf1b74 Start talksprut..
16:48:01.393 strm0xbf1b74 Starting silence
16:48:01.531 strm0xbf1b74 Start talksprut..
// mergeButtonTriggered()
// resumeCall(callID = 0)
16:48:01.619 endpoint Request msg INVITE/cseq=10455 (tdta0xbf9600) created.
16:48:01.620 inv0xbb5664 Sending Request msg INVITE/cseq=10455 (tdta0xbf9600)
16:48:01.620 dlg0xbb5664 Sending Request msg INVITE/cseq=10455 (tdta0xbf9600)
16:48:01.620 tsx0xbe7664 Transaction created for Request msg INVITE/cseq=10454 (tdta0xbf9600)
16:48:01.627 tsx0xbe7664 Sending Request msg INVITE/cseq=10454 (tdta0xbf9600) in state Null
16:48:01.627 sip_resolve.c Target '111.11.79.9:0' type=Unspecified resolved to '111.11.79.9:5060' type=UDP (UDP transport)
16:48:01.628 pjsua_core.c TX 1219 bytes Request msg INVITE/cseq=10454 (tdta0xbf9600) to UDP 111.11.79.9:5060:
INVITE sip:012344444 at 217.116.117.70 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.30:50405;rport;branch=z9hG4bKPjWruk-TFH58hj1RNulwRya1TCnlYitpnt
Max-Forwards: 70
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Contact: <sip:sipid001 at 192.168.178.30:50405;ob>
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10454 INVITE
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Route: <sip:177.77.40.4;lr>
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: SIP020
Content-Type: application/sdp
Content-Length: 432
v=0
o=- 3527592461 3527592465 IN IP4 192.168.178.30
s=pjmedia
c=IN IP4 192.168.178.30
t=0 0
a=X-nat:0
m=audio 4012 RTP/AVP 98 97 99 104 3 0 8 96
a=rtcp:4013 IN IP4 192.168.178.30
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
--end msg--
16:48:01.629 tsx0xbe7664 State changed from Null to Calling, event=TX_MSG
16:48:01.629 dlg0xbb5664 Transaction tsx0xbe7664 state changed to Calling
16:48:01.662 sip_endpoint.c Processing incoming message: Response msg 100/INVITE/cseq=10454 (rdata0xba5a14)
16:48:01.662 pjsua_core.c RX 380 bytes Response msg 100/INVITE/cseq=10454 (rdata0xba5a14) from UDP 111.11.79.9:5060:
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 192.168.178.30:50405;received=78.94.222.222;rport=50405;branch=z9hG4bKPjWruk-TFH58hj1RNulwRya1TCnlYitpnt
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10454 INVITE
Content-Length: 0
--end msg--
16:48:01.662 tsx0xbe7664 Incoming Response msg 100/INVITE/cseq=10454 (rdata0xba5a14) in state Calling
16:48:01.662 tsx0xbe7664 State changed from Calling to Proceeding, event=RX_MSG
16:48:01.662 dlg0xbb5664 Received Response msg 100/INVITE/cseq=10454 (rdata0xba5a14)
16:48:01.662 dlg0xbb5664 Transaction tsx0xbe7664 state changed to Proceeding
16:48:01.663 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=10454 (rdata0xba5a14)
16:48:01.663 pjsua_core.c RX 916 bytes Response msg 200/INVITE/cseq=10454 (rdata0xba5a14) from UDP 111.11.79.9:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.178.30:50405;received=78.94.222.222;rport=50405;branch=z9hG4bKPjWruk-TFH58hj1RNulwRya1TCnlYitpnt
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10454 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:012344444 at 217.116.117.70>
Content-Type: application/sdp
Content-Length: 370
v=0
o=root 1863852319 1863852322 IN IP4 217.116.117.70
s=sipgate VoIP GW
c=IN IP4 111.11.77.24
t=0 0
m=audio 59434 RTP/AVP 8 0 3 104 96
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=nortpproxy:yes
--end msg--
16:48:01.663 tsx0xbe7664 Incoming Response msg 200/INVITE/cseq=10454 (rdata0xba5a14) in state Proceeding
16:48:01.663 tsx0xbe7664 State changed from Proceeding to Terminated, event=RX_MSG
16:48:01.663 dlg0xbb5664 Received Response msg 200/INVITE/cseq=10454 (rdata0xba5a14)
16:48:01.663 dlg0xbb5664 Transaction tsx0xbe7664 state changed to Terminated
16:48:01.702 inv0xbb5664 Got SDP answer in Response msg 200/INVITE/cseq=10454 (rdata0xba5a14)
16:48:01.702 inv0xbb5664 SDP negotiation done, status=0
16:48:01.702 pjsua_call.c Call 0: remote NAT type is 0 (Unknown)
16:48:01.703 strm0xbc8374 JB summary:
size=0 prefetch=0 level=0
delay (min/max/avg/dev)=0/0/0/0 ms
burst (min/max/avg/dev)=0/0/0/0 frames
lost=0 discard=0 empty=0
16:48:01.703 pjsua_media.c Media session for call 0 is destroyed // suspicious ? - If so, what should be done ?
16:48:01.703 strm0xbc8374 VAD temporarily disabled
16:48:01.703 rtp.c pjmedia_rtp_session_init: ses=0xbc9c08, default_pt=8, ssrc=0x5bd8041b
16:48:01.703 rtp.c pjmedia_rtp_session_init: ses=0xbca22c, default_pt=8, ssrc=0x5bd8041b
16:48:01.703 stream.c Stream strm0xbc8374 created
16:48:01.703 strm0xbc8374 Encoder stream started
16:48:01.703 strm0xbc8374 Decoder stream started
16:48:01.703 pjsua_media.c Media updates, stream #0: PCMA (sendrecv)
16:48:01.704 pjsua_call.c Got answer with multiple codecs, scheduling updating media session to use only one codec..
// on_call_media_state() --- reconnecting call[0] to slot[0]
16:48:01.704 conference.c Port 3 (sip:012344444 at provider.net) transmitting to port 0 (iPhone IO device)
16:48:01.704 conference.c Port 0 (iPhone IO device) transmitting to port 3 (sip:012344444 at provider.net)
16:48:01.704 conference.c Port 3 (sip:012344444 at provider.net) transmitting to port 4 (sip:6389979 at provider.net)
16:48:01.704 conference.c Port 4 (sip:6389979 at provider.net) transmitting to port 3 (sip:012344444 at provider.net)
// mergeCalls(callOne = 0 --- callTwo = 1)
16:48:01.714 strm0xbc8374 Jitter buffer empty (prefetch=0), plc invoked
16:48:01.752 strm0xbc8374 Start talksprut..
16:48:01.756 strm0xbc8374 RTP status: badpt=0, badssrc=0, dup=0, outorder=0, probation=-1, restart=0
16:48:01.762 strm0xbf1b74 Jitter buffer empty (prefetch=0), plc invoked
16:48:01.784 strm0xbc8374 Jitter buffer starts returning normal frames (after 3 empty/lost)
16:48:01.807 strm0xbf1b74 jb updated(2), lvl=7 pre=0, size=6
16:48:01.808 strm0xbf1b74 Jitter buffer starts returning normal frames (after 2 empty/lost)
// conference active: callOne = 0 --- callTwo = 1
16:48:01.823 inv0xbb5664 Received Response msg 200/INVITE/cseq=10454 (rdata0xba5a14), sending ACK
16:48:01.823 tdta0xbe2200 Destroying txdata Request msg ACK/cseq=10453 (tdta0xbe2200)
16:48:01.823 endpoint Request msg ACK/cseq=10454 (tdta0xbe2200) created.
16:48:01.824 dlg0xbb5664 Sending Request msg ACK/cseq=10454 (tdta0xbe2200)
16:48:01.824 sip_resolve.c Target '111.11.79.9:0' type=Unspecified resolved to '111.11.79.9:5060' type=UDP (UDP transport)
16:48:01.824 pjsua_core.c TX 502 bytes Request msg ACK/cseq=10454 (tdta0xbe2200) to UDP 111.11.79.9:5060:
ACK sip:012344444 at 217.116.117.70 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.30:50405;rport;branch=z9hG4bKPjNrxXkx-vE9WkWsk.gTlaskYNjTntVOnh
Max-Forwards: 70
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10454 ACK
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Route: <sip:177.77.40.4;lr>
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Content-Length: 0
--end msg--
16:48:01.825 pjsua_call.c Updating media session to use only one codec..
16:48:01.825 endpoint Request msg INVITE/cseq=10456 (tdta0xbbe200) created.
16:48:01.825 inv0xbb5664 Sending Request msg INVITE/cseq=10456 (tdta0xbbe200)
16:48:01.825 dlg0xbb5664 Sending Request msg INVITE/cseq=10456 (tdta0xbbe200)
16:48:01.826 tsx0xbfc064 Transaction created for Request msg INVITE/cseq=10455 (tdta0xbbe200)
16:48:01.826 tsx0xbfc064 Sending Request msg INVITE/cseq=10455 (tdta0xbbe200) in state Null
16:48:01.826 sip_resolve.c Target '111.11.79.9:0' type=Unspecified resolved to '111.11.79.9:5060' type=UDP (UDP transport)
16:48:01.827 pjsua_core.c TX 1021 bytes Request msg INVITE/cseq=10455 (tdta0xbbe200) to UDP 111.11.79.9:5060:
INVITE sip:012344444 at 217.116.117.70 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.30:50405;rport;branch=z9hG4bKPjVp-c2lYbwOlrd1QBOo1TEWyevqKXygdL
Max-Forwards: 70
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Contact: <sip:sipid001 at 192.168.178.30:50405;ob>
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10455 INVITE
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Route: <sip:177.77.40.4;lr>
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 254
v=0
o=- 3527592461 3527592466 IN IP4 192.168.178.30
s=pjmedia
c=IN IP4 192.168.178.30
t=0 0
a=X-nat:0
m=audio 4012 RTP/AVP 8 96
a=rtcp:4013 IN IP4 192.168.178.30
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
--end msg--
16:48:01.828 tsx0xbfc064 State changed from Null to Calling, event=TX_MSG
16:48:01.828 dlg0xbb5664 Transaction tsx0xbfc064 state changed to Calling
16:48:01.828 tsx0xbe7664 Timeout timer event
16:48:01.828 tsx0xbe7664 State changed from Terminated to Destroyed, event=TIMER
16:48:01.828 tdta0xbf9600 Destroying txdata Request msg INVITE/cseq=10454 (tdta0xbf9600)
16:48:01.828 tsx0xbe7664 Transaction destroyed!
16:48:01.877 strm0xbc8374 jb updated(2), lvl=2 pre=0, size=9
16:48:01.884 strm0xbc8374 Discarding frame #1528: eff=8 disc=0 orig:1520 seq_delta:1528
16:48:01.892 sip_endpoint.c Processing incoming message: Response msg 100/INVITE/cseq=10455 (rdata0xba5a14)
16:48:01.892 pjsua_core.c RX 380 bytes Response msg 100/INVITE/cseq=10455 (rdata0xba5a14) from UDP 111.11.79.9:5060:
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 192.168.178.30:50405;received=78.94.222.222;rport=50405;branch=z9hG4bKPjVp-c2lYbwOlrd1QBOo1TEWyevqKXygdL
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10455 INVITE
Content-Length: 0
--end msg--
16:48:01.892 tsx0xbfc064 Incoming Response msg 100/INVITE/cseq=10455 (rdata0xba5a14) in state Calling
16:48:01.892 tsx0xbfc064 State changed from Calling to Proceeding, event=RX_MSG
16:48:01.892 dlg0xbb5664 Received Response msg 100/INVITE/cseq=10455 (rdata0xba5a14)
16:48:01.893 dlg0xbb5664 Transaction tsx0xbfc064 state changed to Proceeding
16:48:01.893 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=10455 (rdata0xba5a14)
16:48:01.893 pjsua_core.c RX 821 bytes Response msg 200/INVITE/cseq=10455 (rdata0xba5a14) from UDP 111.11.79.9:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.178.30:50405;received=78.94.222.222;rport=50405;branch=z9hG4bKPjVp-c2lYbwOlrd1QBOo1TEWyevqKXygdL
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10455 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:012344444 at 217.116.117.70>
Content-Type: application/sdp
Content-Length: 275
v=0
o=root 1863852319 1863852323 IN IP4 217.116.117.70
s=sipgate VoIP GW
c=IN IP4 111.11.77.24
t=0 0
m=audio 59434 RTP/AVP 8 96
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=nortpproxy:yes
--end msg--
16:48:01.893 tsx0xbfc064 Incoming Response msg 200/INVITE/cseq=10455 (rdata0xba5a14) in state Proceeding
16:48:01.893 tsx0xbfc064 State changed from Proceeding to Terminated, event=RX_MSG
16:48:01.893 dlg0xbb5664 Received Response msg 200/INVITE/cseq=10455 (rdata0xba5a14)
16:48:01.893 dlg0xbb5664 Transaction tsx0xbfc064 state changed to Terminated
16:48:01.894 inv0xbb5664 Got SDP answer in Response msg 200/INVITE/cseq=10455 (rdata0xba5a14)
16:48:01.894 inv0xbb5664 SDP negotiation done, status=0
16:48:01.894 pjsua_call.c Call 0: remote NAT type is 0 (Unknown)
16:48:01.933 strm0xbc8374 Discarding frame #1532: eff=11 disc=1 orig:1520 seq_delta:4
16:48:01.934 strm0xbc8374 JB summary:
size=14 prefetch=0 level=2
delay (min/max/avg/dev)=20/100/84/32 ms
burst (min/max/avg/dev)=2/2/2/0 frames
lost=0 discard=2 empty=3
16:48:01.934 pjsua_media.c Media session for call 0 is destroyed
16:48:01.934 strm0xbc8374 VAD temporarily disabled
16:48:01.935 rtp.c pjmedia_rtp_session_init: ses=0xbc9c08, default_pt=8, ssrc=0x5bd8041b
16:48:01.935 rtp.c pjmedia_rtp_session_init: ses=0xbca22c, default_pt=8, ssrc=0x5bd8041b
16:48:01.939 stream.c Stream strm0xbc8374 created
16:48:01.939 strm0xbc8374 Encoder stream started
16:48:01.939 strm0xbc8374 Decoder stream started
16:48:01.940 strm0xbc8374 RTP status: badpt=0, badssrc=0, dup=0, outorder=0, probation=-1, restart=0
16:48:01.940 pjsua_media.c Media updates, stream #0: PCMA (sendrecv)
16:48:01.940 conference.c Port 3 (sip:012344444 at provider.net) transmitting to port 0 (iPhone IO device)
16:48:01.940 conference.c Port 0 (iPhone IO device) transmitting to port 3 (sip:012344444 at provider.net)
// on_call_media_state() --- reconnecting call[0] to slot[0] // how is this triggered again ?
16:48:01.941 inv0xbb5664 Received Response msg 200/INVITE/cseq=10455 (rdata0xba5a14), sending ACK
16:48:01.941 tdta0xbe2200 Destroying txdata Request msg ACK/cseq=10454 (tdta0xbe2200)
16:48:01.942 endpoint Request msg ACK/cseq=10455 (tdta0xbe2200) created.
16:48:01.942 dlg0xbb5664 Sending Request msg ACK/cseq=10455 (tdta0xbe2200)
16:48:01.942 sip_resolve.c Target '111.11.79.9:0' type=Unspecified resolved to '111.11.79.9:5060' type=UDP (UDP transport)
16:48:01.942 pjsua_core.c TX 502 bytes Request msg ACK/cseq=10455 (tdta0xbe2200) to UDP 111.11.79.9:5060:
ACK sip:012344444 at 217.116.117.70 SIP/2.0
Via: SIP/2.0/UDP 192.168.178.30:50405;rport;branch=z9hG4bKPjA2VeGJMoemXdMvFOFhgQSL4opp8Pxdsy
Max-Forwards: 70
From: <sip:004912345555555@xxxxxxxxxxxx>;tag=xWV2lUtDErdDyyhl2DyvHK0FpBMAS0Xv
To: "012344444" <sip:012344444 at provider.net>;tag=as56c24ce6
Call-ID: 0d6a40d52e14364734a610d032684164 at provider.net
CSeq: 10455 ACK
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Route: <sip:177.77.40.4;lr>
Route: <sip:111.11.79.9;lr;ftag=as56c24ce6>
Content-Length: 0
On Oct 12, 2011, at 6:38 , Benny Prijono wrote:
> 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
>>
>
> _______________________________________________
> 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
