OsmocomBB

h1. Call Hold SS

Call Hold (HOLD) is specified together with Call Waiting (CW).

h2. Relevant Specifications

* "3GPP TS 22.083: Call Waiting (CW) and Call Hold (HOLD) supplementary service; Stage 1":http://www.etsi.org/deliver/etsi_ts/122000_122099/122083/14.00.00_60/ts_122083v140000p.pdf

** high-level description + definition

* "3GPP TS 23.083: Call Waiting (CW) and Call Hold (HOLD) supplementary service; Stage 2":http://www.etsi.org/deliver/etsi_ts/123000_123099/123083/14.00.00_60/ts_123083v140000p.pdf

** contains SDL state diagrams for VLR and MSC

* "3GPP TS 24.010: Supplementary services specification":http://www.etsi.org/deliver/etsi_ts/124000_124099/124010/14.00.00_60/ts_124010v140000p.pdf

* "3GPP TS 24.080: supplementary services specification; Formats and coding":http://www.etsi.org/deliver/etsi_ts/124000_124099/124080/14.01.00_60/ts_124080v140100p.pdf

* "3GPP TS 24.083: Call Waiting (CW) and Call Hold (HOLD) supplementary service; Stage 3":http://www.etsi.org/deliver/etsi_ts/124000_124099/124083/14.00.00_60/ts_124083v140000p.pdf

** contains information on signaling on L3 interface between MS and MSC

h2. Notes

* 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

h3. notification of other party

The other party is notified if SS-screening != 0:

** Facility/Invoke/NotifySS/HOLD

h3. HOLD activation

* 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, ...)

h3. RETRIEVE activation

* MS sends RETRIEVE

* MSC responds with RETRIEVE ACK in successful case

* MSC responds with RETRIEVE REJECT in unsuccessful case

h3. 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.

h3. translation to SIP

It seems that "RFC 5359":https://tools.ietf.org/html/rfc5359 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(sendonly)

* the SIP 200 OK in response translates to CC HOLD ACK

* the CC RETRIEVE must be translated to a SIP INVITE(sendrecv)

* the SIP 200 OK in response translates to CC RETRIEVE ACK

Further references:

* Section B.9 of "Q.1912.5":https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.1912.5-201801-I!!PDF-E&type=items explains the detailed mapping between the SDP sendrecv/recvonly/inactive/... mappings

* Section 7.4 of "3GPP TS 29.163":http://www.etsi.org/deliver/etsi_ts/129100_129199/129163/14.06.00_60/ts_129163v140600p.pdf seems to repeat those same mappings?

* "Cisco MGC SIP/ISUP Conversion of HOLD":https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/pgw/9/feature/module/9-7_3_/sip_isup.pdf