13 Commands for enhanced support of dialling

27.0073GPPAT command set for User Equipment (UE)Release 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

13.1 General

This clause defines commands that a TE may use when dialling. These commands can be used instead of ATD that does not support dialling of URIs.

Clause 13.2 defines commands for dialling (direct dialling and dialling from phonebook) as well as hangup of these calls.

Clause 13.3 contains relevant examples.

13.2 Commands for dialling

13.2.1 Dial URI +CDU

Table 13.2.1-1: +CDU action command syntax

Command

Possible response(s)

+CDU=<action>[,<URI>[,<client>[,<mpidx>[,<CLIR_OIR>[,<CUG_pointer>[,<type_of_call>]]]]]]

+CME ERROR: <err>

when <action>=0 and command successful:

[+CDUT: <URI_scheme>[,<client>]

[<CR><LF>+CDUT: <URI_scheme>[,<client>]]

[…]]

when <action>=1 and command successful:

[+CDU: <ccidx>]

when <action>=1 and command unsuccessful:

[+CDUI: <cause>]

+CDU=?

+CDU: (list of supported <URI_scheme>s)

Description

Execution command can be used to dial a URI (with <action>=1) for initiating communication using the specified communication client with the specified media profile. With <action>=0 the command can query which clients are supported for the URI types supported.

When the command is used to query the supported URI types (i.e. <action>=0), the URI types are provided by +CDUT: <URI_scheme>. When the command is used to dial a URI (i.e. <action>=1) and the dialling succeeds the command is terminated by +CDU: <ccidx> and OK. The parameters <CLIR_OIR> and <CUG_pointer> are used to set the per call basis values of the supplementary services CLIR / OIR and CUG.

The unsolicited result code +CDUU: <ccidx>,<code> can be subsequently provided to give further basic information about the call as it progresses. The value of the <ccidx> is kept until the call is released. See command +CMCCS and unsolicited result code +CMCCSI for provision of additional information about the call setup.

If "Call control by USIM" see 3GPP TS 31.111 [92] clause 4.5 is activated by the USIM, it is the responsibility of the communication client to perform any required call control verification according to the procedures defined in 3GPP TS 31.111 [92] clause 7.3 prior to the execution of the call setup.

When call control by USIM is applicable, the communication client shall perform the call control (for example by using the Commands for USIM application toolkit, see clause 12) and act upon the result of the call control as follows:

– if call control by USIM performs no modifications to the call request, the call setup shall be executed without any changes to the data;

– if call control by USIM modifies the call request, the call setup shall be executed using the modified data as provided by the call control;

– if call control by USIM modifies the call request to a different service, the appropriate AT command(s) for that service shall be executed; and

– if call control by USIM rejects the call request, the call setup shall not be executed.

If the attempt to dial does not succeed, the command is terminated by ERROR / +CME ERROR or +CDUI: <cause> and OK. Refer clause 9.2 for possible <err> values.

Test command returns values supported as a compound value.

Defined values

<action>: integer type

0 Query supported communication clients for the supported URI types. Execution command +CDU=0 returns a line of intermediate result code +CDUT: <URI_scheme>[,<client>] for every supported <URI_scheme>.

1 Dial <URI> using the indicated communication client with the indicated media profile.

<URI>: string type. URI including the prefix specifying the URI type. The URI may include URI parameters. The used character set should be the one selected with command select TE character set +CSCS.

<CLIR_OIR>: integer type. Indicates per call basis changes provided to the supplementary service CLIR / OIR. See +CLIR for further information of the related parameters.

0 No per call based changes to CLIR / OIR, the settings with +CLIR apply

1 Restrict the CLI presentation for the current call (CLIR / OIR invocation)

2 Allow CLI presentation for the current call (CLIR / OIR suppression)

<CUG_pointer>: integer type. Indicates per call basis changes provided to the supplementary service closed user group. See +CECUG for further information of the related parameters.

0 No per call basis changes to CUG

1-n Indicates the CUG index to use for this call. The CUG index and corresponding values used as set with command +CECUG (enable CUG temporary mode). The maximum value of n is implementation specific.

