Return to LanScape's home page Go back a page...       Active TopicsActive Topics   Display List of Forum MembersMember List   Knowledge Base SearchSearch   HelpHelp  RegisterRegister  LoginLogin

LanScape VOIP Media Engine™ - Pre-Sales Technical Support
 LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Subject Topic: Another Urgent Severe Voice Quality Issue! Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 14 2008 at 1:04am | IP Logged Quote speedvoip
Hi Support:
Per what u instruct me, I modify playback buffering setting into quad(4), "ka ka" noise is removed. But another noise occures, u can use same testing parameters to test and find that each time callee voice is completed, caller can hear a slight "bo bo" noise.
Thus how to tune corresponding parameters for this issue? Tell me answer.

Urgent!!!

As u know, any voice quality related issue will be vital. whereas feature related bug or issue can be tolerent. Pls keep in mind that.

__________________
VoIP Anti-Blocking Guru
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 14 2008 at 11:22am | IP Logged Quote speedvoip
Help me Pls !!!!!!!!!!!!!!!

__________________
VoIP Anti-Blocking Guru
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 15 2008 at 9:01am | IP Logged Quote support
Hi George,

Hmmm…… we will need more information from you. It could be anything.


1)
What exactly is a “bo bo” noise? Please be as descriptive as possible. We have not heard this term before.

2)
What codec is being used for the call?

3)
Does the noise go away if you use another codec?

4)
Have you tested making calls using other host machines?

5)
Does the “bo bo” noise heard occur on all machines?

6)
Try to get an Ethereal or WireShark network trace of the RTP media for the call. Email the captured call data to us and we will look. We need to know if the noise is occurring in the RTP channel for the call or by internal processing of the media engine.

7)
Enable call recording for the phone line. After making the call where “bo bo” noise occurs, does the noise also appear in the recorded call data file?

8)
Does the noise occur when calling other VOIP domains, VOIP servers or VOIP service providers? We need to know if there is some kind of codec incompatibility somewhere and possibly if an unsupported codec feature is not assuming proper default behavior.

9)
Please post the SIP log for the call setup that experiences the “bo bo” noise. There might be something in the SIP or SDP that will give us an indication what is going on.


There are other things to try but the above list is a good place to start.


Support


Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 17 2008 at 5:31am | IP Logged Quote speedvoip
Hi Support:
Per what u instruct, I have done all things. RTP media trace file for noise call in form of Wireshark and recorded captured file are all sent to support email for troubleshooting together with sip log file.

1."bo bo" noise is a kind of lightweight pausing tone which often occures at interval between two sentences or words. This noise only can be heared from phone line, not by recording sample audio block. In listening to recorded sound, we can not find "bo bo" noise.

2. I have tested any supported codec, there all existed noise. But codec for primary testing is g.729 and g.729A.

3. No, after changing codec, noise not go away.

4. Yes, on several machines, result is same.

5. Among all testing machines, noise all occures.

6. Yes, captured RTP media file is sent to email.

7. No, noise not appears at recorded call data.

8. I have tested singleline phone example upon at least three voip domains, results are all same: noise occures at phone line, not at recorded data.

9. Yes. I can do that.

Code:


************* Log Opened (Nov 17 19:06:29) *************
>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#1, [19:06:35.255] 0 Ms, To: 203.167.54.180:6060) >>>>
REGISTER sip:sw2.sp.ring-fone.com:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:6060;rport;branch=z9hG4bK01c9c509
From: <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c95200
To: <sip:77880003@sw2.sp.ring-fone.com:6060>
Call-Id: 38f7d679-df5d-4929-9062-23ca00bcfa5f-000012bc@192.168.1.100
CSeq: 13202036 REGISTER
Expires: 1800
Max-Forwards: 70
Contact: <sip:77880003@192.168.1.100:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.0  (www.LanScapeCorp.com)
x-MyCustomHeader: "This is a modified transmitted SIP message."
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.0 (www.LanScapeCorp.com)
Content-Length: 0




<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#1, [19:06:35.971] 0 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 401 Unauthorized
From: <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c95200
To:  <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=b436a7cb- 17ac-49215511-8644fe16-539da0d7
 Call-ID: 38f7d679-df5d-4929-9062-23ca00bcfa5f-000012bc@192.168.1.100
