Mitel Deutschland GmbH 68635RFP36U-01 ユーザーズマニュアル
SIP-DECT OM System Manual
32
3.13.2 CALL COMPLETED ELSEWHERE
SIP-DECT supports the SIP “Reason” header field defined in RFC 3326.
When SIP-DECT receives a CANCEL request including a “Reason” header field with “cause=200”, the
incoming call will be marked as accepted in the local incoming call logs of the Mitel 600 and Mitel 142d
phones.
incoming call will be marked as accepted in the local incoming call logs of the Mitel 600 and Mitel 142d
phones.
3.13.3 SEMI-ATTENDED TRANSFER
The SIP message sequence for a “Semi-Attended Transfer” allows the transferor to start the transfer
while the target phone is still ringing.
while the target phone is still ringing.
SIP-DECT supports different behaviors for semi-attended transfers. This can be configured on the OMP
SIP -> Advanced settings tab (see section 6.5.4.2).
The supported modes are:
SIP -> Advanced settings tab (see section 6.5.4.2).
The supported modes are:
Semi-attended
transfer mode
Refer-to with
replaces
Behavior
Blind
No
The semi-attended transfer is handled as a blind transfer. The phone
sends CANCEL before REFER for semi-attended transfer.
sends CANCEL before REFER for semi-attended transfer.
Blind
Yes
The semi-attended transfer is handled as a blind transfer. The phone
sends REFER with Replaces for semi-attended transfer and no CANCEL.
This behavior is not SIP compliant but necessary for some iPBX platforms.
sends REFER with Replaces for semi-attended transfer and no CANCEL.
This behavior is not SIP compliant but necessary for some iPBX platforms.
Attended
-
The semi-attended transfer is handled as an attended transfer. Both lines
of the transferor remain active until the transfer succeeds. This behavior is
compliant to RFC 5589.
of the transferor remain active until the transfer succeeds. This behavior is
compliant to RFC 5589.
Please note:
The mode “Semi-attended transfer mode: Blind” with “Refer-to with replaces:
yes” is not SIP compliant and should only be used on iPBX platforms that require that
signaling.
signaling.
3.13.4 THIRD LINE HANDLING FOR MITEL 142D AND 600 DECT PHONES
In earlier implementations of SIP-DECT user call control, a waiting call forces the user to react to that
call (accept or reject), before he can use other supplementary services like call transfer, conference or
inquiry call options.
call (accept or reject), before he can use other supplementary services like call transfer, conference or
inquiry call options.
In the new implementation, a third line is reserved for call waiting purposes. The waiting call is kept in the
background, even if the receiving user decides to finish supplementary services first (see rule at the end
of this subsection). It is also kept, if two lines are already used for brokering (in the former
implementation, the incoming call was answered with busy state). After one of those lines is released,
the waiting call can be accessed by the known means (by R-key or the referring menu options).
background, even if the receiving user decides to finish supplementary services first (see rule at the end
of this subsection). It is also kept, if two lines are already used for brokering (in the former
implementation, the incoming call was answered with busy state). After one of those lines is released,
the waiting call can be accessed by the known means (by R-key or the referring menu options).
Please note:
The Third Line Handling is available for Mitel 142d and Mitel 600 DECT
phones, but not for third party GAP phones.
Third Line Handling follows the existing MMI philosophy of the DECT phones. If the user wants to
continue supplementary services when a call comes in:
continue supplementary services when a call comes in:
• R-Key will accept the incoming call. All supplementary services will involve that incoming call
directly or indirectly.