| Table of Contents |
|---|
| Page properties | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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.
Requirements
...
Requirement title
...
Functionality
...
D8XX_BLF-XML_FR-1
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 | Must Have | |||||||||||||||||||||||||||||||||||||||||||||
| Status | |||||||||||||||||||||||||||||||||||||||||||||||
| colour | Green | ||||||||||||||||||||||||||||||||||||||||||||||
| title | FULLY IMPLEMENTED | 2 | D8XX_BLF-XML_FR-2 | 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:
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 | - | 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 | ||||||||||||||||||||||||||||||||||||||||||||
| Dialog state | terminated | trying | early/proceeding | confirmed | |||||||||||||||||||||||||||||||||||||||||||
| Translated state | idle | offhook | calling | ringing | talking | ||||||||||||||||||||||||||||||||||||||||||
| Direction | - | initiator | initiator | recipient | initiator/recipient | ||||||||||||||||||||||||||||||||||||||||||
| Allowed actions | Quick-dial | - | - | Pick-up | - | Must Have | |||||||||||||||||||||||||||||||||||||||||
| Status | |||||||||||||||||||||||||||||||||||||||||||||||
| colour | Yellow | ||||||||||||||||||||||||||||||||||||||||||||||
| title | PartLY IMPLEMENTED |
|
| ||||||||||||||||||||||||||||||||||||||||||||
| 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:Subscription | The assignment shall initiate the SIP subscription process according to RFC 3265. |
|
| |||||||||||||||||||||||||||||||||||||||||||
| 4 | D8XX:PFK-mapping:BLF-XML:Monitoring:Translation | Dialog states of the configured SIP extension shall be monitored, processed, and translated according to its direction.
|
| 3 | D8XX_BLF-XML_FR-3 | 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). | Must Have | ||||||||||||||||||||||||||||||||||||||||
| Status | |||||||||||||||||||||||||||||||||||||||||||||||
| colour | Green | ||||||||||||||||||||||||||||||||||||||||||||||
| title | FULLY IMPLEMENTED | 4 | D8XX_BLF-XML_FR-2-1 | On D8xx series, during an active subscription, state changes of the monitored SIP extension shall be visualized on both, PFK LED and PFK label. | Must Have | ||||||||||||||||||||||||||||||||||||||||||
| Status | |||||||||||||||||||||||||||||||||||||||||||||||
| colour | Green | ||||||||||||||||||||||||||||||||||||||||||||||
| title | FULLY IMPLEMENTED | 5 | D8XX_BLF-XML_FR-2-1-1 | ||||||||||||||||||||||||||||||||||||||||||||
| Dialog state | terminated | trying | early/proceeding | confirmed | |||||||||||||||||||||||||||||||||||||||||||
| Translated state | idle | offhook | calling | ringing | talking | ||||||||||||||||||||||||||||||||||||||||||
| Direction | - | initiator | initiator | recipient | initiator/recipient | ||||||||||||||||||||||||||||||||||||||||||
| LED behaviour | off | on | on | blinking | on | ||||||||||||||||||||||||||||||||||||||||||
| LED colour | - | red | red | red | red | Must Have |
| ||||||||||||||||||||||||||||||||||||||||
| 5 | D8XX_:PFK-mapping:BLF-XML_FR-2-1-2The PFK label shall be composed of 3 areas: | ||||||||||||||||||||||||||||||||||||||||||||||
| (A) icon area | (B) name area | ||||||||||||||||||||||||||||||||||||||||||||||
| (C) state area | When the PFK is pressed, the following actions are allowed according to the translated state
|
|
| ||||||||||||||||||||||||||||||||||||||||||||
| 6 | D8XX_:PFK-mapping:BLF-XML_FR-2-1-2-1: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. |
|
| |||||||||||||||||||||||||||||||||||||||||||
| 7 | D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:LED | The PFK LED behaviour and colour shall be according to the translated state: The label icon area (A) shall contain the following graphical symbol and colour | |||||||||||||||||||||||||||||||||||||||||||||
| Dialog state | terminated | trying | early/proceeding | confirmed | |||||||||||||||||||||||||||||||||||||||||||
| Translated state | idle | offhook | calling | ringing | talking |
|---|
| LED behaviour |
|---|
| off |
| on |
| on |
| blinking |
tbd| on | |||||
| LED colour | - | red | red | red | red |
|---|
| Status | ||||||
|---|---|---|---|---|---|---|
|
| Status | ||||||
|---|---|---|---|---|---|---|
|
D8XX
_:PFK-mapping:BLF-XML
_FR-2-1-2-2:Monitoring:Visualization:Label:Areas
The PFK label shall be composed of 3 areas:
| (A) icon area | (B) name area |
| (C) state area |
| Status | ||||||
|---|---|---|---|---|---|---|
|
| Status | ||||||
|---|---|---|---|---|---|---|
|
D8XX:PFK-mapping:BLF-XML:Monitoring:Visualization:Label:icon-area
The label icon area (A) shall contain an icon and colouraccording to the translated state
The label name area (B) shall contain a text using either the display name or number (configurable) of the monitored / calling party. Depending on the available space, the text shall be scrolled.
trying
early/proceeding
| 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
| Example (using display name) | Alex | Alex > | Alex > Alice | Alice > Alex | Alice <> Alex | Alex <> Alice |
Must Have
| Icon (suggestion from fkey_icons) |  |  |  | ||
|---|---|---|---|---|---|
| Name | kIconTypeFkeyBlfIdle | kIconTypeFkeyBlfOffhook | kIconTypeFkeyBlfCalling | kIconTypeFkeyBlfRinging | kIconTypeFkeyBlfTalking |
| Colour | grey/white | red | red | yellow | red |
| Status | ||||||
|---|---|---|---|---|---|---|
|
| Status | ||||||
|---|---|---|---|---|---|---|
|
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.
The label state area (C) shall contain a text and colour representing the translated state
trying
early/proceeding
| Translated state | idle | offhook | calling | ringing | talking | ||
|---|---|---|---|---|---|---|---|
| Direction | - | initiator | initiator | recipient | initiator | /recipient | |
| text | idle | offhook | calling | ringing | talking | ||
| Text (based on target) | local | local > | local > remote | remote > local | remote <> local | local <> remote | |
| Text colour | white | white | white | white | white | ||
Must Have
Interactions and output
|
|
| ||||||||||||||||||||||||||||||||||||
| 11 | 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
|
|
|
Software Requirement Specification (SRS)
Based on user interactions, the UAS sends SIP NOTIFY messages to the UAC. By means of XML definitions, the information in the SIP NOTIFY XML body are translated into variables, that are known to the UAC phone application and can be processed to show the desired results.
| Interactions | SIP NOTIFY XML body | XML definition | Display | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| UAS | UAS => UAC | UAC translation rules | Complete rule set | PFK LED & label (number) | PFK LED & label (display name) | |||||||||||||||||||||||||||||||
| goes offhook | dialog state => trying
| translate state => offhook
| ||||||||||||||||||||||||||||||||||
| Interactions | SIP NOTIFY XML body | XML definition | Result | |||||||||||||||||||||||||||||||||
| UAS | UAS => UAC | UAC translation rules | PFK LED & label | |||||||||||||||||||||||||||||||||
| goes offhook | ||||||||||||||||||||||||||||||||||||
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
...
<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> |
dialog state => terminated
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
NOTIFY ... <?xml<NotifyParsingRules versiontype="1.0state"?> <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
...
<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> |
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
<ReplacementPlan> <!-- This defines the name of the entry in the Function Keys page under Type --> <key id="BLF-new"> |
<general type=" |
BLFSampleDefinition" /> |
dialog state => early/proceeding
| language | xml |
|---|---|
| title | NOTIFY |
| linenumbers | true |
| collapse | true |
<initialization> <!-- only add the UAS IP here, extension number is replaced from WUI as variable $(ui_argument) --> <variable name="subscr_proxy" value="10.110.22.35"/> <!-- initial value for the state variable: off means, that after bootup this button has state off --> <state value="off"/> </initialization> <!-- a subscription of event-type dialog will be initiated to the URI defined --> <subscription type="dialog" to="<sip:$(ui_argument)@$(subscr_proxy)>" for="$(ui_argument)@$(subscr_proxy)"/> <!-- checks if a SIP NOTIFY message belongs to this particular button level is ok, if the condition inside the tags is matched --> <NotifyParsingRules type="applies"> <level1 translates_to='OK'>/dialog-info[@entity="sip:$(ui_argument)@$(subscr_proxy)"]</level1> </NotifyParsingRules> <!-- translates the button state based on the body of the SIP NOTIFY --> <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> <level3 translates_to="offhook">/dialog-info/dialog/state[.="trying"]</level3> <level4 translates_to="talking">/dialog-info/dialog/state[.="confirmed"]</level4> <level5 translates_to="idle"/> </ |
NotifyParsingRules> |
translate state => ringing
- quick dial not allowed
- pick-up allowed
| language | xml |
|---|---|
| theme | Confluence |
| title | XML definition |
| linenumbers | true |
| collapse | true |
<!-- Call pickup: fetch variable call_id from call-id of NOTIFY body --> <NotifyParsingRules type="variable" id="call_id" state="ringing"> <level1 fetch_attribute="call-id">/dialog-info/dialog |
[@call-id]</level1> </NotifyParsingRules> |
<!-- Call pickup: fetch variable remote_tag from remote-tag of NOTIFY body --> <NotifyParsingRules type="variable" |
id="remote_tag" |
state="ringing"> <level1 fetch_attribute="remote-tag">/dialog-info/dialog[@remote-tag]</level1> </NotifyParsingRules> |
|
<!-- Call pickup: fetch variable local_tag from local-tag of NOTIFY body --> <NotifyParsingRules type="variable" id="local_tag" |
state="ringing"> <level1 fetch_attribute="local-tag">/dialog-info/dialog[@local-tag]</level1> </NotifyParsingRules> |
<!-- Call pickup: fetch variable remote_uri from uri of NOTIFY body --> <NotifyParsingRules type="variable" id="remote_uri" state="ringing"> <level1 fetch_attribute="uri">/dialog-info/dialog/remote/target[@uri]</level1> </NotifyParsingRules> <action> <!-- Quick dial: Szolt decided to allow it only in idle state --> <invite target="$( |
ui_ |
argument)" |
when="on press" |
states="idle"/> <!-- Pick up --> <invite target="$(remote_name)<$(remote_uri)>" |
when="on press" |
state="ringing" |
request_uri="$(remote_uri)" |
replaces="$(call_id);to-tag=$(remote_tag);from-tag=$(local_tag)"/> <!-- change icon on NOTIFY and translated state idle --> <assign when="on notify" state="idle"> <source value="kIconTypeFkeyBlfIdle"/> <destination id="icon"/> </assign> <!-- change icon on NOTIFY and translated state offhook --> <assign when="on notify" state="offhook"> <source value="kIconTypeFkeyBlfOffhook"/> <destination id="icon"/> </assign> <!-- change icon on NOTIFY and translated state ringing --> <assign when="on notify" state="ringing"> <source value="kIconTypeFkeyBlfRinging"/> <destination id="icon"/> </assign> <!-- change icon on NOTIFY and translated state calling --> <assign when="on notify" state="calling"> <source value="kIconTypeFkeyBlfCalling"/> <destination id="icon"/> </assign> <!-- change icon on NOTIFY and translated state talking --> <assign when="on notify" state="talking"> <source value="kIconTypeFkeyBlfTalking"/> <destination id="icon"/> </assign> </action> </key> </ReplacementPlan> |
| 🔴 |  | 101 > |
| offhook |
| 🔴 | | Alex > |
| offhook |
dialog state => terminated
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
...
<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 |
| ⚪️ | | Alex |
| idle |
dialog state => early/proceeding
| Code Block | ||||
|---|---|---|---|---|
|
dialog state => confirmed
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
...
<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> |
dialog state => terminated
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
NOTIFY ... <NotifyParsingRules<?xml typeversion="state1.0"?> ... <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> |
<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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
...
<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 state => early/proceeding
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
... <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[@remote-tag]</level1> </NotifyParsingRules> <NotifyParsingRules type="variable" id="local_tag" state="ringing"> <level1 fetch_attribute="local-tag">/dialog-info/dialog/state[.="proceeding"] </level2> <level2-1 translates_to="calling[@local-tag]</level1> </NotifyParsingRules> <NotifyParsingRules type="variable" id="remote_uri" state="ringing"> <level1 fetch_attribute="uri">/dialog-info/dialog[@direction="initiator"] </level2-1>/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 > 103 |
| calling | ||
| ringing |
| 🟠 | | Alice > Alex |
| ringing |
dialog state => confirmed
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
NOTIFY ... <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="..." state="full" entity="sip:101@..."> <dialog id="..." direction='initiatorrecipient' 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="DC">sip:103@102@...</identity> <target uri="sip:103@102@..."/> </remote> </dialog> </dialog-info> |
translate state => talking
- quick dial not allowed
- pick-up not allowed
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
...
<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 <> 103 |
| talking |
| 🔴 | | Alice <> Alex |
| talking |
dialog state => terminated
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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='initiatorrecipient' call-id='...' local-tag="..." remote-tag="..."> <state>terminated</state> <local> 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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
...
<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> |
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| translate state => idle
|
|
| |||||||||||||||||||||||||||||||||
| Outgoing call ringing | dialog state => early/proceeding
| translate state => calling
|
|
| ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Outgoing call accepted | dialog state => confirmed
| translate state => talking
|
|
| ||||||||||||||||||||||||||||||||
| Outgoing call terminated | dialog state => terminated
| translate state => 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? | Alexander Feldt I'd agree, for these reasons:
| ||
Shall we allow quick dial only in idle state? | Alexander Feldt Technically, we could allow quick dial in any state, except ringing... | ||
Shall we create new icons or reuse those already existing ones? | Alexander Feldt I really question icons, that are so small, that there is no visible difference to the user, like | ||
| How can a specific LED behaviour be addressed using XML definitions? | Alexander Feldt Currently not within XML definitions, it has to be configured via settings. | ||
| How can a specific label be addressed using XML definitions? | Alexander Feldt see label, but I haven't figured out how to define it correctly
| ||
| How can a specific icon be addressed using XML definitions? | Alexander Feldt see icon, but I haven't figured out how to define it correctly | ||
| How shall the Label area be configured to use either number or display name? | Alexander Feldt The topic is even more complex: I assume the PFK label is generally too short to show longer extension number or names, i.e. some kind of scrolling must be used. But is this really helpful for the customer at all? | ||
| From the UX point of view: which visual aid is more important for the customer: LED or PFK label? |
| ||
Tita Petre Is the above list of requirements enough input to create a proper testplan? | |||
Clemens Cramer As the decision to move the default blf & extension configuration to a xml definition is based on customer requests to modify the behavior, guides with working examples on how to change the labels, icons, led behavior, and handled dialog states should probably be a requirement (and as such covered by tests). | Question | Outcome