CSeq: 13202036 REGISTER
Contact: <sip:77880003@192.168.1.100:6060>;user=phone
Expires: 60
WWW-Authenticate: Digest realm="Subcentrex", nonce="49215511", stale=false, algorithm=MD5, qop="auth,auth-int"
Via: SIP/2.0/UDP  192.168.1.100:6060;received=61.141.174.213;rport=28986;branc h=z9hG4bK01c9c509
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#2, [19:06:35.976] 721 Ms, To: 203.167.54.180:6060) >>>>
REGISTER sip:sw2.sp.ring-fone.com:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:6060;rport;branch=z9hG4bK01c95b0f
From: <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c95200
To: <sip:77880003@sw2.sp.ring-fone.com:6060>
Call-Id: 38f7d679-df5d-4929-9062-23ca00bcfa5f-000012bc@192.168.1.100
CSeq: 13202037 REGISTER
Authorization: Digest  algorithm=md5,cnonce="00c9b6b6",nc=00000001,nonce="49215511",
 qop=auth,realm="Subcentrex",response="cb6bad9914d2053bdd811 9402d1fed5e",
 uri="sip:sw2.sp.ring-fone.com:6060",username="7 7880003"
Expires: 1800
Max-Forwards: 70
Contact: <sip:77880003@192.168.1.100:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.0  (www.LanScapeCorp.com)
x-MyCustomHeader: "This is a modified transmitted SIP message."
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.0 (www.LanScapeCorp.com)
Content-Length: 0




<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#2, [19:06:36.582] 611 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 200 OK
From: <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c95200
To:  <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=b436a7cb- 17ac-49215512-8645007b-285264ad
 Call-ID: 38f7d679-df5d-4929-9062-23ca00bcfa5f-000012bc@192.168.1.100
CSeq: 13202037 REGISTER
Contact: <sip:77880003@192.168.1.100:6060>;user=phone
Expires: 60
Via: SIP/2.0/UDP  192.168.1.100:6060;received=61.141.174.213;rport=28986;branc h=z9hG4bK01c95b0f
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#3, [19:06:49.859] 13882 Ms, To: 203.167.54.180:6060) >>>>
INVITE sip:0755114@sw2.sp.ring-fone.com:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:28986;rport;branch=z9hG4bK01c9c2a1
From: "LanScape Phone" <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9f826
To: <sip:0755114@sw2.sp.ring-fone.com:6060>
Contact: <sip:77880003@61.141.174.213:28986>
Call-Id:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212232 INVITE
Max-Forwards: 70
Organization:  6A8361EE-CBCB-4E2D-A584-76CEF7FBC2F5
x-MyCustomHeader: "This is a modified transmitted SIP message."
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.0 (www.LanScapeCorp.com)
Content-Length: 196
User-Agent: LanScape VOIP Media Engine/6.0.0.0  (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp

v=0
o=77880003 29984343 29984343 IN IP4 61.141.174.213
s=LanScape
c=IN IP4 61.141.174.213
t=0 0
m=audio 8732 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=sendrecv
a=fmtp:18 annexb=no
a=ptime:20




<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#3, [19:06:50.310] 13728 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 100 Trying
From: "LanScape  Phone"<sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9 f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-ID:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212232 INVITE
Via: SIP/2.0/UDP  192.168.1.100:28986;received=61.141.174.213;rport=28986;bran ch=z9hG4bK01c9c2a1
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Contact: <sip:0755114@sw2.sp.ring-fone.com:6060>
Content-Length: 0




<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#4, [19:06:50.872] 562 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 183 Session Progress
From: "LanScape  Phone"<sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9 f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-ID:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212232 INVITE
Content-Type: application/sdp
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Via: SIP/2.0/UDP  192.168.1.100:28986;received=61.141.174.213;rport=28986;bran ch=z9hG4bK01c9c2a1
Contact: <sip:0755114@sw2.sp.ring-fone.com:6060>
Content-Length: 221

v=0
o=0755114 1226921248 1226921248 IN IP4 203.167.54.180
s=session-name
c=IN IP4 203.167.54.180
t=0 0
m=audio 33396 RTP/AVP 18 101
c=IN IP4 203.167.54.180
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#5, [19:06:56.095] 5222 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 180 Ringing
From: "LanScape  Phone"<sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9 f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-ID:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212232 INVITE
Content-Type: application/sdp
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Via: SIP/2.0/UDP  192.168.1.100:28986;received=61.141.174.213;rport=28986;bran ch=z9hG4bK01c9c2a1
Contact: <sip:0755114@sw2.sp.ring-fone.com:6060>
Content-Length: 221

v=0
o=0755114 1226921253 1226921253 IN IP4 203.167.54.180
s=session-name
c=IN IP4 203.167.54.180
t=0 0
m=audio 33396 RTP/AVP 18 101
c=IN IP4 203.167.54.180
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#6, [19:06:56.110] 16 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 200 OK
From: "LanScape  Phone"<sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9 f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-ID:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212232 INVITE
Content-Type: application/sdp
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Via: SIP/2.0/UDP  192.168.1.100:28986;received=61.141.174.213;rport=28986;bran ch=z9hG4bK01c9c2a1
Contact: <sip:0755114@203.167.54.180:6060>
Content-Length: 221

v=0
o=0755114 1226921253 1226921253 IN IP4 203.167.54.180
s=session-name
c=IN IP4 203.167.54.180
t=0 0
m=audio 33396 RTP/AVP 18 101
c=IN IP4 203.167.54.180
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000



>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#4, [19:06:56.115] 6256 Ms, To: 203.167.54.180:6060) >>>>
ACK sip:0755114@sw2.sp.ring-fone.com:6060 SIP/2.0
Via: SIP/2.0/UDP  192.168.1.100:28986;received=61.141.174.213;rport=28986;bran ch=z9hG4bK01c9c2a1
From: "LanScape Phone" <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-Id:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212232 ACK
Max-Forwards: 70
Route: <sip:0755114@203.167.54.180:6060>
User-Agent: LanScape VOIP Media Engine/6.0.0.0  (www.LanScapeCorp.com)
x-MyCustomHeader: "This is a modified transmitted SIP message."
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.0 (www.LanScapeCorp.com)
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#5, [19:07:22.989] 26875 Ms, To: 203.167.54.180:6060) >>>>
BYE sip:0755114@sw2.sp.ring-fone.com:6060 SIP/2.0
Via: SIP/2.0/UDP 61.141.174.213:6060;rport;branch=z9hG4bK01ca8330
From: "LanScape Phone" <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-Id:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212233 BYE
Max-Forwards: 70
User-Agent: LanScape VOIP Media Engine/6.0.0.0  (www.LanScapeCorp.com)
x-MyCustomHeader: "This is a modified transmitted SIP message."
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.0 (www.LanScapeCorp.com)
Content-Length: 0




<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#7, [19:07:23.414] 27304 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 200 OK
From: "LanScape  Phone"<sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1c9 f826
To:  <sip:0755114@sw2.sp.ring-fone.com:6060>;tag=b436a7cb-1 7ac-4921551f-86453616-348e17db
 Call-ID:  d58781d4-0230-48fa-8e02-d9afca112fdb-000012bc@61.141.174.213 
CSeq: 13212233 BYE
Via: SIP/2.0/UDP 61.141.174.213:6060;rport=28986;branch=z9hG4bK01ca8330
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#6, [19:07:25.807] 2818 Ms, To: 203.167.54.180:6060) >>>>
REGISTER sip:sw2.sp.ring-fone.com:6060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:6060;rport;branch=z9hG4bK01ca5af0
From: <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1ca12f4
To: <sip:77880003@sw2.sp.ring-fone.com:6060>
Call-Id: 38f7d679-df5d-4929-9062-23ca00bcfa5f-000012bc@192.168.1.100
CSeq: 13202038 REGISTER
Expires: 0
Max-Forwards: 70
Contact: <sip:77880003@192.168.1.100:6060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.0  (www.LanScapeCorp.com)
x-MyCustomHeader: "This is a modified transmitted SIP message."
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.0 (www.LanScapeCorp.com)
Content-Length: 0




<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#8, [19:07:26.232] 2818 Ms, From: 203.167.54.180:6060) <<<<
SIP/2.0 200 OK
From: <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=1ca12f4
To:  <sip:77880003@sw2.sp.ring-fone.com:6060>;tag=b436a7cb- 17ac-49215543-8645c27e-4d1d22a2
 Call-ID: 38f7d679-df5d-4929-9062-23ca00bcfa5f-000012bc@192.168.1.100
CSeq: 13202038 REGISTER
Contact: <sip:77880003@192.168.1.100:6060>;user=phone
Expires: 60
Via: SIP/2.0/UDP  192.168.1.100:6060;received=61.141.174.213;rport=28986;branc h=z9hG4bK01ca5af0
Supported: replaces,ACK,INFO,CANCEL,BYE,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Content-Length: 0




************* Log Closed (Nov 17 19:07:26) *************




Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 17 2008 at 12:19pm | IP Logged Quote support
Hi George,

We understand all of the information that you last posted. Thanks for the effort. We can not see any “glaring” mistake as to why “bo bo” noise is present. We really need to hear an example of the noise you speak of in order to determine a possible cause.

From your information, it appears that the media engine is receiving all RTP media properly and it is not a codec issue. This would be proven by listening to the media engine recorded audio for the phone call. If there is no noise in the full duplex recorded phone line audio, then RTP reception and codec decoding Is OK.

It does appears however that the noise source is somewhere in the final playback signal processing that occurs immediately before rendering the internal digitally mixed sample block data to multimedia hardware.

It is important that we get an audio sample of the “bo bo” noise. If we can capture that, then we will be well on our way to removing the noise and figure out why it is occurring.

One thing we can do to attempt an audio “capture” is to use an undocumented API procedure that will allow us to record the final playback sample blocks to a wave file. You can call the following API procedure anytime after the media engine has been configured (anytime after the call to StartSipTelephone() procedure).

Code:

TELEPHONY_RETURN_VALUE VOIP_API AudioSubsystemSavePlaybackSa mples(
          SIPHANDLE hStateMachine, 
          char *pWaveFileName,
          BOOL Enable
          );



Once you call the above API procedure, make a phone call that exhibits the noise and send us the resulting wave file.


Support



Notes:

This post discusses VOIP Media Engine undocumented API procedures that are used for internal test purposes. Do not use these API procedures in your VOIP applications.


Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 18 2008 at 10:57am | IP Logged Quote speedvoip
Hi Support:
Per your instruction, I have recorded final playback sample block to wav file and have emailed it to u. I have found that there existed bo bo noise at final playback sample block.
So your analysis is right, something wrong or inproper processing maybe at final signal stage.
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 18 2008 at 5:25pm | IP Logged Quote support
George,

Got it. We will review the sample file probably in the morning. We also owe you a few other forum responses - again in the morning.

Thanks,

Support

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 19 2008 at 2:24pm | IP Logged Quote support
Hi George,

We hear the noise in the sample data file you sent us. Strange…..

The media engine supports internal time scaling of the audio stream data. If may have something to do with that.

My gut tells me that we may have an overflow condition occurring in the audio time scaling function block that exists just prior to multi media audio playback.

If you can perform a test, see if the noise goes away as you reduce the phone line receive volume level using the SetPhoneLineVolume() API procedure.

Hmmm… we have to think…. Hopefully we can get rid of “bo bo”.   :)


