[OpenH323]Patch for adding {hw} capabilities, even if no codec available (fwd)

[Diana Cionoiu]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-432056473-1113088520=:4139
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.50.0504100216061.4178@dragoshel>

Hello list,

Maybe you should also consider addung this patch into all OpenH323 
versions, if you want to have codec passtrough for OpenH323.

Diana Cionoiu

---------- Forwarded message ----------
Date: Sun, 10 Apr 2005 02:17:15 +0300 (EEST)
From: Paul Chitescu <paulc@voip.null.ro>
Reply-To: openh323@openh323.org
To: openh323@openh323.org
Cc: craigs@postincrement.com
Subject: [OpenH323]Patch for adding {hw} capabilities,
     even if no codec available


Hello!

During development of the Yate H.323<->SIP signalling proxy we really 
needed a way to add particular capabilities to an endpoint, even if no 
codec for that specific data format is installed. We redirect the RTP 
stream (claiming we have an external RTP) so we really don't care about 
codecs.

We basically try to add "NAME*{sw}" capabilities and if we fail (that is,
GetCapabilities().GetSize() doesn't change) and faking is enabled we retry 
with "NAME*{hw}".

Older (pre 1.14.0?) versions of openh323 didn't care about the actual 
presence of a codec and added capabilities as requested. Newer versions 
seems to only allow software codecs, even if explicitely requested to add 
{hw} capabilities.

This is a slight modification of the patch that was proposed by Diana
Cionoiu and rejected by the developers. This new version checks if
hardware capabilities were explicitely requested. After all, if we ask for
it, shouldn't we get it? ;-)

Supposing we have no codec for G.723:
AddAllCapabilities(0,0,"G.723.1*") -> adds nothing
AddAllCapabilities(0,0,"G.723.1*{sw}") -> adds nothing
AddAllCapabilities(0,0,"G.723.1*{hw}") -> adds G.723.1 capabilities

I hope this behaviour is what was intended.


Paul Chitescu
--8323328-432056473-1113088520=:4139
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="openh323-addallcapshw.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.50.0504100215200.4139@dragoshel>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="openh323-addallcapshw.patch"

VGhpcyBwYXRjaCBhcHBsaWVzIHRvIG9wZW5oMzIzLTEuMTQuc29tZXRoaW5n

IG9yIGhpZ2hlcg0KLS0tIC4vc3JjL2gzMjNjYXBzLmN4eC5vcmlnCTIwMDQt

MDgtMjYgMTE6MDU6MDQuMDAwMDAwMDAwICswMzAwDQorKysgLi9zcmMvaDMy

M2NhcHMuY3h4CTIwMDUtMDEtMTAgMTM6Mjg6MjcuMDAwMDAwMDAwICswMjAw

DQpAQCAtMTg3MCw3ICsxODcwLDcgQEANCiAgICAgUENhc2VsZXNzU3RyaW5n

IGNhcE5hbWUgPSAqcjsNCiAgICAgaWYgKE1hdGNoV2lsZGNhcmQoY2FwTmFt

ZSwgd2lsZGNhcmQpICYmIChGaW5kQ2FwYWJpbGl0eShjYXBOYW1lKSA9PSBO

VUxMKSkgew0KICAgICAgIEJPT0wgZm91bmQgPSBzdGQ6OmZpbmQoc3RkRm9y

bWF0cy5iZWdpbigpLCBzdGRGb3JtYXRzLmVuZCgpLCBjYXBOYW1lKSAhPSBz

dGRGb3JtYXRzLmVuZCgpOw0KLSAgICAgIGlmICghZm91bmQgJiYgKGNhcE5h

bWUuUmlnaHQoNCkgPT0gIntzd30iKSAmJiBjYXBOYW1lLkdldExlbmd0aCgp

ID4gNCkNCisgICAgICBpZiAoIWZvdW5kICYmIChjYXBOYW1lLkdldExlbmd0

aCgpID4gNCkgJiYgKChjYXBOYW1lLlJpZ2h0KDQpID09ICJ7c3d9IikgfHwg

KChjYXBOYW1lLlJpZ2h0KDQpID09ICJ7aHd9IikgJiYgKG5hbWUuUmlnaHQo

NCkgPT0gIntod30iKSkpKQ0KICAgICAgICAgZm91bmQgPSBzdGQ6OmZpbmQo

c3RkRm9ybWF0cy5iZWdpbigpLCBzdGRGb3JtYXRzLmVuZCgpLCBjYXBOYW1l

LkxlZnQoY2FwTmFtZS5HZXRMZW5ndGgoKS00KSkgIT0gc3RkRm9ybWF0cy5l

bmQoKTsNCiAgICAgICBpZiAoZm91bmQpIHsNCiAgICAgICAgIC8vIGFkZCB0

aGUgY2FwYWJpbGl0eQ0K
--8323328-432056473-1113088520=:4139--