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.
Vadim Lebedev escreveu:
Hi Mauro,
Sorry for the delay....
Yur analysis is correct.
The only point is that QutCom does send ptime attribut in outgoing
sdp's.
This is controlled by EXOSIP_FORCE_PTIME env variable
Thanks
Vadim
Mauro Sérgio Ferreira Brasil wrote:
Hi Vadim!
Let me just fully understand your point.
With such adjustment the application will work with same packetization
on both channels when receiving a call, prioritizing the packetization
informed by the caller on this scenario, right ?
On the other hand, when we initiate the call our default of 20ms for
packetization will contrast with the one informed by the callee pair
that could or not be the same.
Speeking of 20ms default packetization, you haven't answered my
question about why the "ptime:20" isn't added to original SDP on
Qutecom libraries.
Thanks,
Mauro.
Vadim Lebedev escreveu:
The ideal behaviour would be to DO a copy when handling an incoming call
and NOT DOING it when handling outgoing call...
Thanks
Vadim
Mauro Sérgio Ferreira Brasil wrote:
Hi Vadim!
I forgot to reply my considerations about the copying of opayloads to
ipayloads.
I agree and understand the copy of opayloads elements to ipayloads.
What I was trying to validate is whether we should copy "ptime" and
"fmtp" fields from info present on "opaylods" itens to "ipayloads"
ones, what happens on method "ph_update_media_payloads_fmtp".
My suggestion was to remove lines 209 and 216 of file "phapi-old.c"
after the last patch applied, that correspond to lines with **** below:
if (strstr(format_modifier, pszPayloadId)
!=
NULL)
{
msp->opayloads[payloadIndex].fmtp =
osip_strdup(format_modifier);
msp->ipayloads[payloadIndex].fmtp =
osip_strdup(format_modifier); ****
}
}
if (msp->ptime != 0)
{
msp->opayloads[payloadIndex].ptime = msp->ptime;
msp->ipayloads[payloadIndex].ptime = msp->ptime;
****
}
}
}
What do you think ?
Thanks,
Mauro.
Vadim Lebedev escreveu:
Hi
Mauro,
The IDEAL algoritm for SDP negotiation should be as
follows:
We have two parties A and B. The party sending an
SDP
OFFER
(usually this is the calling side but not always) called OFFERER the
party replying
called ANSWERER
When ANSWERER receives SDP OFFER it learns which
payload
number
corresponds to which codecs with corresponding params
so it can generate an SDP ANSWER with the same mapping
(in
our
context it means copying opayloads to ipayloads)
when new call arrives the function ph_call_new in
phapi-old.c
is callde with event pointer which you could use.
You can use this moment to retrieve infos from incoming
SDP,
`
however the BEST way would be to dwelve into the heart
of
eXosip
and to add a function wich receives a dialog id as input and retrieves
the exoisp_dialog and from there osip_transaction and from there
osip_message holding incoming SDP
Thanks
Vadim
Le 4 déc. 08 à 19:18, Mauro Sérgio Ferreira Brasil a
écrit
:
Hi Vadim,
Getting back on handling packetization info issue when answering a
call, I have some questions to clear up with you:
1- Having a better look on method "ph_update_media_payloads_fmtp", I
fell that the "ipayloads" array should not be affected by it. Here we
are considering "ptime" and "fmtp" info received as a indication of
which packetization the other part desires, and this should affect only
"opayloads" array, right ?
I think you tried to tell me that when I was doing this patch, but at
that moment I didn't understand very well.
My suggestion is to eliminate the lines where the "ipayloads" get
assigned, let these values clean as was before and keep passing the
parameter to "decoder_init" for future use, maybe.
What do you think ?
2- It seems to me that Qutecom libraries were meant to be used with
20ms packetization by default, so why isn't a "ptime:20" being added to
local SDP by default too ?
This one is just a curiosity.
3- I'm having some problems here to identify the better place to get
and/or the better way to save the remote SDP info ("ptime" and "fmtp"
modifiers) when I'm accepting a remote call. As I said on prior
messages, on such condition, the method "ph_call_media_start" receive
"je" parameter as NULL which was the way we provided to store/carry the
packetization info when the user initiate a call.
When I've tried the same packetization on both channels approach, I
changed method "osip_negotiation_ctx_execute_negotiation" to
incorporate the packetization modifiers received from the caller on
local SDP, and used this info after on "ph_call_media_start" on an
similar way that happens now for local initiated calls.
Now that we agree that we won't work with same packetization on both
channels, I'm not finding a better way to carry the remote SDP
parameters out to "ph_call_media_start" method on remote call accept
scenario.
Do you have any idea/suggestion to give me ?
Thanks,
Mauro.
Vadim Lebedev escreveu:
Mauro,
First httptunnel functionality do exist in QuteCom (you should look
int owsl layer)
Second, YES your fmtp handling stuff is now include in main qutecom
repo
Thanks
Vadim
Mauro Sérgio Ferreira Brasil wrote:
Vadim,
Time my friend... time...
Lots of things to do and few time to get them done... :-)
In fact this application that we provide maintenance uses some
libraries and we consider version updates with extremely care.
And these especific wengo libraries have lots of changes that comes
from old versions (like the use of "httptunnel" that don't even is part
of current codes).
A complete merge will demand a considerable amount of time to be done.
This is why we still uses old Wengophone 2.1 codes.
Now, when you said me that the patch for handle of iLBC "mode"
attribute was added to Qutecom source codes, you mean that it was done
on main codes ?
I'll get these changes whether I update my HG local copy ?
Thanks,
Mauro.
Vadim Lebedev escreveu:
Mauro,
No problem, please keep me posted.
Btw i'm curious: understand you're using WengoPhone 2.1 code base for
your project, so
what is the reason not using more recent QuteCom?
Thanks
Vadim
Mauro Sérgio Ferreira Brasil wrote:
Hi Vadim,
Unfortunatelly, my efforts on Qutecom codes are delimited by our
customer's needs.
On next few days I'll be envolved on general maintenance and little bug
fixes on their client.
Next week I expect to have some time to dedicate to packetization
handling on both sides issue that will shortly become a demanding to
them.
Good new is that this payload number issue should raise on their needs
shortly too, because of usability of Asterisk servers nowadays.
Sorry I can not help you on this now.
But I'll contact you if our customer ask us about this.
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
Mauro,
QuteCom does handles INCOMING ptime...
I wanted howevre to raise another issue - payload number negotiation.
The current implementation is somewhat deficiant because the
code in wifo/eXosip/sdp_offans.c compairs only payload numbers during
negtiation.
So if we receive an SDP where iLBC is mapped to 95 (I think this is
what Asterisk uses) we will refuse it because we use 111 as payload nr
for iLBC.
Can you take a look at this?
Thanks
Vadim
--
| 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 |
--
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 |
--
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 |
--
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 |
|
