I’m trying to use SRTP between 2 SNOM 710 phones, with FreePBX (2.11) in the middle.
Without SRTP, both SNOM phones have direct media between each other after REINVITE was initiated by Asterisk. But this REINVITE is not initiated anymore as soon as SRTP is used so in this case Asterisk B2BUA stays in the middle and tha’s not what I want.
Both SNOM phones have identical codec settings, and in FreePBX their extensions are both programmed with canreinvite=yes, no recording options, no nat, no dial commands.
Advanced Freepbx Device settings have SIP encryption = yes and canreinvite (directmedia) = yes.
Is there a solution for this - because I don’t see a reason why the use of SRTP would stop directmedia working. In fact SRTP is even more secure end-to-end compared to a B2BUA staying in the middle !
I see, but couldn’t it be solved in following way : suppose reinvite is initiated as usual, and then both endpoints use their own key for their incoming RTP stream - as if they have setup a direct connection ? The reinvite provides again SDP info, so the SRTP processing can then restart end-to-end for each stream. It is an important element in a hosted PBX environment, because it’s not only bandwidth wasting on the hosting link, but also performance wasting on the PBX server.
only problem is that Asterisk does not initiate a reinvite from the moment SRTP if used…
is there some setting in Asterisk to force reinvite in any case ?
This seems to be an Asterisk wish list item. You should probably raise it on the Asterisk developer mailing list.
At the moment I can’t think of any trust issues that would make forwarding this information over an authenticated channel breach any trust relationships.
ok - I will put it as a feature request on Asterisk. Hope they react on it because I believe that this is a “show stopper” for hosted PBX solutions based on Asterisk.
There are hundreds of thousands of Asterisk based hosted systems out there, so it might not be as much of a show stopper as you think. Asterisk is designed to a B2BUA so removing it from the audio stream renders many of the useful features of Asterisk moot.
In my usecase (Virtual PBX with IPphones) this is only partially true because many of the Asterisk features are “DTMF controlled” features which are obsolete or even conflict with features offered via IPphones or soft clients. Only in special cases (like voice recording) or transcoding (although better avoid this by using common set of voice codecs) Asterisk should really stay in the voice path. In all other cases it causes only bandwidth and CPU wasting, and even extra cost on bandwidth (with QOS !) for hosted solutions.