NOTE 1: 3GPP TS 22.085 [21] indicates that each individual subscriber can be a member of a maximum of 10 CUGs.

<type_of_call>: integer type. Indicates type of call on per call basis.

0 Normal call

1 Dual radio voice call continuity call.

<URI_scheme>: string type represented with IRA characters. Parameter identifies supported URI scheme. This parameter shall not be subject to conventional character conversion as per +CSCS.

"sip" Internet Assigned Number Authority (IANA) registry as per RFC 3969 [113], used with Session Initiation Protocol (SIP), see RFC 3261 [111].

"tel" Internet Assigned Number Authority (IANA) registry as per RFC 5341 [114], used with SIP, see RFC 3966 [112].

"urn" Internet Assigned Number Authority (IANA) registry according to RFC 2141 [116], only used with SIP in combination with a suitable uniform resource name (URN) namespace.

NOTE 2: The URN namespace "service" listed in the Internet Assigned Number Authority (IANA) registry according to RFC 3406 [117] is an example of a namespace that can be used in SIP in combination with the URI scheme "urn". Not all top-level service labels listed in the Internet Assigned Number Authority (IANA) registry according to RFC 5031 [118] need to be supported in combination with the URN namespace "service".

<client>: integer type. Communication client indication. The default value is implementation specific.

1 MMTel. The UE procedures in 3GPP TS 24.173 [87] apply.

128 – 255 Reserved for vendor specific communication clients.

<mpidx>: integer type. Media profile identification number. The parameter is local to the TE-MT interface. The range of permitted values (minimum value = 1) is returned by the test form of the command +CDEFMP. When +CDU is used for dialling (i.e. with <action>=1) this number can be provided to point to a particular media profile. The provided media profile identification number is the number being returned by +CDEFMP when defining the media profile. Usage and value of a default media profile is implementation specific.

<ccidx>: integer type. Call identification number as described in 3GPP TS 22.030 [19] clause 6.5.5.1. This number can be used in +CHLD command operations. Value range is from 1 to N. N, the maximum number of simultaneous call control processes is implementation specific.

NOTE 3: When +CMCCS is supported, the call identification number is not reset until the unsolicited result code +CMCCSI has indicated that the <ccstatus>=1 (Idle).

<code>: string type represented with IRA characters. Cause codes giving main call state information. Intermediate call status responses can be reported using the unsolicited result code +CMCCSI (see command +CMCCS). This parameter shall not be subject to conventional character conversion as per +CSCS.

"BUSY" Busy signal detected

"ANSWERED" Remote party has answered and the connection between A and B has been established

"NO ANSWER" Connection completion timeout

"CONNECTION TERMINATED" The connection is terminated from either the remote party or the network, or the attempt to establish the call setup is unsussessful

NOTE 4: The cause code "CONNECTION TERMINATED" also covers all other situations where a call is unsuccessfully terminated. Examples of this are all types of network congestion or lack of radio coverage.

<cause>: integer type. Reason code providing further details why the call setup fails in the terminal before signalling towards the network is initiated.

0 Outgoing call attempt rejected by (U)SIM/ME, unspecified

1 Outgoing call attempt rejected by barring services in the SIM/ME

Implementation

Optional.

13.2.2 Dial URI from phonebook +CDUP

Table 13.2.2-1: +CDUP action command syntax

Command

Possible response(s)

+CDUP=<pb_field>,<str>[,<client> [,<mpidx>[,<storage>]]]

+CME ERROR: <err>

when command successful:

[+CDUP: <ccidx>]

+CDUP=?

Description

Execution command dials a URI for initiating communication using the specified communication client with the specified media profile by referencing either the alphanumeric phonebook field, or the index or entry-number in the phonebook. Supported clients URI schemes are those returned with +CDU=0. If parameter <storage> is not included, the relevant phonebook is specified by the current +CPBS setting. If the referenced URI is not found, OK is returned and nothing is dialled.