Thanks,

Randal

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 20 2008 at 3:11am | IP Logged Quote speedvoip
Hi Support:
Very pity to tell u that althrough lowing phone line receive volume, result is same: bo bo existed.

Pls hurry up remove bo bo.

After that time, I will place order Sir.
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 20 2008 at 10:18am | IP Logged Quote support
Hi George,

OK, we will need you to capture a bit of RTP data for us.

What we are going to do is capture the raw RTP payloads that are being received by your media engine app. Once we have this data, we can then at our location simulate the complete receive audio path for your call and see what is occurring.

Here is what we need you to do:

1)
Disable jitter compensation for received phone line data using the SetEnableJitter() API procedure.

2)
Allow all RTP payloads for the phone line to be logged in a HEX dump. Somewhere in your test code you will need to call the undocumented API procedure:

Code:

TELEPHONY_RETURN_VALUE VOIP_API LogReceivedRtpPackets(
          SIPHANDLE hStateMachine,
          int PhoneLine,
          BOOL Enable,
          char *pLogFileName
          );



Set the Enable parameter to TRUE and set the pLogFileName parameter to point to some log file name you chose.

3)
Perform your test call having your app receive a call. Do not send RFC2833 DTMF digits to your app. If “bo bo” noise is heard, continue to keep the call going for 30 seconds or so that we have enough RTP logged data.

