View Source

Target release	1.0
Epic
Document status
Document owner	Alexander Feldt
Designer	Zsolt Erdei
Developers	Clemens Cramer
QA	Tita Petre

Goals

The current BLF and Extension mapping implementations for D8xx IP phone series are similar, but with a few differences and partly erroneous behaviour. Therefore, it is desired to align both implementations by using XML definitions instead. Furthermore, the requirements should be re-defined to communicate a clear result.
- Avoid confusion for customers
- Improve user experience
- Improve performance

Background and strategic fit

BLF is a valuable feature for Snom customers, like enterprises who are looking to assist in connecting their customers to a live, available person as well as save business phone use time. Overall, it enables businesses to streamline their communication and better serve customers. BLF aka Extension monitoring has been utilized in numerous ways by businesses using Snom phone systems with multiple extensions.

Use cases

Use case#1: A secretary's phone shall display the call status of the boss's line, allowing the secretary to know whether the boss is on a phone call or not. This will enable the secretary to make the decision to put the new caller on hold or let them through to the boss.
Use case#2: Call centers and customer support groups have also a need for BLF: it enables employees to see if their colleagues are free to take a support call or if their supervisor is on another line and unable to help another customer.
Use case#3: BLF is needed by teams working on a specific project: supervisors can monitor team members' extensions and vice versa so all team members are aware of each other's current status.

Preconditions

On Snom IP phones acting as UAS, any SIP extension having an active subscription of its state changes, shall sent a notification SIP message (NOTIFY) to the UAC, when one of the following state changes occur:

from any state => terminated
from any state => trying
from any state => early/proceeding
from any state => confirmed

The NOTIFY XML body must contain the necessary information for the UAC to perform state translation and visualization.

Requirements

#

Requirement title

Functionality

Importance

Implementation status

1

D8XX:PFK-mapping:BLF-XML:General-Functionality

On D8xx IP phones, any PFK (programmable function key - physical or virtual) can be assigned to a key type called "BLF-XML", and a key number, which corresponds to a SIP extension on another IP phone in the same VoIP environment. The following specific functionality is required:

Monitoring states of the configured SIP extension
Quick-dial to the configured SIP extension in idle state
Pick-up an incoming call to the configured SIP extension

2

D8XX:PFK-mapping:BLF-XML:Configuration

The assignment shall be configured either manually via web user interface (WUI) and/or phone user interface (PUI), and automatically via auto-provisioning (HTTP/TFTP setting server), SRAPS, or remote management (TR-069).

3

D8XX:PFK-mapping:BLF-XML:Monitoring:Translation

Dialog states of the configured SIP extension shall be monitored, processed, and translated according to its direction.

UAS state	Dialog state (NOTIFY)	Direction	Translated state
idle mode	terminated/none of the below mentioned	-	idle
offhook	trying	initiator	offhook
incoming call ringing	early/proceeding	recipient	ringing
incoming call accepted	confirmed	recipient	talking
outgoing call ringing	early/proceeding	initiator	calling
outgoing call accepted	confirmed	initiator	talking

4

D8XX:PFK-mapping:BLF-XML:Actions

When the PFK is pressed, the following actions are allowed according to the translated state

Translated state	idle	offhook	calling	ringing	talking
Allowed actions	Quick-dial	-	-	Pick-up	-

5

D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization

On D8xx series, during an active subscription, state changes of the monitored SIP extension shall be visualized on both, PFK LED and PFK label.

6

D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:LED

The PFK LED behaviour and colour shall be according to the translated state:

Translated state	idle	offhook	calling	ringing	talking
LED behaviour	off	on	on	blinking	on
LED colour	-	red	red	red	red

7

D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:Label:Areas

The PFK label shall be composed of 3 areas:

(A) icon area	(B) name area
	(C) state area

8

D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:Label:icon-area

The label icon area (A) shall contain a graphical symbol and colour according to the translated state

Translated state	idle	offhook	calling	ringing	talking
Graphical symbol	tbd	tbd	tbd	tbd	tbd
Colour	white/tbd	white/tbd	white/tbd	white/tbd	white/red

9

D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:Label:name-area

The label name area (B) shall contain a text derived from display name or number (configurable) according to translated state and direction. Depending on the available space, the text shall be scrolled.