+CDUP=0,<str> originates a call to the first URI found in the selected phonebook which has a partial or full match to <str>. The mechanism to search for the first match through a phonebook is implementation specific. Upon no match in the selected phonebook, it is manufacturer specific if and what further phonebook memories are searched.

+CDUP=1,<str> originates a call to the URI in memory location <str>, where <str> must contain a decimal number. The index or entry-number in the phonebook is expressed by <str>.

How the string of digits or the index or entry-number is associated with entries is implementation specific.

The command is terminated by +CDUP: <ccidx> and OK or ERROR / +CME ERROR. Refer clause 9.2 for possible <err> values.

Defined values

<pb_field>: integer type

0 Refers alphanumeric field of the phonebook. <str> may contain valid characters for alphanumeric field of the selected phonebook.

1 Refers index or entry-number in the phonebook.

<str>: string type. Valid characters are governed by <pb_field>.

<storage>: string type. Supported values are the same as that supported for <storage> of +CPBS.

<client>: integer type. Communication client indication.

1 MMTel. The UE procedures in 3GPP TS 24.173 [87] apply.

128 – 255 Reserved for vendor specific communication clients.

<mpidx>: integer type. Media profile identification number. The parameter is local to the TE-MT interface. The range of permitted values (minimum value = 1) is returned by the test form of the command +CDEFMP. The provided media profile identification number is the number being returned by +CDEFMP when defining the media profile. Usage and value of a default media profile is implementation specific.

Implementation

Optional.

13.2.3 Hangup of current calls +CHCCS

Table 13.2.3-1: +CHCCS action command syntax

Command

Possible response(s)

+CHCCS=<ccidx>[,<cause>]

+CME ERROR: <err>

when <ccidx>=value>0 is inserted and command successful:

[+CHCCSI: <ccidx>]

when <ccidx>=0 is inserted and command successful:

[+CHCCSI: <ccidx>

[<CR><LF>+CHCCSI: <ccidx>]

[…]]

+CHCS=?

Description

Execution command causes the TA to initiate hangup and subsequently perform call clearing of the call for which a <ccidx> was provided when the call was detected in the MT. The parameter <cause> can be added to indicate particular information on the cause for call clearing. Setting the parameter <cause> to values 2 or 3 is typically relevant for call clearing before a call has been established (e.g. an incoming or waiting call). The parameter <cause> is ignored by the lower layers if it is not according to the signalling procedures in question.

A special form of the execution command, +CHCCS=0, causes the TA to initiate hangup and subsequently perform call clearing of all calls for which a <ccidx> was provided when the call was detected in the MT. The parameter <cause> will be ignored if <ccidx>=0.

The information text +CHCCSI: <ccidx> is provided for each call where a successful hangup is initiated as result of the +CHCCS. If no hangup is initiated, no information text is provided before OK is returned.

NOTE 1: The command +CHCCS=0 will initiate hangup of all calls with a <ccid>. This also applies to calls on hold and call waiting calls.

Refer clause 9.2 for possible <err> values.

Defined values

NOTE 2: When +CMCCS is supported, the call identification number is not reset until the unsolicited result code +CMCCSI has indicated that the <ccstatus>=1 (Idle).

<cause>: integer type. Proposed cause value for call clearing.

0 No particular cause indicated

1 Cause "Normal call clearing" (value 16), see 3GPP TS 24.008 [8] table 10.5.123 or BYE request, see RFC 3261 [111] clause 15.1

2 Cause "Call rejected" (value 21), see 3GPP TS 24.008 [8] table 10.5.123 or "488 Not Acceptable Here", see RFC 3261 [111] clause 21.4.26

3 Cause "User busy" (value 17), see 3GPP TS 24.008 [8] table 10.5.123 or "486 Busy Here", see RFC 3261 [111] clause 21.4.24

Implementation

Mandatory when +CDU is implemented in the TA.

13.2.4 Define media profile +CDEFMP

Table 13.2.4-1: +CDEFMP parameter command syntax