4)
Email us the RTP log file that was captured for the call.

5)
Once we get the log file, we can analyze and determine the cause.



Randal



Notes:

This post discusses VOIP Media Engine undocumented API procedures that are used for internal test purposes. Do not use these API procedures in your VOIP applications.


Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 20 2008 at 10:24am | IP Logged Quote speedvoip
Hi Support:
My testing is based on SingleLine Phone example, pls tell me where to place LogReceivedRtpPackets api proc within source code.
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 20 2008 at 12:07pm | IP Logged Quote support
Hi George,

You can call the LogReceivedRtpPackets() API proc anytime after the media engine is created. A good place to call it is right after the StartSipTelephony() proc.

Support

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 21 2008 at 10:45am | IP Logged Quote speedvoip
Hi Support:
I have captured RTP payload in HEX dump form into log file and emailed to u. Pls check it and analyse it ASAP to find root cause for fixing bug.

My customers is nearly to be crasy.
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 21 2008 at 1:30pm | IP Logged Quote support
OK... Got it.

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 22 2008 at 6:09pm | IP Logged Quote support
Hi George,

Ok… I worked all day today on Saturday to get to the bottom of the noise issue you reported.

The RTP receiver packet dump you created with the media engine last week gave me the data I needed to make a thorough analysis of the receive media payloads.

For your test call -> 20Ms G729 (annexb=no) was set up. Under this condition, the far end of the call should only send RTP packets that are 32 total bytes on length. 12 bytes for RTP header and 20 bytes for 20Ms frame worth of media.

The far end SHOULD NOT send any other type of media packets for this call… but the far end of the call is sending some strange RTP packet data.

Test Results:

Missing or out of sequence RTP packets:
Taking your RTP dump data, I ran our RTP payload sequence verify test. The result: Only 4 packets were missing for the call and the missing packets appeared at the very end of the call. So packet sequence or missing packets are not the issue at this point.

Strange RTP payload type 19 (1 byte of data) being received:
One thing the sequence test did show is that the media engine is receiving RTP packets having only a single byte of data with payload ID of 19. I have no clue at this point what payload 19 is being used for by the far end. The far end should not be sending this RTP payload data. The media engine is taking this payload 19 data and treating it as full RTP frame audio. The result – Playback noise. We need to find out what this payload 19 data is being used for and make the media engine handle it properly or figure out how to make the far end stop sending it.

G729 frames not always 20Ms in length:
I also ran our “payload size verify tests” and the results were interesting. Occosionally, the far end of the call sends 10Ms frames of G729 data even though the call set up 20Ms frame data. There were a total of 19 frames of 10Ms data for the 70 second call. The media engine takes this ½ frame data and tries to use them as full RTP frames. The result – Playback noise.

Conclusion:
So we now know what the problem is and why the “bo bo” noise is occurring. What we have to do now is determine the best strategy to handle the above cases.

If you have time, try and check into what RTP payload 19 is being used for and why the far end of the call seems to occasionally send half frames of RTP data.

The good news is, once we determine the appropriate solution, we will have very clear crisp G729 audio for the deployment scenario you face.

Here is some of the log data from the RTP tests I ran:

Code:


Sequence test shows:

1) 4 lost packets. Not an issue. 

2) The big issue is: Why are we receiving Payload 19?

*************************************************
* SequenceVerify Test                           *
*************************************************
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1
Warning: Unsuported RTP payload type 19 detected. Payload bytes = 1

Warning: Expected sequence number 16276, detected 16277
Warning: Expected sequence number 16953, detected 16954
Warning: Expected sequence number 16978, detected 16979
Warning: Expected sequence number 18021, detected 18022


Error: RTP packets sequence errors detected = 4.

------------------------------------------------------------ -----------

PayloadSizeVerify test shows:

1) 19 bad sized packets. Why? 

2) Why are we receiving Payload 19? 


*************************************************
* PayloadSizeVerify Test                        *
*************************************************
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.
Warning: Unsuported RTP payload type 19 detected.

Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 15261)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 15689)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 15800)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 15893)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16155)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16223)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16272)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16428)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16636)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16858)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 16968)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 17061)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 17253)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 17439)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 17805)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 18026)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 18137)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 18482)
Error: Expected payload size of 20 bytes, detected 10 (RTP Sequence: 18652)


Error: RTP packets payload size errors detected = 19.




