Discussiion list for developers using and contributing to sipXtapi API hosted on sipfoundry.org ()

D. S. | 6 Feb 2009 21:52

Fix for G.722 sessions to connect properly

As it stands, G.722 sessions will not connect using Recon with sipXtapi.
The reason is that G.722 sessions are negotiated with 8000 as the
sample rate even though it actually operates at 16000.
See sec. 4.5.2 in RFC3551 and the following link:
http://en.wikipedia.org/wiki/G.722

I got it working with my Polycom phone with the patches to sipXtapi
that follows.
My old Grandstream Budgetone 102 phone insists on negotiating 16000 in
the SDP which goes against what the RFC says.
If anyone can add code to negotiate both rates, that would be appreciated.
My patch also changes the default internal sample rate of the codec to
get it working with the default internal sipXtapi sample rate of 8000.
How do you build sipXtapi to use an internal sample rate of 16000?

David Suh

Index: SdpDefaultCodecFactory.cpp
===================================================================
--- SdpDefaultCodecFactory.cpp	(revision 11260)
+++ SdpDefaultCodecFactory.cpp	(working copy)
 <at>  <at>  -69,7 +69,8  <at>  <at> 
    { SdpCodec::SDP_CODEC_G726_40,       "g726-40", 8000, 1,  NULL },
    { SdpCodec::SDP_CODEC_G729A,         "g729a",   8000, 1,  "annexb=no" },
    { SdpCodec::SDP_CODEC_G729A,         "g729",    8000, 1,  "annexb=no" },
-   { SdpCodec::SDP_CODEC_G722,          "g722",   16000, 1,  NULL },
+   // This advertised G.722 SDP sample rate is required to maintain
backward compatibility as stated in sec. 4.5.2 of RFC3551.
+   { SdpCodec::SDP_CODEC_G722,          "g722",    8000, 1,  NULL },
    { SdpCodec::SDP_CODEC_TONES,         "telephone-event", 8000, 1,   NULL  },

(Continue reading)

headers

Alexander Chemeris | 9 Feb 2009 06:28

Re: Fix for G.722 sessions to connect properly

Hi David,

On Fri, Feb 6, 2009 at 11:52 PM, D. S. <dsuhpublic <at> gmail.com> wrote:
> As it stands, G.722 sessions will not connect using Recon with sipXtapi.
> The reason is that G.722 sessions are negotiated with 8000 as the
> sample rate even though it actually operates at 16000.
> See sec. 4.5.2 in RFC3551 and the following link:
> http://en.wikipedia.org/wiki/G.722

Yes, this is a known problem, and it's already workarounded in
sipXtapi. Look at following lines:
sipXtackLib\src\net\SdpBody.cpp:1272
sipXtackLib\src\net\SdpBody.cpp:1778
sipXtackLib\src\net\SdpHelper.cpp:220

So if it does not work with recon, it's a problem with recon I guess.
I recall I tested this with some phones and it worked.

> My patch also changes the default internal sample rate of the codec to
> get it working with the default internal sipXtapi sample rate of 8000.

It's a very different patch, please do not mix several changes into
a single one. You can use things like Mercurial queues to maintain
sets of patches.

Please, upload clean version of this patch to http://codereview.appspot.com/
Choose "sipXtapi/main branch" and add me (Alexander.Chemeris)
as a reviewer.

Actually we should pass flowgraph samplerate to a codec

(Continue reading)

headers

Alexander Chemeris | 9 Feb 2009 07:19

Re: 3.2 Branch: DTMF telephone-event seem to confuse the Jitter Buffering - PATCH

I got some free time to work on DTMF notifications only
last week, so it was implemented later, then expected.
But, after all, main branch can handle RFC4733 DTMF
tones. I enabled sending RFC4733 DTMFs when you
call sipxCallStartTone() and it emits sipXtapi events
when it receives them. SDP handling is slightly fixed too
along with jitter buffer confusion. I tested it with sipXtapi
to sipXtapi and X-Lite to sipXtapi calls.

On Tue, Jan 20, 2009 at 12:03 AM, Alexander Chemeris
<Alexander.Chemeris <at> sipez.com> wrote:
> On Mon, Jan 19, 2009 at 9:48 PM, Mert Kır <mert.kir <at> sestek.com.tr> wrote:
>> Although I apply the patch, I don!t have any DTMF event when remote device
>> sends dtmf. What should i do to have MEDIA_REMOTE_DTMF event work with
>> sipxtapi 3.2 stable branch.
>
> Stable 3.2 branch won't support DTMF notifications in sipXtapi.
> It requires definitely more changes, then we want to see in
> a stable branch. We plan to get DTMF notifications working
> in main branch during this or next week and you'll be welcome
> to test them then. I'll send notification to mailing list when
> relevant changes are committed.
>
>
> --
> Regards,
> Alexander Chemeris.
>
> SIPez LLC.
> SIP VoIP, IM and Presence Consulting

(Continue reading)

headers

Alexander Chemeris | 9 Feb 2009 07:24

New useful pages on sipXtapi wiki

Hi all,

