[Kamailio-Users] [SR-Users] force_rtp_proxy() vis-a-vis BYE

[Daniel-Constantin Mierla]

On 07/07/2009 06:36 PM, Alex Balashov wrote:
> I somewhat object to the idea that rtpproxy control socket functions 
> should be exposed in the nathelper module.

maybe there was some misunderstanding. What we discussed here is not 
when to use rtpproxy, but if you do it for initial invite, then all 
subsequent requests in the dialog will be automatically handled.

When and why one does rtp relaying is still a decision of the script 
writer. From this perspective, maybe suggested name for RR parameter is 
not the best, should be something "rtpp=yes".

Cheers,
Daniel

>   Why does mediaproxy get its own module?  What if I want to relay 
> media for some purpose other than far-end NAT traversal (for example, 
> passive in-line tap / monitor-port based call recording)?
>
> Iñaki Baz Castillo wrote:
>
>> 2009/7/7 Daniel-Constantin Mierla <miconda at gmail.com>:
>>>> Hi Daniel, please clarify me is your suggestion would require running
>>>> (in the config script) the function rtpproxy_session_update() in
>>>> onreply_route.
>>>>
>>> no. The script needs just rtpproxy_session_init(). All the rest is done
>>> automatically in the module.
>>>
>>> Inside a module, you can register functions that are executed before
>>> executing the configuration file for each sip message.
>>>
>>> So, here is what is needed:
>>> - registers callback functions for pre-script event for reply and 
>>> request
>>> - if it is an initial invite, then skip processing in the callback
>>> - if it is a reply or a in-dialog request, search for 
>>> Record-Route/Route
>>> headers matching "myself"
>>> - if the R-R/R headers have "nat=xyz", then process
>>> rtpproxy_session_update()
>>> - export to config file the function rtpproxy_session_init() that 
>>> has to be
>>> called for initial invite and append to R-R the parameter "nat=xyz" 
>>> (this
>>> should be configurable)
>>>
>>> In the config file, just call rtpproxy_session_init() and that is. 
>>> Probably
>>> this function needs some flags as parameter to control the 
>>> behaviour, flags
>>> that could be added as value to nat parameter, if needed later.
>>
>> ok, that sounds really nice :)
>>
>
>

-- 
Daniel-Constantin Mierla
http://www.asipto.com/