Post back with any thoughts you have.


See you Monday…Thanks George,


Randal


Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 23 2008 at 1:32am | IP Logged Quote speedvoip
Hi Randal:
Great analysis job. I understand what u concern. Let me think some while on why happened and when to happen. At your side, pls give cost-effective solution to bug ASAP!
It is better that I can get updated image for bug fix.

Work Hard!!!
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 23 2008 at 10:09am | IP Logged Quote speedvoip
Hi Support:
For either unknown RTP payload type frame or half an RTP frame, media engine need to handle me in more robust way. It means "more tolerant", in fact we sometimes even can not ask 3rd-party fix their own stuffs expect to allow us to be more adaptive, isn't it?
As u know, there are many many exceptional cases at VoIP powered networking.
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 24 2008 at 11:04am | IP Logged Quote support
Hi George,

Unfortunetely I will not be able to get back to this issue until next week. As much as I would like to address this now, I have to focus on demands of other customers who have paid support agreements with us.

That being said, this "bo bo" noise issue will be addressed formally.

One thing you can do in the mean time is have your VOIP app filter received RTP packets for G729 calls. Its easy to do.

To allow your app to filter received RTP packets, call the EnableRawRtpPacketAccess() API procedure any time after the media engine has been initialized (anytime after you call the StartSipTlephony() proc).

The callback proc you register with the media engine will be executed for all transmitted and received RTP packets. Filtering bogus G729 RTP packets is easy.

Your handler will be called and will be passed a pointer to a RAW_RTP_DATA data structure.

To filter RTP packets not having the proper frame length:
Have your callback handler look at the RtpPacketLengthInBytes value. If it is not 32 bytes (representing an RTP header 12 bytes + 20 bytes of payload (20Ms)), then set the ProcessRtpPacket structure member to FALSE (zero) to have the media engine ignore the received RTP packet.

To filter RTP packets not having the payload type 18 (G729):
Have your callback handler look at the pRtpHeader-> PayloadType value. If it is not set to 18 (G729), then set the ProcessRtpPacket structure member to FALSE (zero) to have the media engine ignore the received RTP packet.

Hopefully simply filtering out the bad RTP packets will give good results. Like I said, we have not had time yet to learn why your VOIP domain is sending the ½ frame size G729 packets and why RTP packets having payload 19 are being received. This will take time to look into and we will not have time until possibly next week.

The option is to contract with us to resolve immediately. That’s just the way it is.


Thanks,

Randal

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 24 2008 at 11:32am | IP Logged Quote speedvoip
Hi Support:
Today I will place official order over online shop. Pls address me order link.

Thanks
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 24 2008 at 1:58pm | IP Logged Quote support
Hi George,

The different line versions of the media engine can be purchased starting at this web page:

http://www.lanscapecorp.com/Store/pi-837478901.asp?categoryI d=0

Thanks,


Support

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 25 2008 at 9:11am | IP Logged Quote speedvoip
Hi Support:
I have placed order just now. Pls check it and deliver latest official media engine release without any time bomb. Then I require that bo bo noise should be fixed ASAP because I have been your customer from now.
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
speedvoip
Vetran
Vetran


Joined: August 07 2008
Location: Canada
Posts: 156
Posted: November 25 2008 at 4:09pm | IP Logged Quote speedvoip
Hi Support:
Pls process my order and request ASAP! Why not to response?
Back to Top View speedvoip's Profile Search for other posts by speedvoip Visit speedvoip's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 26 2008 at 7:07am | IP Logged Quote support
Hi George,

We know that you are in a hurry. :)
The order is in the process of being completed. It won't be long. Hang on.....

Thanks,

Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: December 13 2008 at 7:59am | IP Logged Quote support
George,

You sent to me an email containing a VOIP test account I could use from my location for testing the fixes for the bobo noise issue.

I have tested the media engine against this VOIP server (sw2) and do not get any bobo noise or problematic received RTP packets.

What is going on?

I need to test with a server that sends the garbage RTP packets.

Thanks,


Randal

Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: December 13 2008 at 8:49am | IP Logged Quote support
George,

By chance, are you accessing the same server as I am using some sort of wireless connection?

Hmm....

Randal
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 

Page of 2 Next >>
  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum





Contact LanScape Hear what the Lawyers have to say How youm may use this site Read your privacy rights