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
--
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 |
|