Translated state	idle	offhook	calling	ringing	talking
Direction	-	initiator	initiator	recipient	initiator	recipient
Text (based on target)	local	local >	local > remote	remote > local	remote <> local	local <> remote
Text colour	white	white	white	white	white	white
Example (using number)	101	101 >	101 > 102	102 > 101	102 <> 101	101 <> 102
Example (using display name)	Alex	Alex >	Alex > Alice	Alice > Alex	Alice <> Alex	Alex <> Alice

10

D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:Label:state-area

The label state area (C) shall contain a text and colour representing the translated state

Translated state	idle	offhook	calling	ringing	talking
text	idle	offhook	calling	ringing	talking
colour	white	white	white	white	white

Interactions and output

Interactions

SIP NOTIFY XML body

XML definition

Result

UAS

UAS => UAC

UAC translation rules

PFK LED & label

goes offhook

dialog state => trying

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="..."
	state="full"
	entity="sip:101@...">
	<dialog id="..." >
		<state>trying</state>
	</dialog>
</dialog-info>

translate state => offhook

quick dial not allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
	...
  	<level3
		translates_to="offhook">/dialog-info/dialog/state[.="trying"]
	</level3>
  	...
</NotifyParsingRules>
...
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

🔴	tbd	101 >
		offhook

goes onhook

dialog state => terminated

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="..."
	state="full"
	entity="sip:101@...">
	<dialog id="..."
		direction='initiator'
		call-id='...'
		local-tag=""
		remote-tag="">
		<state>terminated</state>
		<local>
			<identity display="B">sip:101@...</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
			</target>
		</local>
	</dialog>
</dialog-info>

translate state => idle

quick dial allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
	...
  	<level5 translates_to="idle"/>
</NotifyParsingRules>
...
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

⚪️		101
		idle

incoming call ringing

dialog state => early/proceeding

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="..."
	state="full" entity="...">
	<dialog
		id="..."
		direction='recipient'
		call-id='...'
		local-tag="..."
		remote-tag="...">
		<state>early</state>
		<local>
			<identity display="B">
				sip:101@...
			</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
			</target>
		</local>
		<remote>
			<identity display="C">
				sip:102@...
			</identity>
			<target uri="sip:102@..."/>
		</remote>
	</dialog>
</dialog-info>

translate state => ringing

quick dial not allowed
pick-up allowed

...
<NotifyParsingRules type="state">
	<level1
		translates_to="ringing">/dialog-info/dialog/state[.="early"]
	</level1>
	...
	<level2
		translates_to="ringing">/dialog-info/dialog/state[.="proceeding"]
	</level2>
  ...
</NotifyParsingRules>
<NotifyParsingRules
	type="variable"
	id="call_id"
	state="ringing">
	<level1 fetch_attribute="call-id">/dialog-info/dialog[@call-id]</level1>
</NotifyParsingRules>
<NotifyParsingRules
	type="variable"
	id="remote_tag"
	state="ringing">
	<level1 fetch_attribute="remote-tag">/dialog-info/dialog[@remote-tag]</level1>
</NotifyParsingRules>
<NotifyParsingRules
	type="variable"
	id="local_tag"
	state="ringing">
	<level1 fetch_attribute="local-tag">/dialog-info/dialog[@local-tag]</level1>
</NotifyParsingRules>
<NotifyParsingRules
	type="variable"
	id="remote_uri"
	state="ringing">
	<level1 fetch_attribute="uri">/dialog-info/dialog/remote/target[@uri]</level1>
</NotifyParsingRules>
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

🟠		102 > 101
		ringing

incoming call accepted

dialog state => confirmed

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="..."
	state="full"
	entity="sip:101@...">
	<dialog
		id="..."
		direction='recipient'
		call-id='...'
		local-tag="..."
		remote-tag="...">
		<state>confirmed</state>
		<local>
			<identity display="B">sip:101@...</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
				<param pname="+sip.rendering" pval='yes' />
			</target>
		</local>
			<remote>
				<identity display="C">sip:102@...</identity>
				<target uri="sip:102@..."/>
			</remote>
	</dialog>
</dialog-info>

translate state => talking

quick dial not allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
	...
	<level4
		translates_to="talking">/dialog-info/dialog/state[.="confirmed"]
	</level4>
