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
Mauro Sérgio Ferreira Brasil wrote:
Hi Vadim,
I remember of seeing this "EXOSIP_FORCE_PTIME" on some part of the code.
Will this fixes provide the necessary means to handle a "ptime"
received during a call received? (This is my principal demand here...)
Anyway, I'll keep you informed of my further analysis about the
maintenance as I've suggested to you, if I could put a hand on it.
Thanks,
Mauro.
Vadim Lebedev escreveu:
Mauro,
Actually, if you'll look into source of QuteCom, you'll see that there
is alredy
support for setting ptime on outgoing SDP (look for usage of
getenv("EXOSIP_FORCE_PTIME"))
In phmedia-audio.c there is support for packet resegmenattion too -
handling of unexpected packet size,
this stuff is somewhat buggy we're going to commit fixes today....
Thanks
Vadim
Mauro Sérgio Ferreira Brasil wrote:
Vadim,
Yeah... that was funny... :-)
As funny as myself realizing the scenario you put on your reply, right
after I've clicked on "Send Now"... I remembered Hommer Simpson's usual
screem after he does a very stupid thing :-)
About the list, I was not very clear on my explanation.
I was intending to send all messages to the list, but just direct the
arguing to you. I need more practice on english language... :-)
When I've sent you the email, I was considering the INVITE as qutecom
libraries send it by now that, if I'm not wrong, don't have a "ptime"
attribute. On this scenario I think we wouldn't have problems.
Unfortunately, our customer has already demanded an adjustment to add
this parameter when their version of "g729" is used.
So, you are right, we need to work with different packetization sizes.
Anyway, this is the best thing to do, despite of the painfull
consequences :-)
Now, I need to be very frank with you.
Althought I want very much to make this patch, it could demand a
considerable amount of time (maybe not) and I need to validate with our
customer whether it will be done by now.
I think the best place to make it work is on "ph_call_media_start"
where we will invoke methods that will get "ptime" and "fmtp" values
that are used today, extracting them from local and remote SDP and
associating them with correct "ipayloads" and "opayloads" (hum... it
seems it will be easier I firstly thought).
That way, the rest of code will be kept without changes, right ?
Thanks,
Mauro.
Vadim Lebedev escreveu:
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,
--
| 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 |
--
TQI - Technology and Quality on Information
| 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 |
|
