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

Asterisk Team (JIRA) noreply at issues.asterisk.org
Fri Sep 21 08:50:54 CDT 2018


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

Asterisk Team commented on ASTERISK-28067:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

> 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)



More information about the asterisk-bugs mailing list