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@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
