Chapter 4 Configuring SPA9000 Features
Managing Call Forwarding
When a client station boots up and successfully registers with the proxy of each shared EXT, it sends a NOTIFY of dialog-info to the SPA9000 for the first time. The state of this dialog-info is set to “full.” In this case, all the dialog states should be idle because the client station has just booted. This indicates the station is just starting up. In response, the SPA9000 sends a full-state dialog-info NOTIFY to the client station with the current states of the dialog on each of the share line keys for this share extension.
The example below shows extension 5041 shared by the User-A station (whose primary extension is 5031), with no one using any of the share line appearances on the shared extension.
1.Client station initial NOTIFY/dialog to sa:
NOTIFY sip:sa@192.168.0.1:6060 SIP/2.0Via: SIP/2.0/UDP
192.168.0.4:5061;branch=z9hG4bK-aba99b57From: “User-A”
<sip:5031@192.168.0.1:6060>;tag=e676b37bae382029o1To: “User-A”
<sip:5041@192.168.0.1:6060>Call-ID: 12e6cb3f-268f4b3d@192.168.0.4CSeq: 64949 NOTIFY
Max-Forwards: 70
Contact: “User-A” <sip:5041@192.168.0.4:5061>Event: dialog
Content-Length: 155
Content-Type: application/dialog-info+xml
<?xml version=”1.0”?>
<dialog-info xmlns=”urn:ietf:params:xml:ns:dialog-info” version=”0” state=”full”
entity=”sip:5031@192.168.0.1:6060”> </dialog-info>
2. SPA9000 initial NOTIFY/dialog to client station:
NOTIFY sip:5041@192.168.0.4:5061 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.1:6060;branch=z9hG4bK-512b4023
From: PBX Line 1 <sip:37683101@matrix.sipura.com>;tag=5080117180da6835o2
To: <sip:5041@192.168.0.4:5061>
Call-ID: ebec254f-a8610a68@localhost
CSeq: 54508 NOTIFY
Max-Forwards: 70Event: dialogContent-Length: 151
Content-Type: application/dialog-info+xml
<?xml version=”1.0”?>
<dialog-info xmlns=”urn:ietf:params:xml:ns:dialog-info” version=”30” state=”full” entity=”sa@192.168.0.1:6060”></dialog-info>
When a client station sends NOTIFY to the SPA9000, the user-id field of the Request-URI must be “sa” and the message must include a CONTACT header. The CONTACT must be the same as the one used for registration. The SPA9000 tracks the client station that is using a share line key based on the CONTACT information in the NOTIFY request sent by client stations.
Before a client station can seize a share line key to make a call, it must send a partial-state dialog-info NOTIFY with the dialog state of the corresponding line key set to “trying.” The SPA9000 either replies 202 to the NOTIFY if no one is using that line key, or 403 if the line key is currently used by another client station.
In the example below, User-A is trying to use the first shared line key (x-line-id = 0) to make a call. Because no one is using that line key, the sa replies 202 to the NOTIFY. Subsequently, SPA9000 notifies the other client stations sharing that line key so that they would not attempt to use that line key (but can monitor its status).
1. User-A tries to make a call on the first shared line key on the shared extension 5041:
| | NOTIFY sip:sa@192.168.0.1:6060 SIP/2.0 |
| | Via: SIP/2.0/UDP 192.168.0.4:5061;branch=z9hG4bK-55f99f8e |
| | From: “User-A” <sip:5031@192.168.0.1:6060>;tag=e676b37bae382029o1 |
| | To: “User-A” <sip:5041@192.168.0.1:6060> |
| | Call-ID: 942395ba-dfdc1193@192.168.0.4 |
| | CSeq: 6583 NOTIFY |
| | Linksys SPA9000 Administrator Guide | | |
| | |
| Document Version 3.01 | | | 4-23 | |
| | | |
