Hi Colin,
We have a fix for this on https://trac.pjsip.org/repos/ticket/2014, thanks for the report!
Riza
Best Regards,
Riza
On Wed, Apr 19, 2017 at 10:52 AM, Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
Hey list,I believe there's a bug in SRTP negotiation in trunk - or at least very odd behavior.Client generates an SDP with 4 crypto lines (tags 1, 2, 3, 4)Remote endpoint selects crypto tag 3, and responds with "crypto:3"Client generates an UPDATE request after performing STUN bindings, UPDATE request include "crypto:1" <--- this already seems weird, but it gets strangerRemote endpoint reponds with crypto tag "crypto:3" <-- this could be an issue in freeswitch, but I believe FS is trying to keep the same crypto active on an update, but this also isn't the issueClient attempts to place the call on hold, generates another SDP with "crypto:1"Server reponds with "crypto:1" (since FS renegotiates SRTP on an INVITE)PJSIP fails to update media channel #0, because it says the crypto name for the given tag did not matchI believe this was introduced by https://trac.pjsip.org/repos/changeset/5500 which attempts to restart crypto numbering from 1 on a re-invite. I believe this ticket is missing a critical step, though. If cryptos can be re-numbered mid-call, then any state associated with previous tag numbers should be cleared when new crypto information is written into that spot. I believe in this case, PJSIP received "crypto:1" back from the remote, and it looked at crypto:1 that it created back when it initially generated the call, which was a completely different type.Best,Colin
_______________________________________________
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