</NotifyParsingRules>
...
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

🔴		102 <> 101
		talking

Incoming call terminated

dialog state => terminated

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="8"
	state="full"
	entity="sip:101@...">
	<dialog id="..."
		direction='recipient'
		call-id='...'
		local-tag="..."
		remote-tag="...">
		<state>terminated</state>
		<local>
			<identity display="B">sip:101@...</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
			</target>
		</local>
		<remote>
			<identity display="C">sip:102@...</identity>
			<target uri="sip:102@..."/>
		</remote>
	</dialog>
</dialog-info>

translate state => idle

quick dial allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
  ...
  <level5 translates_to="idle"/>
</NotifyParsingRules>
... 
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

⚪️		101
		idle

Outgoing call ringing

dialog state => early/proceeding

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="13"
	state="full"
	entity="sip:101@...">
	<dialog
		id="..."
		direction='initiator'
		call-id='...'
		local-tag="..."
		remote-tag="">
		<state>early</state>
		<local>
			<identity display="B">sip:101@...</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
			</target>
		</local>
		<remote>
			<identity display="D">sip:103@...;user=phone</identity>
			<target uri="sip:103@...;user=phone"/>
		</remote>
	</dialog>
</dialog-info>

translate state => calling

quick dial not allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
	<level1
		translates_to="ringing">/dialog-info/dialog/state[.="early"]
	</level1>
	<level1-1
		translates_to="calling">/dialog-info/dialog[@direction="initiator"]
	</level1-1>
	<level2
		translates_to="ringing">/dialog-info/dialog/state[.="proceeding"]
	</level2>
	<level2-1
		translates_to="calling">/dialog-info/dialog[@direction="initiator"]
	</level2-1>
</NotifyParsingRules>
...
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

🔴	tbd	101 > 103
		calling

Outgoing call accepted

dialog state => confirmed

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="..."
	state="full"
	entity="sip:101@...">
	<dialog
		id="..."
		direction='initiator'
		call-id='...'
		local-tag="..."
		remote-tag="...">
		<state>confirmed</state>
		<local>
			<identity display="B">sip:101@...</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
				<param pname="+sip.rendering" pval='yes' />
			</target>
		</local>
		<remote>
			<identity display="D">sip:103@...</identity>
			<target uri="sip:103@..."/>
		</remote>
	</dialog>
</dialog-info>

translate state => talking

quick dial not allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
	...
	<level4
		translates_to="talking">/dialog-info/dialog/state[.="confirmed"]
	</level4>
</NotifyParsingRules>
... 
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

🔴		101 <> 103
		talking

Outgoing call terminated

dialog state => terminated

NOTIFY
...
<?xml version="1.0"?>
<dialog-info
	xmlns="urn:ietf:params:xml:ns:dialog-info"
	version="..."
	state="full"
	entity="sip:101@...">
	<dialog
		id="..."
		direction='initiator'
		call-id='...'
		local-tag="..."
		remote-tag="...">
		<state>terminated</state>
		<local>
			<identity display="B">sip:101@...</identity>
			<target uri="sip:101@...;line=...">
				<param pname="x-line-id" pval="0" />
			</target>
		</local>
		<remote>
			<identity display="D">sip:103@...</identity>
			<target uri="sip:103@..."/>
		</remote>
	</dialog>
</dialog-info>

translate state => idle

quick dial allowed
pick-up not allowed

...
<NotifyParsingRules type="state">
	...
  	<level5 translates_to="idle"/>
</NotifyParsingRules>
... 
<action>
	<invite target="$(subscr_uri)"
		when="on press"
		states="idle"/>
	<invite target="$(remote_uri)"
		when="on press"
		state="ringing"
		request_uri="$(remote_uri)"
		replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/>
</action>

⚪️		101
		idle

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Question

Outcome

Shall we visualize all possible translation states?

Alex: I'd agree, for these reasons:

Snom phones (acting as UAS) already provide all information in NOTIFY body
It's cleaner, e.g. when the UAS goes offhook or calls somebody, currently "talking" is visualized, which is not true.
It could be an advanced sales feature?

Shall we allow quick dial only in idle state?

Alex: Technically, we could allow quick dial in any state, except ringing...

Not Doing

List the features discussed which are out of scope or might be revisited in a later release.