To be clear, PJMEDIA_SRTP_OPTIONAL does not require you to call a SIPS URIs. It simply allows SDPs to include both SRTP and RTP. The signaling constraints are driven entirely by the srtp_secure_signaling setting.
The issue you're running into here is this: you've told PJSIP that SRTP is optional. As a result, it should offer both SRTP and non-SRTP when it generates an invite. Now, when you place a call, it adds both SRTP and RTP, but the default setting for srtp_secure_signaling does not allow PJSIP to send an invite containing SRTP invite over a non-TLS connection (understandably, because in most cases this would be pointless because establishing an SRTP call when the keys are exchanged in plaintext is a pointless exercise in security).
Now, as far as I'm aware, there's no way to selectively generate an SRTP or RTP invite based on the scheme of the destination you're calling (which I believe would be ideally what you'd want). However, if you set srtp_secure_signaling to 0, PJSIP will not require that SRTP keys are exchanged via a TLS connection. This should allow you to use PJMEDIA_SRTP_OPTIONAL with non-TLS signaling. Note that it has the side-effect of allowing SRTP keys to be exchanged over any type of connection; however, based on the fact that you already want your client to be able to selectively connect to either secure or insecure transports, I don't think this does much more to compromise security. As long as you ensure that when you truly want a secure call, you will signal over TLS also, it shouldn't be a huge issue.
Probably, the right long-term answer here would be to get your client to always call via SRTP, possibly adding a proxy in the middle where required if you need SRTP termination. However, I assume that's not an option and/or not feasible at this time.
Hopefully, that helps.
Best,
Colin
On Mon, Apr 10, 2017 at 10:15 AM, David Talmage <sip.phone.fan@xxxxxxxxx> wrote:
Thanks, Johan. Perhaps I misunderstood the SRTP settings.
I need a way that I can make calls to both SIP: and SIPS: URIs. When
I make a call to a SIPS: URI, I want to use SRTP.
The code in its current state does not allow me to do that. If
use_srtp is set to PJMEDIA_SRTP_OPTIONAL, the code requires me to call
SIPS: URIs.
The documentation isn't as clear as I need it to be. The
documentation for use_srtp says that I can make SRTP not used at all,
optional, or mandatory. For optional SRTP, the documentation addresses
only incoming calls.
On Mon, Apr 10, 2017 at 4:41 AM, JOHAN LANTZ <johan.lantz@xxxxxxxxxxxxxx> wrote:
> Maybe I misunderstand your question but are you sure you problem is not the acc->cfg.srtp_secure_signaling setting?
>
> If that is set to require a secure signalling transport when SRTP is used, changing the value of pjsua_acc_config.use_srtp is probably not going to help if you use a non secure address.
>
> IIRC pjsua_acc_config.use_srtp basically checks if the sdp info contains RTP/AVP or RTP/SAVP and PJMEDIA_SRTP_OPTIONAL would allow both to pass but that is not related to the sip vs sips in the signalling part.
>
> Johan
>
>
>
> On 07/04/2017, 18:46, "pjsip on behalf of David Talmage" <pjsip-bounces@xxxxxxxxxxxxxxx on behalf of sip.phone.fan@xxxxxxxxx> wrote:
>
>>I think I found a bug in the way that PJSIP handles the SRTP settings.
>>Would someone please confirm this?
>>
>>When pjsua_acc_config.use_srtp is not PJMEDIA_SRTP_DISABLED, PJSIP
>>requires SRTP and all calls must be addressed to a sips: URI. PJSIP
>>rejects calls to sip: URIs with the status code
>>PJSIP_ESESSIONINSECURE.
>>
>>The behavior I expect is for PJSIP to fall back to an insecure call
>>when the destination URI is sip: and the value of
>>pjsua_acc_config.use_srtp is PJMEDIA_SRTP_OPTIONAL.
>>
>>The mistake is in pjsua_media.c:call_media_init_cb(). Here is the code:
>>
>> /* Check if SRTP requires secure signaling */
>> if (acc->cfg.use_srtp != PJMEDIA_SRTP_DISABLED) {
>> if (security_level < acc->cfg.srtp_secure_signaling) {
>> err_code = PJSIP_SC_NOT_ACCEPTABLE;
>> status = PJSIP_ESESSIONINSECURE;
>> goto on_return;
>> }
>> }
>>
>>I don't have a working solution yet. It looks easy but perhaps there
>>will be unintended consequences.
>>
>>_______________________________________________
>>Visit our blog: http://blog.pjsip.org
>>
>>pjsip mailing list
>>pjsip@xxxxxxxxxxxxxxx
>>http://lists.pjsip.org/mailman/listinfo/pjsip_lists. pjsip.org
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@xxxxxxxxxxxxxxx
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists. pjsip.org
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists. pjsip.org
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
