7 Jul
2009
7 Jul
'09
3:28 p.m.
Iñaki Baz Castillo schrieb:
2009/7/7 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
In this case you can use mediaproxy or someone have to change the
rtpproxy module to rely on dialog module to get information about
session updates (as mediaproxy module does)
regards
klaus
cc-ed the k users list, just in case someone pops
up a better idea.
Having to invoke rtpproxy in each message (initial INVITE, reply,
ACK?, re-INVITE...) makes the config file really ugly.
While it provides flexibility (using different flags for offers and
responses) I think it's not needed in most of the cases.
If would be really great a rtpproxy function working for transaction
(instead of working for each message). For example:
if (is_method("INVITE")) {
tran_use_rtpproxy(FLAGS);
} This "tran_use_rtpproxy()" could handle
rtpproxy invocations for the
request (if it has SDP) for the responses (if they have SDP), for ACK
(if it's has SDP) and for CANCEL. It would add some info to the
transaction and some callbacks to tm module to invoke rtpproxy
functions. This is, a rtpproxy function depending on TM module.