We're slowly filling new sipXtapi wiki with useful information,
and I want to announce a useful page:
http://sipxtapi.sipfoundry.org/wiki/Changelog-3.3
As name states, it contain a list of changes we've done
in main branch after sipXtapi-3.2 was branched off. To date
it contain only few items, because I started it only recently,
and *a*lot* of cool changes are not listed. I hope to improve
the coverage over time and, most importantly, keep it up to
date.

--

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

D. S. | 9 Feb 2009 22:22

Re: Fix for G.722 sessions to connect properly

Alex,

On Sun, Feb 8, 2009 at 9:28 PM, Alexander Chemeris
<Alexander.Chemeris <at> sipez.com> wrote:
> Hi David,
>
> On Fri, Feb 6, 2009 at 11:52 PM, D. S. <dsuhpublic <at> gmail.com> wrote:
>> As it stands, G.722 sessions will not connect using Recon with sipXtapi.
>> The reason is that G.722 sessions are negotiated with 8000 as the
>> sample rate even though it actually operates at 16000.
>> See sec. 4.5.2 in RFC3551 and the following link:
>> http://en.wikipedia.org/wiki/G.722
>
> Yes, this is a known problem, and it's already workarounded in
> sipXtapi. Look at following lines:
> sipXtackLib\src\net\SdpBody.cpp:1272
> sipXtackLib\src\net\SdpBody.cpp:1778
> sipXtackLib\src\net\SdpHelper.cpp:220
>
> So if it does not work with recon, it's a problem with recon I guess.
> I recall I tested this with some phones and it worked.

Thank you for pointing me to this.
This would require Recon to hack the sample rate passed to sipXsdpLib
because Recon uses Resiprocate for the SIP stack.
IMHO, it would be better to make changes to the static tables in
SdpDefaultCodecFactory.cpp and plgg722.c because it would be handled
by the SDP library itself for all calling SIP stacks.
Static data changes are simpler than coded if-thens.
Of course, your mileage may vary if something depends on this somehow

(Continue reading)

headers

D. S. | 9 Feb 2009 22:40

Re: Fix for G.722 sessions to connect properly

Jaro,

On Sun, Feb 8, 2009 at 10:47 PM, Jaroslav Libak <jarol1 <at> seznam.cz> wrote:
> G.722 is supposed to report 8000 clockrate in SDP due to RFC bug. It also must
> use 8000 clockrate in RTP. Real sampling rate is 16Khz. If some other phone or
> software doesn't do so, its wrong and sipxtapi shouldn't have hacks to make it
> work. G.722 support already added enough hacks.

IMHO, I believe it is always good to be interoperable if you can.
If it is too much work, then there should be a line drawn in the sand.

>
> Its not very useful to use 8000 sample rate with G.722, due to degraded quality.
> It simply doesn't make sense to tell people you support a wideband codec, and
> encode using 8Khz.

My point was that the default internal sampling rate for sipXtapi is
8000 so why not make the default sampling rate for G.722 be 8000 so
someone who builds it may see that it works.
However, this may give developers a false sense that it is operating
as intended at 16000 without them realizing it.
Maybe my idea is not good for the long run.

>
> Jaro
>
> D. S. schrieb:
>> As it stands, G.722 sessions will not connect using Recon with sipXtapi.
>> The reason is that G.722 sessions are negotiated with 8000 as the
>> sample rate even though it actually operates at 16000.

(Continue reading)

headers

Keith Kyzivat | 9 Feb 2009 22:43

Re: Fix for G.722 sessions to connect properly

On Mon, Feb 9, 2009 at 4:22 PM, D. S. <dsuhpublic <at> gmail.com> wrote:

> Please, upload clean version of this patch to http://codereview.appspot.com/
> Choose "sipXtapi/main branch" and add me (Alexander.Chemeris)
> as a reviewer.

Thanks for the tip.
I don't submit many patches but I'm learning.

This is new for us too, and we're just starting to use it.

http://codereview.appspot.com/ is Google's public install of the Rietveld patch review system (which is open source based derivative of Google's internal Mondrian code review system)

I'm in midst of using it for the first such patch review, with Alex right at the moment.

It looks very promising for being both a learning/teaching tool for those that are not super-comfortable modifying and providing patches for open source software, and a way to be much more productive and provide better audit trail for code reviews.

--
Keith Kyzivat

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Alexander Chemeris | 9 Feb 2009 23:58

Re: Fix for G.722 sessions to connect properly

