Hello there!
Vadim,
I was running against time here, so choose to make all necessary
changes and send you the patches for approval before your answers.
These patch files were generated over qutecom codes from revision
"a48abbba566c".
I think it will be easier to apply this way considering that many
changes made on first patch to handle "mode" paramater were fixed or
removed on this one.
I've made considerable changes to acchieve the following goals:
1- Unify the references to default packetization on a unique MACRO
definition;
2- Allow the handling of "ptime" and iLBC "mode" for originated and
received calls;
3- Allow different packetization on incoming and outgoing channels;
Everything went right on my tests, so theoretically the codes are right.
But I'm affraid some code blocks should be placed on different places
and about the use of some "phapi" features on "eXosip" library.
As I've said you before, my code base is out-of-date, and I test the
changes on my base and copy them to the qutecom codes.
Because of this, you can find some inconsistencies on patch files.
Please let me know whether everything is alright, ok?
Thanks and best regards,
Mauro.
Mauro Sérgio Ferreira Brasil escreveu:
Hi
Vadim,
Now back from vacations for sure :-).
My bad... Your appointments about "mode" parameter are completely right.
It seems that on my hurry to anticipate demand for new year I messed
some things up.
Before getting along with the "mode" parameter handling problem or any
other implementation issue, I would like to validate the other changes
suggested below.
On message sent 12/12/2008 I've given a more abstract idea of what I
was planning to do on this patch, involving: explicit indication of
packetization parameters and attributes on SDP messages for local
initiated calls and received calls; adjustments for different
packetization handling on both channels depending on who initiated the
call and the packetization indicators exchanged between the parts; etc.
About all that was described on this message, do you have any questions
or disagreements ?
I'm asking you that because all "packetization negotiation" part of the
patch is necessary only for explicit indication of packetization
parameters and attributes on SDP messages exchanged between the call
parts.
I think this indications (like the "ptime:20" being sent on a call
initiation scenario; or "ptime:30" reply when the received call have a
"ptime" value of 30; or a "fmtp:111 mode=30" reply for a call received
with this "mode" parameter) would be desired.
Do you agree with this "packetization negotiation" idea ?
If you agree, do you think the code location selected to make such
"negotiation" was the better one ? If it wasn't, were would be the
better place ?
If the "negotiation" is already being made on better place, is the
"mode" parameter handling the only point you consider that still demand
adjustments on this part of the patch ?
If the "mode" parameter is the only problem we have, do you think a new
method on "phcodec" structure that will make "per codec attributes
negotiation" would be a good idea ? If don't, do you have any
suggestions to make this as clean and less intrusive as possible ?
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
Hi Mauro,
Already back form vacations... It was fast :)
I suggest you read SDP RFC, because it seems that you misundestood
something.
the mode parameter is not always present and when present is not always
numeric.
in case of iLBC its a number representing a scalar value
in case of other payload it could a number representing a bitmask,
in case of video payload it could be a long string of parameters to
initialize the codec
So it is impossibile to negotiate it's value in the way you do, only
the codec-specifc code
understands it...
Thanks
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 |
