The Wiki of Unify contains information on clients and devices, communications systems and unified communications. - Unify GmbH & Co. KG is a Trademark Licensee of Siemens AG.
|Model:|| OpenStage 60|
The phone will send a subscription to a configured MWI server according to the standard RFC 3842. Unsolicited Notify messages containing the message waiting information are also accepted.
The SIP server can be configured under
- Administrator Pages -> System -> Features -> Services -> Message waiting server address
- 1 Busy Lamp Field and Directed Call Pickup
- 2 Some remarks about the SIP implementation
Busy Lamp Field and Directed Call Pickup
The Busy Lamp Field feature in its most basic form provides the phone user the ability to monitor the state of other users/devices. Typically the information provided to the monitored user will allow them to determine whether the monitored user/device is idle, ringing or connected and it may also in some environments be able to indicate call held, line sized and forwarding states.
Additional functionality may be provided by the monitored users device by having an associated FPK and modifying the action performed when pressing the key depending on the current dialog state. For example when idle pressing the key may initiate a call to the monitored user and when ringing press-ing the key may initiate a pickup of the ringing call. In the HiPath 8000 environment BLF type functionality is provided by the DSS feature.
The Configuration of the BLF Key is done at three different places in the Admin Menu:
BLF Pickup Code
- System -> Features -> Services
- System -> Features -> Program keys
- Key Label: Name of the FPK displayed on the screen
- Monitored Phone: Extension of the phone, which monitored by the key
- Audible Alert: If checked, the phone will do an alert for calling the attention of the user
- Popup on alert: The phone displays a popup notification at the alert state
- System -> Features -> Configuration
- BLF alerting: Beep or Ring
Beep is a short audible indication for the user. Ring is using the selected ringer file for indication.
Some remarks about the SIP implementation
This section provides some guidance on the SIP protocol aspects of susbcribing to the SIP Server for dialog event information and for picking up calls ringing the BLF Destination.
Use of Dialog Event Package (RFC 4245)
On initialisation the OpenStage phone will initiate a subscription to the dialog event package for each FPK configured for the BLF feature. An example of this subscription and a subsequent notify received from an Asterisk server is given below.
A SIP SUBSCRIBE request is generated for a BLF key configured to monitor extension 6001.
SUBSCRIBE sip:firstname.lastname@example.org:5060 SIP/2.0 Via: SIP/2.0/UDP 184.108.40.206:5060;branch=z9hG4bK-1-0 From: sipp <sip:email@example.com:5060>;tag=1 To: sut <sip:firstname.lastname@example.org:5060> Call-ID: email@example.com CSeq: 1 SUBSCRIBE Contact: sip:firstname.lastname@example.org:5060 Max-Forwards: 70 Event: dialog Accept: application/dialog-info+xml Expires: 3600 Content-Length: 0
The Asterisk Server responds with a 200 OK.
SIP/2.0 200 OK Via: SIP/2.0/UDP 220.127.116.11:5060;branch=z9hG4bK-1-0;received=18.104.22.168 From: sipp <sip:email@example.com:5060>;tag=1 To: sut <sip:firstname.lastname@example.org:5060>;tag=as065f0599 Call-ID: email@example.com CSeq: 1 SUBSCRIBE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Expires: 3600 Contact: <sip:firstname.lastname@example.org>;expires=3600 Content-Length: 0
The Asterisk Server generates an initial NOTIFY for the subscription and indicates that extension 6001 is idle (dialog state = terminated).
NOTIFY sip:email@example.com:5060 SIP/2.0 Via: SIP/2.0/UDP 22.214.171.124:5060;branch=z9hG4bK35d158aa;rport From: sut <sip:firstname.lastname@example.org:5060>;tag=as065f0599 To: sipp <sip:email@example.com:5060>;tag=1 Contact: <sip:firstname.lastname@example.org> Call-ID: email@example.com CSeq: 102 NOTIFY User-Agent: Asterisk PBX Max-Forwards: 70 Event: dialog Content-Type: application/dialog-info+xml Subscription-State: active Content-Length: 212
<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" enti-ty="sip:firstname.lastname@example.org:5060"> <dialog id="6001"> <state>terminated</state> </dialog> </dialog-info>
The phone responds to the NOTIFY with a 200OK.
SIP/2.0 200 OK Via: SIP/2.0/UDP 126.96.36.199:5060;branch=z9hG4bK35d158aa;rport From: sut <sip:email@example.com:5060>;tag=as065f0599 To: sipp <sip:firstname.lastname@example.org:5060>;tag=1 Call-ID: email@example.com CSeq: 102 NOTIFY Contact: <sip:188.8.131.52:5060;transport=UDP> Content-Length: 0
Multiple dialogs reported in a dialog event.
A single SIP NOTIFY may contain information relating to multiple dialogs active at the BLF Destination. For example when the BLF destination receives a call waiting call. In this case the phone must parse all dialogs to determine the state to be reported. The state with the highest priority is used to set the state of the BLF LED and any associated popup.
The priority is as follows:
|Priority||Dialog State||Call State at BLF Destination||BLF LED State|
|1.||State = Early,direction=recipient.||Incoming call alerting at destination.||Flashing (Incoming Call)|
|2a.||State = Early, direc-tion=originator||Outgoing call.||On (Busy)|
|2b.||State = Confirmed||Established Call (Including held)||On (Busy)|
|3.||State = Terminated||Call has been cleared Off (Idle).|
Picking-Up a call ringing a BLF destination.
To pickup a call ringing a BLF destination the procedure followed by the Picking-up OpenStage phone depends on configuration and on the amount of information received in the dialog event as follows.
Picking-Up using a feature access code
If a feature access code is configured for BLF Pickup then the OpenStage phone generates an INVITE using the feature access code (FAC) and the BLF Destination in the Request-URI of the INVITE request. The content of the INVITE would be as followed (Note – Only the significant headers are shown).
INVITE sip:<FAC><BLF Destination>@SIPServerDomain SIP/2.0 From: <sip:6000>;tag=drfgdfdg To: sip:<FAC><BLF Destination> Call-ID: gshgshjgsgshjgshjg CSeq: 1 INVITE Accept: application/sdp Content-Type: application/sdp Content-Length: xxx …
This method is used whenever a feature access code is configured for BLF Pickup.
Picking-Up using the SIP Replaces Header (RFC 3891)
If no BLF Pickup feature access code is configured and the dialog event received from the SIP Server contains at a minumum the “call-id” and the “local” and “remote” elements then the OpenStage phone shall folllow the Picking-Up UA procedures as specified in the OSCAR SIP Directed Pickup Specification. This involves generating a SIP a SIP INVITE with Replaces header.
Picking-Up using an INVITE to the remote target-URI.
If no BLF Pickup feature access code is configured and the dialog event contains the “local” and “re-mote” elements but no “call-id” then the OpenStage phone using the same procedures as defined in 0 but without including a Replaces header in the INVITE request.
This method relies on the SIP Server setting the remote target-uri to be something that it will recognise as a call pickup request.