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
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
