In an office, the engineers test the explicit call transfer (ECT) service (an IMS supplementary service), including the Blind transfer and Attendant transfer.
Test of the Blind transfer: The user of CS terminal A calls the user of IMS terminal B. Then B presses Flash*98 + short number of terminal C to forward the call to C. (Before C is connected, A is in Call Hold state.) B hangs up before C is connected. A conversation is set up between A and C, but both parties cannot hear the voice of the each other.
Test of the Attendant transfer: The user of CS terminal A calls the user of IMS terminal B. Then B presses Flash + short number of terminal C to forward the call to C. (Before B hangs up, A is in Call Hold state.) A conversation is set up between B and C and then B hangs up. A conversation continues to be set up between A and C, but C cannot hear the voice of A.
The MSC version is V100R008C02+SPH06 and provides the MGCF function and supports the SIP communication with the IMS side.
The ATS version is V100R002C02.
The MSC and MGW are connected to the IMS NE through a switch on the IMS side. The IP addresses of the MSC and MGW are in the same network segment with the service IP address of the IMS NE.
The MSC R&D personnel provide a test patch based on the protocol. Therefore, the ECT service can be used normally. The problem is solved.
1. After analyzing the subscriber messages and IMS messages on the MSC side, you can find out that during the Blind transfer, if the Invite message sent by the IMS does not contain the parameter a=sendrecv, the 200 message returned by the MSC also does not contain the parameter a=sendrecv. Therefore, there is no audio.
2. During the Attendant transfer, in the Call Hold phase, the Invite message sent by the IMS contains the parameter a=sendonly, so the 200 message returned by the MSC contains the parameter a=recvonly.
During the test, when B and C are connected, the Invite message sent by the IMS does not contain the parameter a, but the MSC returns a 200 message containing the parameter a=recvonly which is the same as that in the previous 200 message. Therefore, the IMS cannot hear the audio of the MS, and there is only one-way audio.
According to the protocol, when the Invite message sent by the peer end does not contain media information, the local end initiates the media negotiation and implements the call conversation. The MGCF in the MSC, however, does not initiate the media negotiation, but inherits the media parameter in the previous 200 message. The specific content of the protocol is as follows:
RFC 2543 .
B.4 Delayed Media Streams
it can support at the time it would like to issue an invitation. This
is the case when the caller is actually a gateway to another protocol
which performs media format negotiation after call setup. When this
occurs, a caller MAY issue an INVITE with a session description that
contains no media lines. The callee SHOULD interpret this to mean
that the caller wishes to participate in a multimedia session
described by the session description, but that the media streams are
not yet known. The callee SHOULD return a session description
indicating the streams and media formats it is willing to support,
however. The caller MAY update the session description either in the
ACK request or in a re-INVITE at a later time, once the streams are
Therefore, you can infer that the media negotiation processing in the current MSC version is abnormal.
Currently, the MGCF in the MSC version is not mature and has many problems when interacting with the IMS. To solve the problems mentioned in the test case, you must upgrade the MSC patch version to the latest patch version of R008C02.