[RTPproxy Devel] [RTPproxy Users] patch - per-channel timeouts, notification on timeout

[Maxim Sobolev]

Daniel Pocock wrote:
>> 1. I would like the make it possible to enable/disable "disconnect 
>> notification" feature on the per-call basis. Basically, the idea is that 
>> the client code will pass the address that it wants rtpproxy to send the 
>> disconnect notification to with the "create session" request. This would 
>> allow several "disconnect-aware" clients to share one proxy.
>>
>>   
> The socket information is now encapsulated in a struct, and each 
> rtpp_session keeps a pointer to the struct.
> 
> Currently, all pointers are initialised to point to a single struct in 
> the config struct, the command for controlling this on a per-call basis 
> can be added later.

The problem with adding this functionality as is now and extending it 
later is that rtpproxy will have to support both ways - notify all, and 
notify on per-call basis. I don't think that we really need this. The 
change to allow notifications to be enabled on per-calls basis is pretty 
trivial, so that doing it now we will save us from either breaking 
protocol later or carrying compatibility code. I think the best way to 
achieve that is to add flag to the U command to enable notification to 
that single socket (if any specified) now, while extend protocol later 
to allow for the optional socket name parameter to be passed somehow 
along with that.

>> The important issue here is the security - allowing rtpproxy opening 
>> arbitrary local socket could be dangerous, my suggestion is that on 
>> startup the proxy should be supplied with the list of allowed 
>> "disconnect sockets" and only allow client requesting notification to 
>> any of those.
>>   
> Maybe we can use my `-n' command line parameter, with a colon-separated 
> list of permitted sockets?  Currently, it only accepts a single socket.  
> If no socket is specified, then there will be no notifications (the old 
> behaviour).

I see no issues with that.

> Incidently, for the purposes of using multiple products with the proxy, 
> I prefer to start different instances of the proxy.  Each instance is 
> bound to a specific IP address rather than 0.0.0.0.  Each B2BUA or SER 
> is on the same IP as the associated RTPproxy, and all of them can use 
> port 5060, even on the same machine.

Well, this is another valid usage scenario, but it doesn't make my 
scenario less valid. Not only it's for sharing purposes but also for the 
cases when you only need notification for some particular calls, not all 
of them.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com