I'd recommend just looking at the conference.c code. The ports are
general purpose, however port 0 is always the master sound interface or
the null sound device which provides clocking to the whole mechanism.
Everything runs off of the put_frame call when port 0 need a frame to
output. The code iterates through all the ports and reads the input
samples for each port, then runs through the ports producing mixed
output samples depending on the connections, and transmits the mixed
results to the ports, then returns the mixed results to port 0. It's
something like that, going from memory.
In your case 84 packets are sent which is less than your WAV file
contains, but definitely better than 0. The fact it sent some packets
means the call is connected to an audio producing port, could be WAV
player or sound device. How to debug? Wireshark as I mentioned earlier
would let you know if those packets contain snippets of audio from your
WAV file. Or run pjsua without call but just connect port 0 to port 0
and verify that audio loops from microphone to speaker. Or connect WAV
to port 0 and see if it plays to speaker. Or add PJ_LOG to WAV player to
log individual writes. Lots of options.
Bill
On 11/6/2014 12:55 PM, Brunner, Brian T. wrote:
> Is there any clear documentation describing which conference bridge
> slot does what?
> Is there any debug setting by which I can tell whether the SplashTone
> file is being read and routed to the callers' conference bridge slot?
> From my reading the documentation, "somebody" must be putting frames
> on the file side, and getting frames on the callers' side, in order
> for the audio data to get to the phone.
> I don't have a "somebody()" routine, is pjsua/pjmedia (supposedly)
> doing this?
> There are only a few rtp packets originating from my side.
> Media Stats:
> [DISCONNCTD] To: "aa2" <sip:5 at 192.168.1.254>;tag=be69e5f44p
> Call time: 00h:00m:06s, 1st res in 25 ms, conn in 130ms
> #0 audio PCMU @8kHz, sendrecv, peer=192.168.1.141:11834
> SRTP status: Not active Crypto-suite:
> RX pt=0, last update:00h:00m:04.558s ago
> total 237pkt 37.9KB (47.4KB +IP hdr) @avg=45.0Kbps/56.3Kbps
> pkt loss=0 (0.0%), discrd=0 (0.0%), dup=0 (0.0%), reord=0 (0.0%)
> (msec) min avg max last dev
> loss period: 0.000 0.000 0.000 0.000 0.000
> jitter : 0.000 0.366 3.375 0.125 0.635
> TX pt=0, ptime=20, last update:never
> total 84pkt 13.4KB (16.8KB +IP hdr) @avg=15.9Kbps/19.9Kbps
> pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
> (msec) min avg max last dev
> loss period: 0.000 0.000 0.000 0.000 0.000
> jitter : 0.000 0.000 0.000 0.000 0.000
> RTT msec : 0.000 0.000 0.000 0.000 0.000
> and
> strm0x73d0fc8c .......JB summary:
> size=50/eff=50 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=424 empty=84
>
> I'm guessing this means I never sent a single buffer of audio to the
> caller.
>
> I'll try the audio editor method to determine whether the caller sent
> voice data.
>
> No data was written to the .wav file
>
> ------------------------------------------------------------------------
> *From:* pjsip [pjsip-bounces at lists.pjsip.org] on behalf of Bill
> Gardner [billg at wavearts.com]
> *Sent:* Friday, October 31, 2014 5:02 PM
> *To:* pjsip at lists.pjsip.org
> *Subject:* Re: [pjsip] How to play a "splash-tone" file as soon as
> posssible in the call sequence
>
> Some ideas. Using wireshark you can dump the RTP contents of that
> stream from .141 and convert it to raw PCMU (using some rtp utils from
> columbia, can't remember name) and then import raw pcmu into a sound
> editor to play. There may be an easier way too but that's how I've
> done it. That could be revealing.
>
> The 7 sec duration is due to a call timer expiring. When call ends the
> media stats dump is very useful to see but it isn't in your log, maybe
> you need to increase log level.
>
> Your WAV is 48k stereo, I assume 16-bits. Should be fine as pjsip
> converts automatically. You might want to try converting it to 16k
> mono 16-bit just to be sure the WAV format isn't the issue.
>
> That's all I've got.
>
> Bill
>
>
> On 10/31/2014 3:58 PM, Brunner, Brian T. wrote:
>> <quote>Next step: capture wireshark trace and see if media is sent on
>> RTP?</quote>
>> Good call: According to WireShark, RTP is between my target (.229)
>> and the ip-pbx box (.141, which is my gateway to the caller).
>> The first several RTP packets go both ways, then it's from ip-pbx only.
>>
>> No. Time Source Destination Protocol Length Info
>> 579 28.662739000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20333, Time=160, Mark
>>
>> Frame 579: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 580 28.673127000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20334, Time=320
>>
>> Frame 580: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 581 28.683403000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20335, Time=480
>>
>> Frame 581: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 582 28.693534000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20336, Time=640
>>
>> Frame 582: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 583 28.703727000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20337, Time=800
>>
>> Frame 583: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 584 28.704927000 ip-pbx.bigman.com 192.168.1.229
>> SIP 610 Request: ACK sip:173 at 192.168.1.229:5060 |
>>
>> Frame 584: 610 bytes on wire (4880 bits), 610 bytes captured (4880
>> bits) on interface 0
>> Ethernet II, Src: Dell_1e:d1:21 (00:24:e8:1e:d1:21), Dst:
>> Congatec_0f:f5:6b (00:13:95:0f:f5:6b)
>> Internet Protocol Version 4, Src: ip-pbx.bigman.com (192.168.1.141),
>> Dst: 192.168.1.229 (192.168.1.229)
>> User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
>> Session Initiation Protocol (ACK)
>>
>> No. Time Source Destination Protocol Length Info
>> 588 28.718298000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20338, Time=960
>>
>> Frame 588: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 591 28.731045000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20339, Time=1120
>>
>> Frame 591: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 592 28.752129000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20340, Time=1280
>>
>> Frame 592: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 597 28.766290000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20341, Time=1440
>>
>> Frame 597: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 598 28.771482000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20342, Time=1600
>>
>> Frame 598: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 599 28.776671000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20343, Time=1760
>>
>> Frame 599: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 600 28.781771000 192.168.1.229 ip-pbx.bigman.com RTP
>> 214 PT=ITU-T G.711 PCMU, SSRC=0x138B2423, Seq=20344, Time=1920
>>
>> Frame 600: 214 bytes on wire (1712 bits), 214 bytes captured (1712
>> bits) on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: terabase (4000), Dst Port: 11432
>> (11432)
>> Real-Time Transport Protocol
>>
>> No. Time Source Destination Protocol Length Info
>> 613 30.407229000 192.168.1.229 ip-pbx.bigman.com UDP
>> 60 Source port: sip Destination port: sip
>>
>> Frame 613: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
>> on interface 0
>> Ethernet II, Src: Congatec_0f:f5:6b (00:13:95:0f:f5:6b), Dst:
>> Dell_1e:d1:21 (00:24:e8:1e:d1:21)
>> Internet Protocol Version 4, Src: 192.168.1.229 (192.168.1.229), Dst:
>> ip-pbx.bigman.com (192.168.1.141)
>> User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
>> Data (2 bytes)
>>
>> NOTE: after 1.74 seconds of bi-directional RTP, (from 28.66 seconds
>> to 30.40 seconds) RTP from .229 to ip-pbx ceases, and all further RTP
>> is only from ip-pbx to .229.
>> RTP messages come from ip-pbx every 20ms except for a 190ms silence
>> at the end of the 229->141 RTP.
>> There is one RTCP message from .229 at 30.77
>> The whole conversation ends 7 seconds after it starts when .229 sends
>> BYE as it is supposed to.
>>
>> NOTE: The "PleaseLeaveYourMessage.wav" file is 14MB, lasting 80
>> seconds. I don't hear any of it.
>> ------------------------------------------------------------------------
>> *From:* pjsip [pjsip-bounces at lists.pjsip.org] on behalf of Bill
>> Gardner [billg at wavearts.com]
>> *Sent:* Friday, October 31, 2014 10:10 AM
>> *To:* pjsip at lists.pjsip.org
>> *Subject:* Re: [pjsip] How to play a "splash-tone" file as soon as
>> posssible in the call sequence
>>
>> The audio device, while in this case is not used to playback or
>> record, is used to clock media flow. You could alternatively set up
>> pjsip to use the null-audio device which is just a timer. In your log
>> I see the audio device is initialized OK:
>>
>> 15:45:40.528 pjsua_aud.c .......Opening sound device PCM at 16000/1/20ms
>> 15:45:40.537 pa_dev.c ........Opened device
>> imx6q-qmx6-sgtl5000: (hw:0,0)(ALSA)/imx6q-qmx6-sgtl5000:
>> (hw:0,0)(ALSA) for recording and playback, sample rate=16000, ch=1,
>> bits=16, 320 samples per frame, input latency=100 ms, output
>> latency=140 ms
>>
>> And after call connects the player is started:
>>
>> 15:45:40.549 pa_dev.c !Recorder thread started
>> 15:45:40.554 os_core_unix.c Info: possibly re-registering existing
>> thread
>> 15:45:40.554 pa_dev.c !Player thread started
>> 15:45:40.560 strm0x7570fc8c Start talksprut..
>>
>> If memory serves, "Start talksprut..." indicates the voice detector
>> has detected voice onset, so this indicates signal is flowing. It all
>> looks good.
>> Next step: capture wireshark trace and see if media is sent on RTP?
>>
>> Bill
>>
>>
>>
>> On 10/31/2014 9:01 AM, Brunner, Brian T. wrote:
>>> Logfile: 703 lines/35K attached.
>>> There is no "audio device" involved, as wav file fed from my hard
>>> drive to the Conference Bridge port should be transmitted to the
>>> VoIP phone on the other end.
>>> Which "Initialization" elements do you want to see?
>>>
>>> ------------------------------------------------------------------------
>>> *From:* pjsip [pjsip-bounces at lists.pjsip.org] on behalf of Bill
>>> Gardner [billg at wavearts.com]
>>> *Sent:* Thursday, October 30, 2014 5:18 PM
>>> *To:* pjsip at lists.pjsip.org
>>> *Subject:* Re: [pjsip] How to play a "splash-tone" file as soon as
>>> posssible in the call sequence
>>>
>>> Right, well I asked for the code and I got it, so I'd better
>>> respond. I can see you're answering the call and connecting the
>>> player, so those parts look correct, but it's hard to know if you
>>> are missing something important in initialization. Do you have a
>>> logfile for the auto-answer call? It should show whether the call is
>>> properly connected and may have clues as to why the player isn't
>>> playing. For example, there may be a problem with audio device that
>>> is preventing media flow.
>>>
>>> Bill
>>>
>>> On 10/30/2014 4:49 PM, Brunner, Brian T. wrote:
>>>> Whilst studying the pjproject-2.2.1/pjsip-apps/src/pjsua files for
>>>> how to cause a "PleaseLeaveYourMessage auto-play to happen, a few
>>>> things:
>>>> 1: my app (running on ARM7) receives my test call from a company
>>>> digital phone via a gateway; this should make no difference.
>>>> You asked for example code; after applying what I could grasp
>>>> from the auto-play example, here's what I think should work but
>>>> doesn't (with lots trimmed out)
>>>> if ((status = pjsua_create()) != PJ_SUCCESS) SleepForever("Can't
>>>> create PJSUA, is it already running?",status);
>>>> if ((status = pjsua_verify_url(LV.MyURI)) != PJ_SUCCESS)
>>>> SleepForever("Fix your bad URI, Doofus!",status);
>>>> if ((status = pjsua_init(&ep_cfg, &ep_logging_cfg, NULL)) !=
>>>> PJ_SUCCESS) SleepForever("Error in pjsua_init()", status);
>>>> if ((status = pjsip_endpt_register_module(pjsua_get_pjsip_endpt(),
>>>> &mod_default_handler)) != PJ_SUCCESS) SleepForever("Can't register
>>>> Endpoint", status);
>>>> if ((status = pjsua_player_create(&LV.PleaseLeaveYourMessage,
>>>> PJMEDIA_FILE_NO_LOOP, &LV.Player_id)) != PJ_SUCCESS)
>>>> SleepForever("Can't create SplashPlayer",status);
>>>> LV.PlayerConferencePortNo = pjsua_player_get_conf_port(LV.Player_id);
>>>> pjsua_player_get_port(LV.Player_id, &LV.SplashPort);
>>>> if ((status = pjmedia_wav_player_set_eof_cb(LV.SplashPort, NULL,
>>>> &on_playfile_done)) != PJ_SUCCESS) SleepForever("Can't set eof
>>>> cb",status);
>>>> if ((status = pjsua_transport_create(PJSIP_TRANSPORT_UDP, &tcfg,
>>>> NULL)) != PJ_SUCCESS) SleepForever("Can't create transport, bad
>>>> config data?",status);
>>>> if ((status = pjsua_acc_add(&acct_cfg, PJ_TRUE, &LV.MyAcctId)) !=
>>>> PJ_SUCCESS) SleepForever("Can't create account (you are a
>>>> no-account!)",status);
>>>> if ((status = pjsua_start()) != PJ_SUCCESS) SleepForever("Can't
>>>> start pjsua. Need more chocolate?",status);
>>>>
>>>> The callbacks that appear to matter (with lots trimmed out, you
>>>> don't want to read a book):
>>>> void cb_on_incoming_call(pjsua_acc_id acc_id, pjsua_call_id
>>>> call_id, pjsip_rx_data *rdata)
>>>> {
>>>> pjsua_call_answer(call_id, 200, NULL, NULL);
>>>> }
>>>> static void cb_on_call_media_state(pjsua_call_id call_id)
>>>> {
>>>> pjsua_call_info CallInfo; pjsua_call_get_info(call_id, &CallInfo);
>>>> unsigned MediaIndex; for (MediaIndex = 0; MediaIndex <
>>>> CallInfo.media_cnt;MediaIndex++)
>>>> {
>>>> switch (CallInfo.media[MediaIndex].type)
>>>> {
>>>> case PJMEDIA_TYPE_AUDIO:
>>>> pjsua_conf_connect(LV.PlayerConferencePortNo,
>>>> CallInfo.media[MediaIndex].stream.aud.conf_slot);
>>>> }
>>>> }
>>>> }
>>>>
>>>> Then I pick up my phone, dial the gateway, and (when it gives dial
>>>> tone) dial this softphone. No "PleaseLeaveYourMessage" plays, but
>>>> I can here the softphone hang up on me when the timeout expires.
>>>>
>>>> 2: running /usr/bin/pjsip-test-arm-poky-linux-gnueabi -l 6 logs an
>>>> error and quits.
>>>> line 918060 of 918085.
>>>> I can't tell where one test ends and another begins
>>>> (hint/beg of benny: please number the tests and print out the
>>>> number so I can say "test 4373 failed; it said "foobar" when it
>>>> should have said "mumble", and we'd be on the same page together.
>>>> Instead:
>>>> 20:02:58.879 Sending Response msg 200/INVITE/cseq=47769
>>>> (tdta0xb8c510) in state Proceeding
>>>> 20:02:58.879 .Destroying txdata Response msg 100/INVITE/cseq=47769
>>>> (tdta0xb93548)
>>>> 20:02:58.879 .TX 321 bytes Response msg 200/INVITE/cseq=47769
>>>> (tdta0xb8c510) to LOOP-DGRAM:0.0.0.0:0:
>>>> SIP/2.0 200 OK^M
>>>> Via: SIP/2.0/LOOP-DGRAM
>>>> 129.0.0.1:15060;rport=15060;received=129.0.0.1;branch=z9hG4bK-UAS-Test11^M
>>>>
>>>> Call-ID: 82e44fbf-330c-4350-8d46-773a2226cba8^M
>>>> From: <sip:alice@127.0.0.1>;tag=d71eff2a-a70f-4e7c-9151-a3a8a2f5e2f4^M
>>>> To: <sip:bob at 127.0.0.1>;tag=z9hG4bK-UAS-Test11^M
>>>> CSeq: 47769 INVITE^M
>>>> Content-Length: 0^M
>>>> ^M
>>>>
>>>> --end msg--
>>>> 20:02:58.879 .State changed from Proceeding to Completed, event=TX_MSG
>>>> 20:02:58.930 Transport failed to send Response msg
>>>> 200/INVITE/cseq=47769 (tdta0xb8c510)! Err=120104 (Connection reset
>>>> by peer)
>>>> 20:02:58.932 State changed from Completed to Terminated,
>>>> event=TRANSPORT_ERROR
>>>> 20:02:58.932 error: incorrect status code
>>>> 20:02:58.932 Timeout timer event
>>>> 20:02:58.932 .State changed from Terminated to Destroyed, event=TIMER
>>>> 20:02:58.932 ..Destroying txdata Response msg 200/INVITE/cseq=47769
>>>> (tdta0xb8c510)
>>>> 20:02:58.932 Transaction destroyed!
>>>> 20:02:58.933 ..ERROR(-170)
>>>> ------------------------------------------------------------------------
>>>> *From:* pjsip [pjsip-bounces at lists.pjsip.org] on behalf of Bill
>>>> Gardner [billg at wavearts.com]
>>>> *Sent:* Monday, October 27, 2014 2:16 PM
>>>> *To:* pjsip at lists.pjsip.org
>>>> *Subject:* Re: [pjsip] How to play a "splash-tone" file as soon as
>>>> posssible in the call sequence
>>>>
>>>> See pjsua_app.c for example on how to create player and connect to
>>>> conference when call answers. It's all part of the --auto-play
>>>> option in pjsua.
>>>>
>>>> On 10/27/2014 10:35 AM, Brunner, Brian T. wrote:
>>>>> I'm puzzled why you need to see broken code in order to tell me
>>>>> correct code?
>>>>>
>>>>> Given a call_id, how do I tell which conference port to connect
>>>>> to, in order to send a wav file to the caller? So far I've
>>>>> managed to connect it to my sound hardware, which isn't much progress.
>>>>>
>>>>> I'm curious which call-back is the earliest point in the call
>>>>> sequence wherein I'm able to tell which conference port to connect
>>>>> my player to (which I mentioned I'd created).
>>>>>
>>>>> When we're agreed that my broken code is in the correct place (and
>>>>> therefore it is the code that is broken, not its location) lets
>>>>> look at broken code to see what I did wrong in the right place.
>>>>>
>>>>> Is there an example of this process (I haven't found one yet)?
>>>>> ------------------------------------------------------------------------
>>>>> *From:* pjsip [pjsip-bounces at lists.pjsip.org] on behalf of Bill
>>>>> Gardner [billg at wavearts.com]
>>>>> *Sent:* Friday, October 24, 2014 3:47 PM
>>>>> *To:* pjsip at lists.pjsip.org
>>>>> *Subject:* Re: [pjsip] How to play a "splash-tone" file as soon as
>>>>> posssible in the call sequence
>>>>>
>>>>> Creating a player and connecting to the conference should work,
>>>>> perhaps you can share some code?
>>>>>
>>>>> On 10/24/2014 10:50 AM, Brunner, Brian T. wrote:
>>>>>>
>>>>>> My attempts (which have been many and unsuccessful) lead me to beg:
>>>>>> How can my SoftVoIPPhone pick up the call and play a "splash
>>>>>> tone" or "please leave your message after the tone" file from the
>>>>>> hard drive to the caller?
>>>>>>
>>>>>> I create a player, and I connect it to the conference, but
>>>>>> clearly not the right way or right time.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> ----------------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Confidentiality Requirement: This communication, including any
>>>>>> attachment(s), may contain confidential information and is for
>>>>>> the sole use of the intended recipient(s). If you are not the
>>>>>> intended recipient, you are hereby notified that you have
>>>>>> received this communication in error and any unauthorized review,
>>>>>> use, disclosure, dissemination, distribution or copying of it or
>>>>>> its contents is strictly prohibited. If you have received this
>>>>>> communication in error, please notify the sender immediately by
>>>>>> telephone or e-mail and destroy all copies of this communication
>>>>>> and any attachments.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20141106/f5687a86/attachment.html>