Command	Possible response(s)
+CDEFMP=[<mpidx>][,<SDP_md>]	+CME ERROR: <err> When no <mpidx> but <SDP_md> provided and command successful: [+CDEFMP: <mpidx>]
+CDEFMP?	[+CDEFMP: <mpidx>,<SDP_md> [<CR><LF>+CDEFMP: <mpidx>,<SDP_md> […]]]
+CDEFMP=?	+CDEFMP: (range of supported <mpidx>s)

Description

A media profile is identified by its media profile identification number. A media profile defines an SDP media description to be used in SDP offers and SDP answers. Media profiles can be used with +CDU and +CDUP when dialling URIs.

The set command specifies the SDP media description for a media profile identified by the (local) media profile identification number, <mpidx>. When no <mpidx> value is provided then a new SDP media description is defined and the media profile’s identification number is returned by the command’s response. When an <mpidx> value is provided, the definition of the SDP media description identified by the media profile identification number <mpidx> is replaced with the SDP media description provided by the command.

A special form of the set command, +CDEFMP=<mpidx> causes the SDP media description for the indicated media profile to become undefined. Further, +CDEFMP= causes the SDP media description for all defined media profiles to become undefined.

The read command returns a list of all defined media profiles.

The test command returns values supported as a compound value.

Refer clause 9.2 for possible <err> values.

Defined values

<SDP_md>: string type represented with IRA characters. SDP media description including media level SDP lines. This parameter shall not be subject to conventional character conversion as per +CSCS.

This parameter can contain the following types of SDP lines: SDP m-lines, SDP a-lines and partial SDP m-lines.

The communication client in the MT shall take into account SDP a-line rtpmap and fmtp attributes when negotiating media. Which other attributes in media level SDP a-lines are taken into account by the communication client is implementation specific.

Partial SDP m-lines include nothing but a media type.

For every media either an SDP m-line or a partial SDP m-line must be provided.

SDP m-lines indicate that the described media is encoded/decoded outside the MT.

Partial SDP m-lines indicate that the described media is encoded/decoded by the MT. When negotiating media the MT adds payload information to the partial SDP m-line.

The communication client in the MT shall use the provided SDP line information when negotiating media. The communication client shall add other SDP lines required for negotiating media.

Informative examples

The MT handles encoding and decoding of audio media, and the TE supports two types of video media, as described by the following SDP lines:

m=audio
m=video 99 98
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=4D4033
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=1

To indicate its support for both audio and video media for an incoming or outgoing call, the TE uses the following <SDP_md>:

"m=audio\0D\0Am=video 99 98\0D\0Aa=rtpmap:99 H264/90000\0D\0Aa=fmtp:99 profile-level-id=4D4033\0D\0Aa=rtpmap:98 MP4V-ES/90000\0D\0Aa=fmtp:98 profile-level-id=1"

The TE intends to offer a file transfer over MSRP, as described by the following SDP lines:

m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg

When proposing the MSRP file transfer to the remote party, the TE uses the following <SDP_md>:

"m=message 7654 TCP/MSRP *\0D\0Aa=sendonly\0D\0Aa=accept-types:message/cpim\0D\0Aa=accept-wrapped-types:*\0D\0Aa=path:msrp://atlanta.example.com:7654/jshA7we;tcp\0D\0Aa=file-selector:name:\22My cool picture.jpg\22 type:image/jpeg"

NOTE: The SDP i-line is not provided as part of the <SDP_md> value.

Implementation

Optional.

13.2.5 Control and modify media description +CCMMD

Table 13.2.5-1: +CCMMD parameter command syntax

Command	Possible response(s)
+CCMMD=<ccidx>,<neg_status>[,<SDP_md>]
+CCMMD?
+CCMMD=?

Description

This command allows control of the media used in a multimedia call. The command can be used to initiate modification of the media of an ongoing call, to accept, modify or reject incoming changes in media or to accept, modify or reject the media for an incoming call. Supported media types are typically audio, video and messaging (MSRP).

When <ccidx> matches the index of an ongoing call, the TA/MT will attempt to add or remove media to the call by triggering an SDP renegotiation over the SIP protocol.

