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.

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.