Hi Benny,
my apologies for sticking to this topic.
Following your advise, I have been trying to solve the puzzle by desperately shifting things around during the last couple of weeks. The log never changes significantly. Obviously, I must be doing something fundamentally wrong - unfortunately, I cannot see what.
Still clueless with respect to the nature of the problem and to the cause of the described symptom, I would be very grateful for one more lead.
Again, thank you very much for helping!
Best regards,
Thomas
On Oct 14, 2011, at 17:57 , Thomas Martin wrote:
> 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
>
>
> _______________________________________________
> 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