When <neg_status>=1, the set command requests an unconditional change the media of the call to that described by <SDP_md>.

When <neg_status>=2, the set command proposes a change of media to that described by <SDP_md>, to which the remote party has to respond before the media of the call is changed. The response from the remote party will be indicated in a +CMCCSI unsolicited result code. If the remote party accepts the change of media, the <neg_status> value in +CMCCSI will be set to 3. If the remote party rejects the change of media, <neg_status> will be set to 4. In both cases the <SDP_md> value in +CMCCSI will describe the currently active media of the call (if any).

If the remote party unconditionally changes the media of the call, this will be indicated in a +CMCCSI unsolicited result code, with <neg_status>=1 and <SDP_md> containing the updated (and now active) media description.

If the remote party proposes to change the media of an ongoing call, this will be indicated in a +CMCCSI unsolicited result code, with <neg_status>=2. The set command is used to respond to the proposal, either by accepting it by setting <neg_status>=3, by rejecting it by setting <neg_status>=4, or indicate that a subset of the incoming proposal is accepted by setting the <neg_status>=3 along with the <SDP_md> containing the subset of the incoming proposal is acceptable.

When the MT receives an incoming call from a remote party, the +CMCCSI unsolicited result code will be sent to the TE with <neg_status>=2. This proposed media for the new call is either accepted, modified or rejected as described above.

Defined values

<ccidx>: integer type. Call identification number as defined in the +CMCCS and +CLCCS commands.

<neg_status>: integer type

1 The <SDP_md> parameter describes the desired set of media for the call.

2 The <SDP_md> parameter describes a proposal for a new set of media for the call.

3 Accept the most recently received media proposal. The <SDP_md> parameter describes the accepted media for the call.

4 Reject the most recently received media proposal.

<SDP_md>: string type represented with IRA characters. Media description as per the +CDEFMP command. This parameter shall not be subject to conventional character conversion as per +CSCS.

Implementation

Optional.

13.3 Informative examples

Below is an example where a voice call originated with +CDU is placed to a tel-URI. This example outlines how the call is initiated by the AT command +CDU, and how the unsolicited result code +CDUU is used to indicate how the call-setup progress until it is terminated. Both successful and unsuccessful outcome of a call attempt is shown in the example.

AT+CDU=1,"tel:+47-123-45678" (Voice call initiated)

+CDU: 2 (Call initiated, call identification number 2 provided)

OK (Call initiation successful)

(Call setup progress, unsolicited result codes appear as appropriate)

(If call is answered by the remote party)

+CDUU: 2,"ANSWERED" (Remote party has answered)

(If remote party does not answer)

+CDUU: 2,"NO ANSWER" (Connection completion timeout)

(If remote party is busy)

+CDUU: 2,"BUSY" (Busy signal detected)

(If call is terminated from remote party)

+CDUU: 2,"CONNECTION TERMINATED" (Connection terminated from remote party)

(If call is terminated from calling party)

AT+CHCCS=2 (Connection with call identification number 2 terminated from calling party)

+CHCCSI: 2

Below is an example where a multimedia-call (voice) originated with +CDU is placed to a SIP-URI. This example outlines how the call is initiated by the AT command +CDU, and how the unsolicited result codes +CDUU and +CMCCSI are used to indicate how the call-setup progress until it is terminated. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2.

AT+CDU=1,"sip:veronica@university.org" (Multimedia-call (voice) initiated)

+CDU: 4 (Call initiated, call identification number 4 provided)

OK (Call initiation successful)

(+CDUU and +CMCCSI appear as appropriate)

+CMCCSI: 4,0,0,0,"",0,2,0,1,0,"sip:veronica@university.org",0,0 (Call setup is started)

+CMCCSI: 4,0,0,0,"",0,3,0,1,0,"sip:veronica@university.org",0,0 (Call is in progress)

+CMCCSI: 4,0,0,0,"",0,4,0,1,0,"sip:veronica@university.org",0,0 (Alert indication received)

CDUU: 4,"ANSWERED" (Remote party answered)

