Call Hold SS¶
Call Hold (HOLD) is specified together with Call Waiting (CW).
- 3GPP TS 22.083: Call Waiting (CW) and Call Hold (HOLD) supplementary service; Stage 1
- high-level description + definition
- 3GPP TS 23.083: Call Waiting (CW) and Call Hold (HOLD) supplementary service; Stage 2
- contains SDL state diagrams for VLR and MSC
- 3GPP TS 24.010: Supplementary services specification
- 3GPP TS 24.080: supplementary services specification; Formats and coding
- 3GPP TS 24.083: Call Waiting (CW) and Call Hold (HOLD) supplementary service; Stage 3
- contains information on signaling on L3 interface between MS and MSC
- the HOLD state is not a state in the 24.007/24.008 call control state machine, but an auxiliary state machine:
- Idle before/after any HOLD or after HOLD REJECT.
- Hold request HOLD sent but no response yet
- Call Held after successful HOLD operation
- Retrieve request RETRIEVE sent but no response yet
notification of other party¶The other party is notified if SS-screening != 0:
- MS sends HOLD
- MSC responds with HOLD ACK in successful case
- MSC responds with HOLD REJECT in error case (#29: rejected, #50: not subscribed, #69: not implemented, ...)
- MS sends RETRIEVE
- MSC responds with RETRIEVE ACK in successful case
- MSC responds with RETRIEVE REJECT in unsuccessful case
altenating between calls¶
The HOLD/RETRIEVE messages contain the regular CC transaction identifer, which is used to differentiate different calls. You can put one call on hold and subsequently retrieve another.
translation to SIP¶
It seems that RFC 5359 explains how to implement call hold on the SIP side.http://www.tech-invite.com/fo-sip/tinv-fo-sip-service-01.html features a graphical message sequence chart. Combined with what we know about the GSM side of things, it looks like
- the CC HOLD must be translated to a SIP INVITE
- the SIP 200 OK in response translates to CC HOLD ACK
- the CC RETRIEVE must be translated to a SIP INVITE
- the SIP 200 OK in response translates to CC RETRIEVE ACK
- Section B.9 of Q.1912.5 explains the detailed mapping between the SDP sendrecv/recvonly/inactive/... mappings
- Section 7.4 of 3GPP TS 29.163 seems to repeat those same mappings?