On Tue, Feb 10, 2009 at 12:22 AM, D. S. <dsuhpublic <at> gmail.com> wrote:
> On Sun, Feb 8, 2009 at 9:28 PM, Alexander Chemeris
> <Alexander.Chemeris <at> sipez.com> wrote:
>> On Fri, Feb 6, 2009 at 11:52 PM, D. S. <dsuhpublic <at> gmail.com> wrote:
>>> As it stands, G.722 sessions will not connect using Recon with sipXtapi.
>>> The reason is that G.722 sessions are negotiated with 8000 as the
>>> sample rate even though it actually operates at 16000.
>>> See sec. 4.5.2 in RFC3551 and the following link:
>>> http://en.wikipedia.org/wiki/G.722
>>
>> Yes, this is a known problem, and it's already workarounded in
>> sipXtapi. Look at following lines:
>> sipXtackLib\src\net\SdpBody.cpp:1272
>> sipXtackLib\src\net\SdpBody.cpp:1778
>> sipXtackLib\src\net\SdpHelper.cpp:220
>>
>> So if it does not work with recon, it's a problem with recon I guess.
>> I recall I tested this with some phones and it worked.
>
> Thank you for pointing me to this.
> This would require Recon to hack the sample rate passed to sipXsdpLib
> because Recon uses Resiprocate for the SIP stack.
> IMHO, it would be better to make changes to the static tables in
> SdpDefaultCodecFactory.cpp and plgg722.c because it would be handled
> by the SDP library itself for all calling SIP stacks.
> Static data changes are simpler than coded if-thens.
> Of course, your mileage may vary if something depends on this somehow
> and breaks.

Yeah, I recall it was a deliberate decision. I recall value from
the SDP is used to determine how to handle this codec in
flowgraph. E.g. if reported codec samplerate differs from
a flowgraph samplerate, data will be automatically
up/downscaled by decoder/encoder resource. (you need
to compile with Speex support enabled for this).

So, it's a bug in specs and it should be handled as a bug.
I.e. it should introduce as small confusion as possible.
My hacks are small enough, and I hope recon can be
hacked the same way.

-
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Alexander Chemeris | 10 Feb 2009 00:01

Re: Fix for G.722 sessions to connect properly

On Tue, Feb 10, 2009 at 12:40 AM, D. S. <dsuhpublic <at> gmail.com> wrote:
> On Sun, Feb 8, 2009 at 10:47 PM, Jaroslav Libak <jarol1 <at> seznam.cz> wrote:
>> G.722 is supposed to report 8000 clockrate in SDP due to RFC bug. It also must
>> use 8000 clockrate in RTP. Real sampling rate is 16Khz. If some other phone or
>> software doesn't do so, its wrong and sipxtapi shouldn't have hacks to make it
>> work. G.722 support already added enough hacks.
>
> IMHO, I believe it is always good to be interoperable if you can.
> If it is too much work, then there should be a line drawn in the sand.

Right.

>> Its not very useful to use 8000 sample rate with G.722, due to degraded quality.
>> It simply doesn't make sense to tell people you support a wideband codec, and
>> encode using 8Khz.
>
> My point was that the default internal sampling rate for sipXtapi is
> 8000 so why not make the default sampling rate for G.722 be 8000 so
> someone who builds it may see that it works.
> However, this may give developers a false sense that it is operating
> as intended at 16000 without them realizing it.
> Maybe my idea is not good for the long run.

Actually it will be downsampled to 8000 if flowgraph operates
at 8000. It will consume considerably more CPU power then
enabling 8000 mode in G.722 itself, but I don't see this as a
problem, because G.722 will likely not be used in 8000
operation mode.

--

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

headers

Keith Kyzivat | 10 Feb 2009 00:05

Re: Fix for G.722 sessions to connect properly

On Mon, Feb 9, 2009 at 5:58 PM, Alexander Chemeris <Alexander.Chemeris <at> sipez.com> wrote:

On Tue, Feb 10, 2009 at 12:22 AM, D. S. <dsuhpublic <at> gmail.com> wrote:> Thank you for pointing me to this.

> This would require Recon to hack the sample rate passed to sipXsdpLib
> because Recon uses Resiprocate for the SIP stack.
> IMHO, it would be better to make changes to the static tables in
> SdpDefaultCodecFactory.cpp and plgg722.c because it would be handled
> by the SDP library itself for all calling SIP stacks.
> Static data changes are simpler than coded if-thens.
> Of course, your mileage may vary if something depends on this somehow
> and breaks.

Yeah, I recall it was a deliberate decision. I recall value from
the SDP is used to determine how to handle this codec in
flowgraph. E.g. if reported codec samplerate differs from
a flowgraph samplerate, data will be automatically
up/downscaled by decoder/encoder resource. (you need
to compile with Speex support enabled for this).

The reason you need to compile with speex support enabled is because we use the speexdsp resampler code, and this is enabled by enabling speex.

--
Keith Kyzivat

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000

_______________________________________________
sipxtapi-dev mailing list
sipxtapi-dev <at> list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

4	June 2010
4	February 2010
4	January 2010
8	December 2009
18	November 2009
2	October 2009
16	September 2009
6	August 2009
32	July 2009
18	June 2009
22	May 2009
3	April 2009
8	March 2009
29	February 2009
8	January 2009
42	December 2008
40	November 2008
77	October 2008
41	September 2008
14	August 2008
14	July 2008
16	June 2008
10	May 2008
31	April 2008
29	March 2008
59	February 2008
54	January 2008
38	December 2007
12	November 2007
45	October 2007
72	September 2007
78	August 2007
269	July 2007
162	June 2007
182	May 2007
80	April 2007
245	March 2007
161	February 2007
62	January 2007
111	December 2006
137	November 2006
84	October 2006
196	September 2006
192	August 2006

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28