Mauro,
Generally speaking your plan is OK, however the code you've sent IMO
present some problems.
ptime attrirbute should be not per negotioation but per media
and mode attribute should be defined per payload.
I'd suggest you to look here for inspiration:
http://svn.savannah.gnu.org/viewvc/trunk/linphone/coreapi/sdphandler.h?revision=1&root=linphone&view=markup
http://svn.savannah.gnu.org/viewvc/trunk/linphone/coreapi/sdphandler.c?revision=160&root=linphone&view=markup
Thanks
Vadim
Mauro Sérgio Ferreira Brasil wrote:
Hi Vadim,
Regarding my suggestion below, let me post here some code blocks so you
can have a better idea of what I'm planning to do:
1- First of all members "ptime" created on "eXosip_event_t" and
"ph_mstream_params_s" (on version 2.2 if I'm not wrong), won't be
necessary any more. And the changes on method
"eXosip_get_sdp_media_info" to return "ptime" value won't be necessary
as well. Method "eXosip_get_sdp_audio_ptime" stay and become public;
2- Method "osip_negotiation_ctx_execute_negotiation" will call a new
method called "osip_negotiation_execute_media_negotiation" responsible
for make a kind of packetization negotiation considering for now the
"ptime" attribute and "mode" paramater of iLBC payload. This
negotiation will be placed only on "audio" type medias, and codes for
this negotiation can be seen on "packet_negoc.txt" attached file;
3- All info extraction and assignment to "ptime" and "fmtp" fields of
respective "ph_media_payload_s" for "opayloads" and "ipaylodas" will
take place at "ph_call_media_start" method. Just one place will be
responsible for all data extraction and assignment of necessary fields
to be used at "ph_msession_audio_stream_hardstart" method for codecs
initialization and for buffer allocation along the life time of the
coding/decoding process. Code that returns the right "ptime" for
incoming and outgoing scenarios is on "ptime_get.txt" attached file;
I'm working now on a similar method to retrieve the "fmtp" modifiers so
I can use them and "in_ptime" and "out_ptime" retrieve with above
method to set the "ph_media_payload_s" respective infos.
As we agreed before, the codec will be responsible for analyse the
content of "fmtp" field, but I think it will be better if we update the
"mode" field of "ph_media_payload_s" structure (instead of "ptime" one)
after this analysis and let the computing of final packetization to be
assigned on "phastream_t" for a calculation that will take place on
"ph_msession_audio_stream_hardstart" method.
And I suggest that "ptime" field from "phastream_t" will be replaced by
"in_ptime" and "out_ptime" fields to be used on buffer allocation.
Right after I intend to make the necessary adjustments on
"ph_msession_audio_stream_hardstart" and on every buffer allocation
point (if necessary).
Please let me know if you have any doubts or disagreements about what
I've described above ok?
I confess I'm not very secure about what I can and I can't do... so I
need your advise for sure on it, mainly on negotiation procedure codes
I've sent.
Thanks, best regards and have a good weekend!
Mauro.
Mauro Sérgio Ferreira Brasil escreveu:
Hi Vadim,
No problem about the delay.
It was good in fact because I was involved on other demands here, and I
had a chance to make a new reading of necessary RFC's.
After reading the RFC's and giving a better look on code, I think
the last patch will need some adjustments and new patch I was working
with too.
The main points are:
1- We need to work with 2 packetization indication scenarios
(initiating call and receiving call);
2- When initiating a call we have the possibility to work with
different packetization on incoming and outgoing channels (this will
affect buffer allocation and codec initialization);
3- Some packetization paramaters (like "mode" of iLBC) are
bi-directional what will demand additional care, as explained here "http://www.rfc-editor.org/rfc/rfc3952.txt";
My suggestion is to create a patch with following premisses:
1- Only "ptime" and iLBC "mode" packetization indicators will be
handled for now;
2- As suggested by you, we will work with same packetization on call
receiving scenario, and accept different packetization on call
initiation (if the other part indicates a different value of course);
Considering what was described above, I would like to suggest the
following adjustments/validations:
1- Add parameter "int bIsIncomingCall" (indicating that the call was
received or not) to method "osip_negotiation_ctx_execute_negotiation"
that will be used on a kind of "packetization parameters negotiation"
on such a way that our local SDP will be updated with according "ptime"
and/or "fmtp" attributes;
2- Add the "ptime:20" attribute on method "eXosip_initiate_call" so the
INVITE always indicate the preferred Qutecom packetization;
3- Make the necessary changes on previous patch, and on work that was
already done about handle of "ptime" and iLBC "mode" on call receiving,
to consider the scenario of different packetinzation for incoming and
outgoing channel so we can have final and correct values to "in_ptime"
and "out_ptime" that will be the new fields of "phastream_t" used on
buffer allocation and audio initialization for both channels;
4- Validate all points where the method
"ph_astream_decoded_framesize_get" is used to validate whether the
changes to consider different packetization won't cause any problems;
That's it.
I think this will cover all changes necessary to have Qutecom libraries
working with packetization parameters as dinamicaly as possible for now.
Could you please send me your impressions about all I've suggested
above ?
Thanks and best regards,
Mauro.
--
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
