[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? :-)
regards
Klaus
More information about the asterisk-dev
mailing list