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