+CMCCSI: 4,0,0,0,"",0,6,0,1,0,"sip:veronica@university.org",0,0 (Connection established)

AT+CHCCS=4 (Connection with call identification number 4 terminated)

+CHCCSI: 4

+CMCCSI: 4,0,0,0,"",0,7,0,1,0,"sip:veronica@university.org",2,200 (Outgoing connection released)

+CMCCSI: 4,0,0,0,"",0,0,0,1,0,"sip:veronica@university.org",0,0 (Idle)

Below is an example where a multimedia-call originated with +CDU is placed to a SIP-URI. This example outlines how the call is initiated by the AT command +CDU, and how the unsolicited result codes +CDUU and +CMCCSI are used to indicate how the call-setup progresses until it is terminated. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. This example illustrates the use of the +CDEFMP and +CCMMD commands to define and control the types of media that are used in the call.

AT+CDEFMP=,"m=audio" (Media profile defined, offering only audio)

+CDEFMP=3 (Media profile index number 3 provided)

AT+CDU=1,"sip:veronica@university.org",1,3 (Multimedia-call initiated, using media profile number 3)

+CDU: 5 (Call initiated, call identification number 5 provided)

OK (Call initiation successful)

(+CDUU and +CMCCSI appear as appropriate)

+CMCCSI: 5,0,0,0,"",0,2,0,1,0,"sip:veronica@university.org",0,0 (Call setup is started)

+CMCCSI: 5,0,0,0,"",0,3,0,1,0,"sip:veronica@university.org",0,0 (Call is in progress)

+CMCCSI: 5,0,0,1,"m=audio",0,4,0,1,0,"sip:veronica@university.org",0,0

(Alert indication received and played back)

+CMCCSI: 5,0,1,3,"m=audio",0,4,0,1,0,"sip:veronica@university.org",0,0

(Remote party accepted the proposal for audio media)

+CDUU: 5,"ANSWERED" (Remote party answered)

+CMCCSI: 5,0,1,1,"m=audio",0,6,0,1,0,"sip:veronica@university.org",0,0

(Connection established, audio media is active)

+CMCCSI: 5,0,1,2,"m=audio\0D\0Am=video 99 98\0D\0Aa=rtpmap:99 H264/90000\0D\0Aa=fmtp:99 profile-level-id=4D4033\0D\0Aa=rtpmap:98 MP4V-ES/90000\0D\0Aa=fmtp:98 profile-level-id=1",0,6,0,1,0,"sip:veronica@university.org",0,0

(Remote party proposed adding video to the call, offering two different formats)

AT+CCMDC=5,3,"m=audio\0D\0Am=video 99 98\0D\0Aa=rtpmap:99 H264/90000\0D\0Aa=fmtp:99 profile-level-id=4D4033\0D\0Aa=rtpmap:98 MP4V-ES/90000\0D\0Aa=fmtp:98 profile-level-id=1"

(Proposal accepted, indicating support for both formats offered)

+CMCCSI: 5,0,1,1,"m=audio\0D\0Am=video 99\0D\0Aa=rtpmap:99 H264/90000\0D\0Aa=fmtp:99 profile-level-id=4D4033",0,6,0,1,0,"sip:veronica@university.org",0,0

(Call media changed to audio and video on a format selected by the TE)

AT+CCMDC=5,1,"m=audio" (Video media removed, unconditionally)

+CMCCSI: 5,0,1,1,"m=audio",0,6,0,1,0,"sip:veronica@university.org",0,0

(Call media changed to audio only)

AT+CHCCS=5 (Connection with call identification number 5 terminated)

+CHCCSI: 5

+CMCCSI: 5,0,0,0,"",0,7,0,1,0,"sip:veronica@university.org",2,200 (Outgoing connection released)

+CMCCSI: 5,0,0,0,"",0,1,0,1,0,"sip:veronica@university.org",0,0 (Idle)

Below is an example where an incoming multimedia-call is received, but the initially offered media audio+video is accepted as audio+video-recv-only, which is subset of the initial offer. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. The terms "<audio>","<audio+video>" and "<audio+video-recv-only>" are used to illustrate respective SDP media descriptions of audio, audio+video and audio+video-recv-only in the example.

