Music on Hold
After a call is established, one of the endpoints can put the other endpoint on hold. An application server might intercept the re-INVITE from one endpoint (for putting the other on hold) and implement MoH as follows.
![](img/GUID-C88836A9-E934-403A-AB85-5B7E600671A1-default.gif)
A: Endpoint UA-A sends an offer SDP for hold to SBC-A.
B: SBC-A forwards offer SDP without any cookie since there will be no media going from/to UA-A.
C: SBC-B receives an offer SDP that is addressed to the MS without any cookie.
D: Because there is no cookie in the ingress offer SDP, SD-B generates its own SDES crypto attributes for the egress offer SDP sent to UA-B.
E: SBC-B receives am answer SDP from UA-B.
F: SBC-B sends its answer SDP without any cookie and encrypts SRTP packets going to UA-B. Note that there will be no SRTP packets going from UA-B to SBC-B.
As a result, MoH is heard by UA-B as it decrypts SRTP packets encrypted by SBC-B. When UA-A resumes, the steps to establish media between UA-A and UA-B will be the same as the steps used for call setup.
Once the media is reestablished between UA-A and UA-B media travelling between the two UAs will not be decrypted by either SBC.