Anybody care to offer a perspective on this one ....
Is it a valid thing to change the SRTP media encryption keys during a session and signal this using a re-INVITE? In RFC4568 (SDES) there is no exact statement regarding this. In fact section 5.1.4. “Modifying the Session” suggests that this should work: “Once a media stream has been established, it MAY be modified at any time, as described in RFC 3264, Section 8. Such a modification MAY be triggered by the security service, e.g., in order to perform a re-keying or change the crypto-suite. If media stream security using the general security descriptions defined here is still desired, the crypto attribute MUST be included in these new offer/answer exchanges.”
Of course standards and implementation are two different things!
To give this some context, lets assume I have an architecture with SRTP end to end (but no TLS for now). The Customer call comes in and goes to GMS for in queue treatment. An agent comes available and is routed to their IP Phone. GMS is used to play a whisper. The call is put on hold (GMS) and later the call is then transferred to another agent / IP Phone.
In this scenario the SDES keys (crypto=) keeps changing as the SIP endpoint keeps changing. The Customer leg via a SBC also needs to know. Therefore the SBC needs to be re-INVITED with the new keys.
In my mind this is no different to mid call renegotiation if the codec on the Customer end changed for some reason.
Views?
