Mauro, First of all, it is really funny you rais the subject, because i was writing and email to you rasing it myself :)
Second, i think it preferable to keep the discussion on the list, so other people will be aware and be able to make sugestions. Third, while your approach will work in most situations what will happen if you send an INVITE with ptime=30 and receive an 200 ok with ptime=20.... You'll HAVE to work with different packetizations for each direction. Thanks Vadim Mauro Sérgio Ferreira Brasil wrote: > Hello there! > > Vadim, > > Considering that the last change suggestion was handled by you and that > this one will be related with the same subject "packetization", I think > it would be better to talk directly with you. > Please let me know whether I should contact another person on this list. > > We've made additional changes on codes here regarding packetization > parameters that are not being handled when the call is received by the user. > For example: if someone makes a call to our application that uses > qutecom libraries and informs a "ptime" different from default "20"ms, > this parameter won't be handled. The other client will send audio data > on a different packetization that expected by our client, making audio > incomprehensible. > > This happens because when "ph_call_media_start" is called by the user > that accepts a call through "phAcceptCall3", the "eXosip_event_t *je" > parameter is NULL. > On calls that are initiated by the user, this is the parameter that > carries the "ptime" and "fmtp" info used to calculate the final > packetization. > > This issue involves two major points: > > 1- Will we work with different packetizations for incoming and outgoing > audio ? > > 2- Considering that we choose to work with only one packetization for > incoming and outgoing audio, how and where will we make some kind of > negotiation to get this working ? > > As long as I could understand by all the research I've done, one client > MUST provide the packetization expected by the other client (if informed > through "ptime", "mode" or another mean), and incoming and outcoming > packetization COULD be different. > > Nevertheless, for the sake of simplicity and to reduce code changes, I > choose to work with same packetization on both audio channels. > > Since I choose to work with same packetization, I needed to validate the > better way to "save" the packetization info received from the caller, > and make a kind of negotiation to define which attributes received from > the caller that will be "incorporated" on local SDP. > For example: If a caller send a SDP with "ptime=30", or a "mode=30" for > "fmtp" attribute of a iLBC media, I incorporate these values to the > local SDP, so they can be sent back as confirmation to the originator > and handled internally by the code already existent. > > Before I send my patches, that are still demanding some little > adjustments, I would like to get an initial feeling from you of what > I've described above. > > Thanks and best regards, > > _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
