Re: Packetization handling for received calls ...

[Mauro Sérgio Ferreira Brasil]

Title: TQI - Technology and Quality on Information

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