[asterisk-dev] the strictrtp feature is almost useless

Klaus Darilion klaus.mailinglists at pernau.at
Fri Oct 15 12:30:04 CDT 2010

Am 15.10.2010 17:29, schrieb Kevin P. Fleming:
> On 10/15/2010 10:26 AM, Klaus Darilion wrote:
>> Theoretically you are correct, but practically the peers IP address used
>> for SIP signaling is a good hint were the RTP will come from.
>> This is e.g. used in rtpproxy to allow "latching" only from the clients
>> IP address.
>> Of course this again give problems if the attacker is behind the same
>> NAT as the user, but practically it solves many scenarios...
> In my experience (and that of many others on this list) who use Asterisk
> with SIP service providers, this will fail completely, because the SIP
> signaling originates from a softswitch/SBC/proxy, and the media
> originates from one of many media gateways. This sort of method would
> only really be applicable to 'endpoints' that are being used, not
> trunking or similar services.

True - I do not use SBCs.

But if Asterisk is located behind a SBC (with media relay) then Asterisk 
can not do anything and has to trust the SBC, so the SBC should 
implements such features.

Regarding connections to media gateways I think the problem arises when 
different policies are needed on one Asterisk server. E.g. SIP clients 
(home customers) connect to the Asterisk server (directly) (lets call 
this UNI-user-network-interface) and the Asterisk server forwards calls 
to several PSTN gateway providers (lets call this 
NNI-network-network-interface). IMO it would be nice to have different 
media IPs with different policies. The Linux server could have 2 
interfaces (different IPs) - one is used by Asterisk for UNI and one for 
NNI. Then for example a certain RTP-latching algorithm is used on the 
UNI side and different policy on the NNI side (just like some SBCs offer).

Maybe a cool feature for Asterisk 1.10? :-)


More information about the asterisk-dev mailing list