RING (Ringing call)

+CMCCSI: 3,1,1,2,"<audio+video>",0,5,0,1,0,"sip:archie@university.org",0,0

(Incoming ringing call with call identification number 3 and a proposal for audio+video media)

AT+CCMMD=3,3," <audio+video-recv-only>" (Media proposal accepted as audio+video-recv-only)

ATA (Call answered)

+CMCCSI: 3,1,1,1,"< Audio+video-recv-only >",0,6,0,1,0,"sip:archie@university.org",0,0

(Active call established with audio media)

Below is an example where a multimedia-call originated with +CDU is placed to a SIP-URI. In this example, the remote party proposes to add video to the call, the local UE accepts the incoming proposal as audio+video-recv-only. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. The terms "<audio>","<audio+video>" and "<audio+video-recv-only>" are used to illustrate respective SDP media descriptions of audio, audio+video and audio+video-recv-only in the example.

AT+CDEFMP=,"m=audio" (Media profile defined, offering only audio)

+CDEFMP=3 (Media profile index number 3 provided)

AT+CDU=1,"sip:veronica@university.org",1,3 (Multimedia-call initiated, using media profile number 3)

+CDU: 5 (Call initiated, call identification number 5 provided)

OK (Call initiation successful)

(+CDUU and +CMCCSI appear as appropriate)

+CMCCSI: 5,0,0,0,"",0,2,0,1,0,"sip:veronica@university.org",0,0 (Call setup is started)

+CMCCSI: 5,0,0,0,"",0,3,0,1,0,"sip:veronica@university.org",0,0 (Call is in progress)

+CMCCSI: 5,0,0,1,"m=audio",0,4,0,1,0,"sip:veronica@university.org",0,0

(Alert indication received and played back)

+CMCCSI: 5,0,1,3,"m=audio",0,4,0,1,0,"sip:veronica@university.org",0,0

(Remote party accepted the proposal for audio media)

+CDUU: 5,"ANSWERED" (Remote party answered)

+CMCCSI: 5,0,1,1,"m=audio",0,6,0,1,0,"sip:veronica@university.org",0,0

(Connection established, audio media is active)

+CMCCSI: 5,0,1,2,"<audio+video>",0,5,0,1,0,"sip:archie@university.org",0,0

(Remote party propose to add video to the call)

AT+CCMDC=5,3,"<audio+video-recv-only>" (Proposal accepted as audio and video (recv-only))

+CMCCSI: 5,0,1,1,"<audio+video-recv-only>",0,6,0,1,0,"sip:veronica@university.org",0,0

(Call media changed to audio and video-recv-only)

Below is an example where a multimedia-call originated with +CDU is placed to a SIP-URI. In this example, the remote party rejects the proposed media and makes a counterproposal, which is then accepted by the originating party before the call is established. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. The terms "<audio>" and "<audio+video>" are used to illustrate respective SDP media descriptions of audio and audio+video in the example.

AT+CDEFMP=,"<audio+video>" (Media profile defined, offering both audio and video)

+CDEFMP=4 (Media profile index number 4 provided)

AT+CDU=1,"sip:veronica@university.org",1,4 (Multimedia-call initiated, using media profile number 4)

+CDU: 6 (Call initiated, call identification number 6 provided)

OK (Call initiation successful)

(+CDUU and +CMCCSI appear as appropriate)

+CMCCSI: 6,0,0,0,"",0,2,0,1,0,"sip:veronica@university.org",0,0 (Call setup is started)

+CMCCSI: 6,0,0,0,"",0,3,0,1,0,"sip:veronica@university.org",0,0 (Call is in progress)

+CMCCSI: 6,0,0,1,"<audio>",0,4,0,1,0,"sip:veronica@university.org",0,0

(Alert indication received and played back)

+CMCCSI: 6,0,1,4,"",0,4,0,1,0,"sip:veronica@university.org",0,0

(Remote party rejected the proposal for audio+video media)

