Dear H.323Plus team,
I have a question regarding support for skype's silk codec. Do you plan to support it soon? Maybe you have already started development/integration? Do you expect any obstacles?
Best regards, Łukasz Czekierda
Lukasz
The issue is there is no definition of Silk in H.323
I wrote a submission to the ITU at the last meeting for inclusion http://wftp3.itu.int/av-arch/avc-site/2009-2012/1011_Res/AVD-3994.zip
The stumbling block is that SILK has defined dynamic payloads for each bitrate for interop with Skype. In H.323 you cannot tell the remote what payload to send, the remote will tell you want it will send. This becomes an issue if you are bridging to skype. There is a work around (submitted by Avaya for a different issue but same meeting) to include in the OLCack the payload that you expect the remote to send you.
I have a development H.323 silk plugin (8k and 16k bitrate) and I will commit them after the next stable release as it requires audio capability merging which needs to be committed. The idea is there is 1 silk capability for the different bitrates (rather than a capability for each bitrate) and you negotiate the actual bitrate by merging your local caps with the caps in the TCS.
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Lukasz Czekierda Sent: Tuesday, January 11, 2011 7:42 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Silk codec support
Dear H.323Plus team,
I have a question regarding support for skype's silk codec. Do you plan to support it soon? Maybe you have already started development/integration? Do you expect any obstacles?
Best regards, Łukasz Czekierda
h323plus\plugins\video\common\dyna.cxx line 70: DynaLink::Open()
If %PTLIBPLUGINDIR% is not set and P_DEFAULT_PLUGIN_DIR is not defined, ptlibPath is never initialized and can cause a buffer overrun and stack corruption in InternalOpen().
Probably the #ifdef should include an #else where ptlibPath is initialized to "".
Are there any plans to update the code to use safe string routines?
Hi Alessandro,
the initialization is fixed in the CVS now. Thanks!
If you could provide a patch to switch to safe string routines that would be great. So far we don't have any other volunteers.
Regards, Jan
Alessandro Angeli wrote:
h323plus\plugins\video\common\dyna.cxx line 70: DynaLink::Open()
If %PTLIBPLUGINDIR% is not set and P_DEFAULT_PLUGIN_DIR is not defined, ptlibPath is never initialized and can cause a buffer overrun and stack corruption in InternalOpen().
Probably the #ifdef should include an #else where ptlibPath is initialized to "".
Are there any plans to update the code to use safe string routines?
-- Alessandro
From: "Jan Willamowius" jan@willamowius.de Date: Tuesday 11 January 2011 16:30
the initialization is fixed in the CVS now. Thanks!
Wouldn't an #else make more sense than the memset()? After all, initialization is already guaranteed if the envvar is set or the default is defined. This is the fix I used:
if (env != NULL) strcpy(ptlibPath, env); #ifdef P_DEFAULT_PLUGIN_DIR else strcpy(ptlibPath, P_DEFAULT_PLUGIN_DIR); #else else strcpy(ptlibPath, ""); #endif
Or, more compact:
(void)strcpy(ptlibPath,env ? env : # ifdef P_DEFAULT_PLUGIN_DIR P_DEFAULT_PLUGIN_DIR # else "" # endif );
If you could provide a patch to switch to safe string routines that would be great. So far we don't have any other volunteers.
Well, I don't even have a working build yet :-) For now I'll just keep reporting the bugs I find until I have something working.
Currently I am building my test app using h323plus, applications and plugins from the H323Plus's CVS and ptlib fron Opal's SVN, ignoring the copies of the plugins in the extensions folder and in Opal.
Is this the supported combination of components?
Alessandro
Yes H323plus is sync'd and developed against Opal's SVN. It also has a version checker which allows it to be compiled against any version from ptlib 2.4
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Alessandro Angeli Sent: Wednesday, January 12, 2011 8:56 AM To: h323plus@lists.packetizer.com Subject: [h323plus] suggested build config
Currently I am building my test app using h323plus, applications and plugins from the H323Plus's CVS and ptlib fron Opal's SVN, ignoring the copies of the plugins in the extensions folder and in Opal.
Is this the supported combination of components?
-- Alessandro
Alessandro,
I choose this initialization, because a.) its the same as used by InternalOpen() right below and b.) it is now very obvious that ptlibPath it is now always initialized.
Your method is ok, too. If you want changes done a certain way, the easiest method would be to send in patches ("diff -u") instead of general hints. ;-)
Regards, Jan
Alessandro Angeli wrote:
From: "Jan Willamowius" jan@willamowius.de Date: Tuesday 11 January 2011 16:30
the initialization is fixed in the CVS now. Thanks!
Wouldn't an #else make more sense than the memset()? After all, initialization is already guaranteed if the envvar is set or the default is defined. This is the fix I used:
if (env != NULL) strcpy(ptlibPath, env); #ifdef P_DEFAULT_PLUGIN_DIR else strcpy(ptlibPath, P_DEFAULT_PLUGIN_DIR); #else else strcpy(ptlibPath, ""); #endif
Or, more compact:
(void)strcpy(ptlibPath,env ? env : # ifdef P_DEFAULT_PLUGIN_DIR P_DEFAULT_PLUGIN_DIR # else "" # endif );
If you could provide a patch to switch to safe string routines that would be great. So far we don't have any other volunteers.
Well, I don't even have a working build yet :-) For now I'll just keep reporting the bugs I find until I have something working.
-- Alessandro
From: "Jan Willamowius" jan@willamowius.de Date: Wednesday 12 January 2011 07:24
Your method is ok, too. If you want changes done a certain way,
I don't really care, I was just saying because you had the #ifdef there anyway and exploiting it would save a memset() most of the time, but there is no practical difference.
the easiest method would be to send in patches ("diff -u") instead of general hints. ;-)
Next time I'll know :-)
I added SILK to OPAL a couple of months back. Unfortunately it was SIP only as I did not know what the H.245 encoding is for SILK, if any.
Now that I see there is at least a proposed standard, this should be able to be finished in a few minutes. It would be really nice if the two systems could use the same code for this.
Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder.
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus- bounces@lists.packetizer.com] On Behalf Of Simon Horne Sent: Tuesday, 11 January 2011 9:32 PM To: 'Łukasz Czekierda' Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Silk codec support
Lukasz
The issue is there is no definition of Silk in H.323
I wrote a submission to the ITU at the last meeting for inclusion http://wftp3.itu.int/av-arch/avc-site/2009-2012/1011_Res/AVD-3994.zip
The stumbling block is that SILK has defined dynamic payloads for each bitrate for interop with Skype. In H.323 you cannot tell the remote what payload to send, the remote will tell you want it will send. This becomes
an
issue if you are bridging to skype. There is a work around (submitted by Avaya for a different issue but same meeting) to include in the OLCack the payload that you expect the remote to send you.
I have a development H.323 silk plugin (8k and 16k bitrate) and I will commit them after the next stable release as it requires audio capability merging which needs to be committed. The idea is there is 1 silk
capability
for the different bitrates (rather than a capability for each bitrate) and you negotiate the actual bitrate by merging your local caps with the caps
in
the TCS.
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Lukasz
Czekierda
Sent: Tuesday, January 11, 2011 7:42 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Silk codec support
Dear H.323Plus team,
I have a question regarding support for skype's silk codec. Do you plan to support it soon? Maybe you have already started development/integration?
Do
you expect any obstacles?
Best regards, Łukasz Czekierda
participants (5)
-
Alessandro Angeli -
Jan Willamowius -
Robert Jongbloed -
Simon Horne -
Łukasz Czekierda