[asterisk-bugs] [JIRA] (ASTERISK-28067) Extra fingerprint attribute in SDP

[Joshua C. Colp (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=244926#comment-244926 ] 

Joshua C. Colp commented on ASTERISK-28067:
-------------------------------------------

If you want to attach a patch for this for reference that is fine, but this is not something I'd see being included without fully supporting optimistic DTLS.

> Extra fingerprint attribute in SDP
> ----------------------------------
>
>                 Key: ASTERISK-28067
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28067
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_sdp_rtp
>    Affects Versions: 13.20.0
>         Environment: A-leg endpoint is configured as 
> media_encryption = dtls
> media_encryption_optimistic = yes
> media_use_received_transport = yes
> In B-leg endpoint there have no any srtp related configuration. 
>            Reporter: Salah Ahmed
>            Severity: Minor
>
> In this above scenario if we make a call between 2 clients and the incoming call has no dtls params in the sdp, the call is successful but in SDP on 200 Ok which asterisk sends to the A-side contains an extra attribute "fingerprint". So A -side endpoint gets confused and ends up rejecting the call.
> In another case, if  media_use_received_transport=no flag and both media_encryption = dtls and media_encryption_optimistic =  yes then call gets answered but media port 0 is sent to the A-Party. So I think it should reject the call if incoming call have no dtls capability as asterisk have no support optimistic dtls.
> we built a simple patch for this issue, this patch does not implement optimistic dtls but with this inbound optimistic will work. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)