+CMCCSI: 6,0,1,2,"<audio>",0,4,0,1,0,"sip:veronica@university.org",0,0

(Remote party proposed audio-only media for the call)

AT+CCMMD=6,3,"<audio>" (Proposal accepted)

+CDUU: 6,"ANSWERED" (Remote party answered the call)

+CMCCSI: 6,0,1,1,"<audio>",0,6,0,1,0,"sip:veronica@university.org",0,0

(Connection established, audio media is active)

Below is the same scenario as above from the terminating party’s perspective. An incoming multimedia-call is received, but the initially offered media is rejected and a successful counterproposal is made. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. The terms "<audio>" and "<audio+video>" are used to illustrate respective SDP media descriptions of audio and audio+video in the example.

RING (Ringing call)

+CMCCSI: 3,1,1,2,"<audio+video>",0,5,0,1,0,"sip:archie@university.org",0,0

(Incoming ringing call with call identification number 3 and a proposal for audio+video media)

AT+CCMMD=3,4 (Media proposal rejected)

AT+CCMMD=3,2,"<audio>" (Audio-only media for the call proposed)

+CMCCSI: 3,1,1,3,"<audio>",0,5,0,1,0,"sip:archie@university.org",0,0

(Originating party accepted the proposed, and now active, audio media)

ATA (Call answered)

+CMCCSI: 3,1,1,1,"<audio>",0,6,0,1,0,"sip:archie@university.org",0,0 (Active call established with audio media)

Below is an example where a multimedia-call originated with +CDU is placed to a SIP-URI. In this example, both the proposed media and the call is rejected by the remote party. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. The terms "<audio>" and "<audio+video>" are used to illustrate SDP media description of audio and audio+video in the example.

AT+CDEFMP=,"<audio+video>" (Media profile defined, offering both audio and video)

+CDEFMP=5 (Media profile index number 5 provided)

AT+CDU=1,"sip:veronica@university.org",1,5 (Multimedia-call initiated, using media profile number 5)

+CDU: 7 (Call initiated, call identification number 7 provided)

OK (Call initiation successful)

(+CDUU and +CMCCSI appear as appropriate)

+CMCCSI: 7,0,0,0,"",0,2,0,1,0,"sip:veronica@university.org",0,0 (Call setup is started)

+CMCCSI: 7,0,0,0,"",0,3,0,1,0,"sip:veronica@university.org",0,0 (Call is in progress)

+CMCCSI: 7,0,0,1,"<audio>",0,4,0,1,0,"sip:veronica@university.org",0,0

(Alert indication received and played back)

+CMCCSI: 7,0,1,4,"",0,4,0,1,0,"sip:veronica@university.org",0,0

(Remote party rejected the proposal for audio+video media)

+CDUU: 7,"CONNECTION TERMINATED" (Remote party rejected the call)

+CMCCSI: 7,0,0,0,"",0,7,0,1,0,"sip:veronica@university.org",2,488 (Outgoing connection released)

+CMCCSI: 7,0,0,0,"",0,1,0,1,0,"sip:veronica@university.org",0,0 (Idle)

Below is the same scenario as above from the terminating party’s perspective. An incoming multimedia-call is received, but both the initially offered media and the call are rejected. A precondition for this example is that the basic event for the call monitoring function is successfully enabled with +CMCCS=2. The term "<audio+video>" is used to illustrate SDP media description of audio+video in the example.

RING (Ringing call)

+CMCCSI: 4,1,1,2,"<audio+video>",0,5,0,1,0,"sip:archie@university.org",0,0

(Incoming ringing call with call identification number 4 and a proposal for audio+video media)

AT+CCMMD=4,4 (Media proposal rejected)

AT+CHCCS=4,2 (Connection with identification number 4 rejected)

+CHCCSI: 4

+CMCCSI: 4,0,0,0,"",0,8,0,1,0,"sip:veronica@university.org",2,488 (Incoming connection released)

+CMCCSI: 4,0,0,0,"",0,1,0,1,0,"sip:veronica@university.org",0,0 (Idle)