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

[Joshua C. Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp updated ASTERISK-28067:
--------------------------------------

    Status: Open  (was: Triage)

> res_pjsip_sdp_rtp: 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
>              Labels: patch, pjsip
>         Attachments: extra_attribute_in_sdp.patch
>
>
> 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)