Pjlib on Symbian
Hi Benny,
Thanks for your response.
I have another question. I try to understand the media transmission flow and
I'm blocked with the logic of application.
Here is the stack of application running on Nokia E61 (is generated with
Carbide v1.3):
Thread [Thread id: 363] (Suspended: Breakpoint hit.)
5 pjmedia_delay_buf_put()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\delaybuf.c:266
0xf55c8ebc
4 pjmedia_port_put_frame()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\port.c:85
0xf55ca9ac
3 rec_cb()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\sound_port.c:139
0xf55cca2c
2 CPjAudioInputEngine::MaiscBufferCopied()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia-audiodev\symb_mda
_dev.cpp:464 0xf55df5f4
1 Unknown (0xF52005A8)() 0xf52005a8
We can see that the audio frame is captured by "MaiscBufferCopied()"
function which will run the callback function "rec_cb()" and finally the
audio frame arrive in the "delay buffer" passing through "put_frame"
function from Conference module (the application uses the Conference
bridge).
My question is when (or who) is reading the "delay buffer" (which contains
the audio frames received from microphone) and transmits the data to
transport layer?
Hope no bothers you to much,
George.
From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org]
On Behalf Of Benny Prijono
Sent: Friday, April 03, 2009 8:03 AM
To: pjsip list
Subject: Re: [pjsip] Pjlib on Symbian
2009/4/2 George Evi george.evi@ctcinc.ca
Hi Benny,
I activate the log in my project (PJ_LOG()) and used the function
"log_call_dump()" to dump the statistics at the end of a call.
I got these statistics:
Great! We love logs and statistics! :)
--end msg--State changed from Null to Calling, event=TX_MSGTransaction
tsx0x732e8c state changed to Calling
[CONFIRMED] To: sip:5148403000@sip6.van.netvoice.ca
mailto:sip%3A5148403000@sip6.van.netvoice.ca ;tag=as5b69601c
Call time: 00h:01m:56s, 1st res in 3542 ms, conn in 5824ms
SRTP status: Not active Crypto-suite: (null)
#0 PCMU @8KHz, sendrecv, peer=64.34.49.82:19122
RX pt=0, stat last update: 00h:00m:00.601s ago
total 5.7Kpkt 924.8KB (1.15MB +IP hdr) @avg=62.3Kbps/77.9Kbps
pkt loss=143 (2.4%), discrd=1 (0.0%), dup=0 (0.0%), reord=1 (0.0%)
(msec) min avg max last dev
loss period: 20.000 178.750 940.000 100.000 63.638
jitter : - 0.001 11.737 579.000 0.750 8.775
TX pt=0, ptime=20ms, stat last update: 00h:00m:03.680s ago
total 5.7Kpkt 906.4KB (1.13MB +IP hdr) @avg 61.1Kbps/76.5Kbps
pkt loss=2 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
(msec) min avg max last dev
loss period: 40.000 40.000 40.000 40.000 0.000
jitter : 193.000 193.000 193.000 193.000 0.000
RTT msec : 92.000 128.637 332.000 101.000 21.526
Processing incoming message: Response msg 200/BYE/cseq=18255
(rdata0x71e65c)RX 510 bytes Response msg 200/BYE/cseq=18255 (rdata0x71e65c)
from UDP 64.34.49.82:5060:
SIP/2.0 200 OK
I also read the "Understanding Media Flow" document and I have a (beginner)
question.
In the TX section we have a jitter line but in the Media Flow diagram there
is no Jitter Buffer for packet transmission, what represents this line?
We get these values from the RTCP report sent by the remote peer. If remote
peer doesn't support RTCP, we would not get these stats of course.
And also why in the same section the loss period and jitter buffer values
are the same for all statistics colons?
It's probably because it's only got one RTCP report? In this case then the
min/avg/max values would be the same, isn't it?
cheers
Benny
Thanks,
George.
From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org]
On Behalf Of Benny Prijono
Sent: Wednesday, March 25, 2009 3:56 AM
To: pjsip list
Subject: Re: [pjsip] Pjlib on Symbian
2009/3/24 George Evi george.evi@ctcinc.ca
Hi Benny,
I update my application with the latest version the "trunk pjproject- 1.1"
and continue to test on Nokia E61.
As you suggested I changed the codec priorities in a way that GSM had
highest priority (in function "pjsua_media_subsys_init" priority value =
PJMEDIA_CODEC_PRIO_NORMAL +4 (132)). The sound was acceptable on the caller
side but on the callee side continue to be stuttered, disrupted and
instable.
Hi George,
In that case, I would probably suggest to try to use different peer for the
testing (pjsua running on desktop would be a good candidate :) ). And make
sure the audio doesn't get routed through the server or otherwise this
wouldn't make any difference. You can call directly to the device's IP
address to make sure.
Also I tried the others codecs (iLBC, Speex/8000 and Speex/16000) in the
same way but didn't see any improvements.
iLBC and Speex/16000 is definitely out of question. Speex/8000 is probably
bang on the processing capability, so use it with care (e.g. only use
release mode), and probably is not good for troubleshooting problems like
this. And of course there is G.711, definitely a good candidate to try.
cheers
Benny
Do you have any suggestions or ideas?
We don't want to use Nokia APS (Audio proxy Server) for the moment, because
it needs a publisher ID.
Thank you,
George.
From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org]
On Behalf Of Benny Prijono
Sent: Friday, March 20, 2009 2:32 AM
To: pjsip list
Subject: Re: [pjsip] Pjlib on Symbian
2009/3/19 George Evi george.evi@ctcinc.ca
Hi Benny,
Thanks for your response.
The flow of sound is disrupted on both sides (caller and callee voice
reception). You can hear the sound but the words are not completed and on
the callee side the voice is metalique (like a robot speech). The latest
tests I made were done with Nokia E61 (S60 3rd edition -mr) connected Wi-Fi
and I expected to see some improvements but voice stilled disrupted.
I'm using iLBC as codec (1st priority) and UDP transport.
Aha, that's probably the reason. iLBC is heavy, I don't think the device has
enough processing power to run it [2]. Try with GSM or Speex.
Alternatively, consider using APS-Direct [1], available in pjsip version 1.1
now downloadable from the website. APS-Direct uses handset's native codec
and it supports iLBC, AMR, G.729, and G.711.
cheers
Benny
[1] http://trac.pjsip.org/repos/wiki/Nokia_APS_VAS_Direct
[2] http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
On Fri, Apr 3, 2009 at 10:37 PM, George Evi george.evi@ctcinc.ca wrote:
Hi Benny,
Thanks for your response.
I have another question. I try to understand the media transmission flow
and I’m blocked with the logic of application.
Here is the stack of application running on Nokia E61 (is generated with
Carbide v1.3):
Thread [Thread id: 363] (Suspended: Breakpoint hit.)
5 pjmedia_delay_buf_put()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\delaybuf.c:266
0xf55c8ebc
4 pjmedia_port_put_frame()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\port.c:85
0xf55ca9ac
3 rec_cb()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\sound_port.c:139
0xf55cca2c
2 CPjAudioInputEngine::MaiscBufferCopied()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia-audiodev\symb_mda_dev.cpp:464
0xf55df5f4
1 Unknown (0xF52005A8)() 0xf52005a8
We can see that the audio frame is captured by “MaiscBufferCopied()”
function which will run the callback function “rec_cb()” and finally the
audio frame arrive in the “delay buffer” passing through “put_frame”
function from Conference module (the application uses the Conference
bridge).
My question is when (or who) is reading the “delay buffer” (which contains
the audio frames received from microphone) and transmits the data to
transport layer?
That will be done by the audio device's playback callback, which will call
get_frame() of the conference.c, and subsequently pjmedia_delay_buf_get().
cheers
Benny
Hi Benny,
I have a question about the codec selection process.
Now the Speex/16000 has the highest priority (is set in the code like that)
but when I run the application only G711 is used.
I could verify this using the debug version and put a breakpoint in
"spx_codec_encode" function the application never stops there.
It seems that only G711 codec is used. Is this because of the SIP server?
The media line 'm' from the SDP how is managed (or negotiated) by the pjsip
module?
I do my tests with a phone Nokia E61 which is connected with Wi-Fi.
Can I ask you on what Nokia (or Symbian) phones the library was tested (may
be E61 is not a good candidate)?
Thank you,
George.
Hi Benny,
I update my application with the latest version the "trunk pjproject- 1.1"
and continue to test on Nokia E61.
As you suggested I changed the codec priorities in a way that GSM had
highest priority (in function "pjsua_media_subsys_init" priority value =
PJMEDIA_CODEC_PRIO_NORMAL +4 (132)). The sound was acceptable on the caller
side but on the callee side continue to be stuttered, disrupted and
instable.
Hi George,
In that case, I would probably suggest to try to use different peer for the
testing (pjsua running on desktop would be a good candidate :) ). And make
sure the audio doesn't get routed through the server or otherwise this
wouldn't make any difference. You can call directly to the device's IP
address to make sure.
Also I tried the others codecs (iLBC, Speex/8000 and Speex/16000) in the
same way but didn't see any improvements.
iLBC and Speex/16000 is definitely out of question. Speex/8000 is probably
bang on the processing capability, so use it with care (e.g. only use
release mode), and probably is not good for troubleshooting problems like
this. And of course there is G.711, definitely a good candidate to try.
cheers
Benny
Do you have any suggestions or ideas?
We don't want to use Nokia APS (Audio proxy Server) for the moment, because
it needs a publisher ID.
Thank you,
George.
From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org]
On Behalf Of Benny Prijono
Sent: Friday, March 20, 2009 2:32 AM
To: pjsip list
Subject: Re: [pjsip] Pjlib on Symbian
2009/3/19 George Evi george.evi@ctcinc.ca
Hi Benny,
Thanks for your response.
The flow of sound is disrupted on both sides (caller and callee voice
reception). You can hear the sound but the words are not completed and on
the callee side the voice is metalique (like a robot speech). The latest
tests I made were done with Nokia E61 (S60 3rd edition -mr) connected Wi-Fi
and I expected to see some improvements but voice stilled disrupted.
I'm using iLBC as codec (1st priority) and UDP transport.
Aha, that's probably the reason. iLBC is heavy, I don't think the device has
enough processing power to run it [2]. Try with GSM or Speex.
Alternatively, consider using APS-Direct [1], available in pjsip version 1.1
now downloadable from the website. APS-Direct uses handset's native codec
and it supports iLBC, AMR, G.729, and G.711.
cheers
Benny
[1] http://trac.pjsip.org/repos/wiki/Nokia_APS_VAS_Direct
[2] http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Hi,
I have a question about the codec selection during an "INVITE" request.
I want to use the iLBC codec and to do that I set a higher priority.
I activate the log in the library and below there are traces of an INVITE
request:
-
client:
INVITE/cseq=31666 (tdta0x73a678) to UDP 64.34.49.82:5060:
INVITE sip:5145294251@sip6.van.netvoice.ca SIP/2.0
Via: SIP/2.0/UDP
192.168.2.102:5060;rport;branch=z9hG4bKPjj5ATg0Ya9xVW0d2vTtMyPdYlvpmDk7P6
Max-Forwards: 70
From:
sip:nv2.ctci01.a@sip6.van.netvoice.ca;tag=Ah5zdhyiX0myLzxhYAH776mnSQZlZDOZ
To: sip:5145294251@sip6.van.netvoice.ca
Contact: sip:nv2.ctci01.a@69.159.242.205:1292;transport=UDP
Call-ID: JLjItY2mS8Mwkw1bAzF12M6iic4G40vO
CSeq: 31666 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
Proxy-Authorization: Digest username="nv2.ctci01.a",
realm="sip6.van.netvoice.ca", nonce="764e2ef9",
uri="sip:5145294251@sip6.van.netvoice.ca",
response="51a4f7de3b8993973a30d1e0e4f387ee", algorithm=MD5
Content-Type: application/sdp
Content-Length: 349
v=0
o=- 3448991582 3448991582 IN IP4 192.168.2.102
s=pjmedia
c=IN IP4 192.168.2.102
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 117 3 0 8 101
a=rtcp:4001 IN IP4 192.168.2.102
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
--end msg--State changed from Null to Calling, event=TX_MSGTransaction
-
server response:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.2.102:5060;branch=z9hG4bKPjj5ATg0Ya9xVW0d2vTtMyPdYlvpmDk7P6;received
=69.159.242.205;rport=1292
From:
sip:nv2.ctci01.a@sip6.van.netvoice.ca;tag=Ah5zdhyiX0myLzxhYAH776mnSQZlZDOZ
To: sip:5145294251@sip6.van.netvoice.ca;tag=as367c40fa
Call-ID: JLjItY2mS8Mwkw1bAzF12M6iic4G40vO
CSeq: 31666 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: sip:5145294251@64.34.49.82
Content-Type: application/sdp
Content-Length: 307
v=0
o=root 2719 2720 IN IP4 64.34.49.82
s=session
c=IN IP4 64.34.49.82
t=0 0
m=audio 17636 RTP/AVP 0 3 117 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
--end msg--Incoming Response msg 200/INVITE/cseq=31666 (rdata0x71d734) in
state
As we can see the client propose in media session iLBC codec in the 1st
position as expected.
The proxy server responds with its list of codecs with PCMU 1st position.
My question is why the application takes all the time the proxy server 1st
position codec (in our case PCMU)?
-
there is a trace where we can find the selected codec:
--end msg--Incoming Response msg 183/INVITE/cseq=31666 (rdata0x71d734) in
state ProceedingState changed from Proceeding to Proceeding,
event=RX_MSGReceived Response msg 183/INVITE/cseq=31666
(rdata0x71d734)Route-set updatedTransaction tsx0x74170c state changed to
ProceedingCall 0 state=EARLYGot SDP answer in Response msg
183/INVITE/cseq=31666 (rdata0x71d734)SDP negotiation done, status=0Call 0:
remote NAT type is 0 (Unknown)VAD temporarily
disabledpjmedia_rtp_session_init: ses=0x744714, default_pt=0,
ssrc=0x675eed34pjmedia_rtp_session_init: ses=0x744d38, default_pt=0,
ssrc=0x675eed34Stream strm0x742f14 createdEncoder stream startedDecoder
stream startedMedia updates, stream #0: PCMU (sendrecv)Port 1
(sip:5145294251@sip6.van.netvoice.ca) transmitting to port 0 (Symbian
Audio)Port 0 (Symbian Audio) transmitting to port 1
(sip:5145294251@sip6.van.netvoice.ca)- clock -Underflow, buf_cnt=0, will
generate 1 frameread_port sip:5145294251@sip6.van.netvoice.ca: count=320
get_frame, count=160Jitter buffer empty (prefetch=0) rx buffer size is now
160 get_frame, count=160 rx buffer size is now 320write_port
sip:5145294251@sip6.van.netvoice.ca: count=160put_frame
sip:5145294251@sip6.van.netvoice.ca, count=160Start talksprut.. tx_buf count
now is 160write_port sip:5145294251@sip6.van.netvoice.ca: count=160put_frame
.
Thank you,
George.
Hi,
Using one codec, application crashes.
For example I want to use only iLBC codec and I have deactivated (put in
comments "PJMEDIA_HAS_SPEEX_CODEC"," PJMEDIA_HAS_GSM_CODEC" .,) all the
other codecs.
When running (on Nokia E61) the application crashes.
Does anybody had this problem before?
Thanks,
George.
Hi,
Using one codec, application crashes.
For example I want to use only iLBC codec and I have deactivated (put in
comments "PJMEDIA_HAS_SPEEX_CODEC"," PJMEDIA_HAS_GSM_CODEC" .,) all the
other codecs.
My goal was to use a more performant codec as PCMU.
When running (on Nokia E61) the application crashes.
I debug the application with Carbide v1.3 and I have now the call stack when
the program has crashed:
SipPhone.exe [Process ID: 615] (Suspended)
Thread [Thread id: 616] (Suspended: Signal 'Exception 0'
received. Description: A data abort exception has occurred..)
13 Unknown (0xF80F572C)() 0xf80f572c
12 iCBSearch()
C:\Symbian\Carbide\voip-phone\SipPhone\third_party\ilbc\iCBSearch.c:62
0xf553ec20
11 iLBC_encode()
C:\Symbian\Carbide\voip-phone\SipPhone\third_party\ilbc\iLBC_encode.c:252
0xf55349a4
10 ilbc_codec_encode()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia-codec\ilbc.c:593
0xf5531b8c
9 put_frame_imp()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\stream.c:913
0xf554b664
8 put_frame()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\stream.c:1116
0xf554b830
7 pjmedia_port_put_frame()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\port.c:85
0xf5547be8
6 write_port()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\conference.c:1673
0xf5544354
5 get_frame()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\conference.c:1895
0xf55447bc
4 pjmedia_port_get_frame()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\port.c:68
0xf5547b84
3 play_cb()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia\sound_port.c:77
0xf5549b30
2 CPjAudioOutputEngine::MaoscBufferCopied()
C:\Symbian\Carbide\voip-phone\SipPhone\pjmedia\src\pjmedia-audiodev\symb_mda
_dev.cpp:741 0xf555d500
1 Unknown (0xF524375C)() 0xf524375c
As we can see it crashes inside the iLBC_encode() function.
Did anybody have this problem before?
Thanks,
George.