Re: Packetization handling for received calls ...

[Vadim Lebedev]

Title: TQI - Technology and Quality on Information

Hi Mauro, Yes that exactly what i suggest Thanks Vadim Mauro Sérgio Ferreira Brasil wrote: Hi Vadim! I tried something similar to what you've described below. On "ph_call_media_start", I tried to retrive the remote SDP using the call id "ca->did" which gives me the eXosip_call that holds the negotiation "osip_negotiation_ctx_t". The problem is that at this point ("ph_call_media_start" invokation), the remote SDP no longer exists for the "osip_negotiation_ctx_t" element. And, as long as I could see, the remote SDP is freed right after the media negotiation. Your suggestion is try the same approach but retrieving the remote SDP from "orig_request" present on "osip_transaction" of "eXosip_call_t", right ? 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 -- 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
QuteCom-dev@lists.qutecom.org
http://lists.qutecom.org/mailman/listinfo/qutecom-dev