Hello there!
Vadim,
Considering that the last change suggestion was handled by you and that
this one will be related with the same subject "packetization", I think
it would be better to talk directly with you.
Please let me know whether I should contact another person on this list.
We've made additional changes on codes here regarding packetization
parameters that are not being handled when the call is received by the user.
For example: if someone makes a call to our application that uses
qutecom libraries and informs a "ptime" different from default "20"ms,
this parameter won't be handled. The other client will send audio data
on a different packetization that expected by our client, making audio
incomprehensible.
This happens because when "ph_call_media_start" is called by the user
that accepts a call through "phAcceptCall3", the "eXosip_event_t *je"
parameter is NULL.
On calls that are initiated by the user, this is the parameter that
carries the "ptime" and "fmtp" info used to calculate the final
packetization.
This issue involves two major points:
1- Will we work with different packetizations for incoming and outgoing
audio ?
2- Considering that we choose to work with only one packetization for
incoming and outgoing audio, how and where will we make some kind of
negotiation to get this working ?
As long as I could understand by all the research I've done, one client
MUST provide the packetization expected by the other client (if informed
through "ptime", "mode" or another mean), and incoming and outcoming
packetization COULD be different.
Nevertheless, for the sake of simplicity and to reduce code changes, I
choose to work with same packetization on both audio channels.
Since I choose to work with same packetization, I needed to validate the
better way to "save" the packetization info received from the caller,
and make a kind of negotiation to define which attributes received from
the caller that will be "incorporated" on local SDP.
For example: If a caller send a SDP with "ptime=30", or a "mode=30" for
"fmtp" attribute of a iLBC media, I incorporate these values to the
local SDP, so they can be sent back as confirmation to the originator
and handled internally by the code already existent.
Before I send my patches, that are still demanding some little
adjustments, I would like to get an initial feeling from you of what
I've described above.
Thanks and best regards,
--
__At.,
_
*Technology and Quality on Information*
Mauro Sérgio Ferreira Brasil
Coordenador de Projetos e Analista de Sistemas
+ [EMAIL PROTECTED] <mailto:@tqi.com.br>
: www.tqi.com.br <http://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
