Mauro,
Go ahead submit your patches for review...
The general approach is ok for me
Thanks
Vadim
Le 21 mai 09 à 18:55, Mauro Sergio Ferreira Brasil a écrit :
Hi Vadim!
I've started testing our application with updated QuteCom codes and
libraries today and I have already faced some issues that I would
like to suggest to you as patches.
Issue 1:
It was regarding two subsequent calls of method
"owplConfigEnableHttpTunnel" with the same configuration.
The second call causes the addition of a second instance of the same
socket type to "owsl_socket_type_list", what will cause failure
during some validation that is made further.
I have already fixed the logic inside our codes so this don't happen
again but, nevertheless, I think the implementation of this method
could be changed in the way a not so drastic event (like calling it
twice with same configuration) don't lead to problems on further
methods invocation. (On my case, the phone line registration failed.)
The idea is quite simple: remove all itens on the very beggining of
this method and let the right itens to be added inside the "if-then-
else" block.
Issue 2:
The first registration test I've made was with HTTP tunnel enabled
and it failed immediately because the HTTP message format (the
headers, in fact) was not what our SIP HTTP tunnel server was
expecting to receive.
The connection request was sent, but no "200 OK" was got back in
response.
To solve this problem I was wondering if it it would be "acceptable"
to create call methods that can be registered by an external
application in order to provide the HTTP request on expected format.
It would be something like shown bellow: (consider file "owsl_uoh.c")
static int _owsl_uoh_make_http_request(OWSLSocketInfo_UoH *sock,
const char * ip_addr, unsigned short port)
{
char query[512];
char buff[2048];
int nbytes;
if ( (owsl_http_request_formatters != NULL) &&
(owsl_http_request_formatters->uoh_connect_formatter !=
NULL) )
{
// Use external request formatter.
owsl_http_request_formatters->uoh_connect_formatter(query,
sizeof(query), sock, ip_addr, port);
}
else
{
snprintf(query, sizeof(query), HTTP_REQUEST_STR, ip_addr,
port);
}
....
Registration methods and the main structure that will hold them is
not described here, but will be very intuitive.
For now, I see a demand to connection request formatting that will
be needed for both UOH and UOHS implementations. Maybe this could be
extended for the further requests as well.
I still need to validate that.
Thats it!
Is there any possibility of this patch suggestions to be accepted
and applied to main QuteCom codes ?
As I've said before, my intention during this migration is to get a
final set of codes that are as similar as possible with the current
QuteCom codes version.
That's why I'm sending some patch suggestions.
If some of them (or both of them) are not accepted, this will be
part of other changes that I have already made here that are
specific to our needs.
Thanks and best regards,
Mauro.
Mauro Sergio Ferreira Brasil escreveu:
Wow...
Thanks a lot for the very quick answer Vadim.
I'll send you the patch regarding "phLineSetFollowMe" method as
soon as I get this codes migrated, what I expect won't take too
much time.
Thanks again and best regards,
Mauro.
Vadim Lebedev escreveu:
Hi Mauro,
you can use owplMessageSend in place of phLineSendMessage
An'd i'm willing to accetp a patch reinstatit phLineSetFollowMe
into phapi-old.c
Thanks
Vadim
Mauro Sergio Ferreira Brasil wrote:
Hi Vadim!
During my efforts to migrate our codes to "qutecom-2-2-RC3"
version, I found two missing methods that we used on prior
versions that are: "phLineSendMessage" and "phLineSetFollowMe".
- "phLineSendMessage" is present on current codes, but is not
being defined. It's between "if 0" and "endif" statements and
with a "// not used" comment.
- "phLineSetFollowMe", by the other hand, disappeared from
current codes.
Is there any replacement for those methods ?
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
Hi Mauro,
Le 6 mai 09 à 20:09, Mauro Sergio Ferreira Brasil a écrit :
Hello there!
Vadim,
Some time ago, when I was submiting a patch to this list, I
told you that we worked with old versions of the voip libs that
we've got from OpenWengo project and you've asked me why we
weren't using the new version still.
That's it, now we are migrating to new and updated codes
("qutecom-2-2-RC3" version to be more especific) and I would
like to ask some questions to you:
1- Despite of the existence of old methods "phXXX" (phInit,
phAcceptCall, etc) on libraries, I've noticed on entire
"sipwrapper" library (that I suppose is used on QuteCom) the
usage of the new "owplXXX" methods. So, I suppose the use of
those new "owplXXX" methods and associated new callback and
constants should be preferable, right ?
Yes...
2- The worst part of this migration probably will be to
identificate all changes introduced by prior programmers on
original code (which are highlighted) and apply those that are
really necessary. Any of these changes that prove to be still
necessary will be posted as patches to this list. Are you ok
with that ?
Sure...
More than everything I need some guidance on question 1.
With this migration done I should get back to the patch
regarding "mode" parameter from "fmtp" attribute negotiation
for iLBC codec.
Thanks and best regards,
Thanks a lot for your effort
Vadim
--
At.,
<CMMI_2.jpg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
--
At.,
<mime-attachment.jpeg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
--
At.,
<mime-attachment.jpeg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
--
At.,
<mime-attachment.jpeg>
Technology and Quality on Information
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [email protected]
: www.tqi.com.br
( + 55 (34)3291-1700
( + 55 (34)9971-2572
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
