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 stranger Remote 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 issue Client 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 match I 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

Hi Colin, We have a fix for this on https://trac.pjsip.org/repos/ticket/2014, thanks for the report! Best Regards, Riza On Wed, Apr 19, 2017 at 10:52 AM, Colin Morelli <colin.morelli@gmail.com> 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 > stranger > Remote 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 issue > > Client 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 match > > I 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@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >