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.,
|
 |
| 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 |
--
TQI - Technology and Quality on Information
| At.,
|
 |
| 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
--
TQI - Technology and Quality on Information
| At.,
|
 |
| 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 |
|
