Table 9.3 lists ISDN supplementary services and where applicable indicates support for corresponding features at the SIP client interface by reference to the appropriate sections in this specification.
ISDN Supplementary Service Support at SIP Client Interface
Call Waiting See Section 8.12, “Call Waiting”.
Message Waiting Indication. See Section 8.10, “Message Waiting Indication (MWI)”. Call Hold See Section 8.2, “Call Hold”.
Completion of Calls to Busy Subscriber (CCBS).
See Section 8.11, “Call Completion”.
Completion of Calls on No Reply (CCNR) See Section 8.11, “Call Completion”.
Anonymous Call Rejection (ACR) A client or OpenScape Voice can reject a call because the caller is anonymous. No specific SIP signalling is specified for this, although response code 403 Forbidden might be an appropriate choice.
Rejection of Forwarded Calls (RFC) A client or OpenScape Voice can reject a call because it has been forwarded. No specific SIP signalling is specified for this, although response code 403 Forbidden might be an appropriate choice.
Direct Dialling In (DDI) This has only an indirect effect on the SIP client interface, in that DDI numbers may map to SIP AoR URIs that clients register against.
Calling Line Identification Presentation (CLIP)
This can be achieved by using the P-Asserted-Identity header field in an INVITE request, or in its absence the From header field.
Calling Line Identification Restriction (CLIR)
This feature should be performed by a OpenScape Voice. A client can receive an INVITE request with no P-Asserted-Identity header field and an anonymous URI value in the From header field.
Connected Line Identification Presentation (COLP)
This can be achieved by using the P-Asserted-Identity header field in a 18x or 200 response to an INVITE request.
Connected Line Identification Restriction (COLR)
This feature should be performed by OpenScape Voice. A client can receive an INVITE response with no P-Asserted-Identity header field.
Malicious Call Identification (MCID) The SIP client interface provides no support for this. It can be performed at OpenScape Voice.
Calling Name Identification Presentation (CNIP)
As for CLIP.
Calling Name Identification Restriction (CNIR)
As for CLIR.
Connected Name Identification Presentation (CONP)
As for COLP.
Normal Call Transfer (CT) See Section 8.2, “Call Hold”.
Single Step Call Transfer (SSCT). See Section 8.1, “Identification Services”. Call Forward Busy (CFB) See Section 8.8, “Call Diversion”. Call Forward No Reply (CFNR). See Section 8.8, “Call Diversion”.
Call Forward No Logged In (CRNL) This is not explicitly supported at the SIP client interface. However, it can be performed within OpenScape Voice, in which case it will appear as call forwarding unconditional when signalled at the SIP client interface. Call Forward Unconditional (CFU) See Section 8.8, “Call Diversion”.
Call Deflection (CD) See Section 8.8, “Call Diversion”.
Line Hunting (LH) This feature has no impact on the client interface. It can be performed within OpenScape Voice.
Advice of Charge (AOC) Not supported. Reverse Charging (REV) Not supported.
Conference Call (CONF) See Section 8.7, “Conferencing”. Three Party Service (3PTY) See Section 8.7, “Conferencing”.
Meet Me Conference (MMC) No special capabilities are required at the SIP client interface to allow users to call a meet-me conference.
ISDN Supplementary Service Support at SIP Client Interface
A TLS Connectivity Checking
This procedure will apply when support is indicated in the response to the REGISTER request by means of the presence of the string "connectivity-check" in the Server header field e.g.
Server: OpenScape Voice_v3.0 connectivity-check or
Server: connectivity-check
Note: In particular this should deal with SIP client control switchover to another
node. The TLS connection to the old node will be found to be broken, and the subsequent connection attempt should result in connection to a different node. A SIP Client should be able to be configured with a time interval (T) that determines the time between connectivity checks. Following successful
completion of a connectivity check, a SIP Client should conduct the next check at time T-R later, where R is a random number between 0 and 20% of T. The Client should use an initial value of R that is seeded by MAC address.
Note: If T is 120s, then the interval between one check and the next will be a
random value between 96s and 120s. This randomness will help to even the load.
Note: Seeding in this way should ensure that if many endpoints start up at the
same time they will not all perform the first connectivity check at the same time. To perform a check, the SIP Client sends a two-octet message, where the first octet has the value 0x00 and the second octet contains a sequence number in the range 0 to 255, which is incremented cyclically for each check. The check is successful if the SIP Client receives an appropriate response or a SIP message within 5 s.
Note: The two-octet message is chosen not to conflict with any SIP message. It
can therefore be handled before passing to the SIP stack.
Note: The value of 5s should normally be sufficient for at least one TCP
If the SIP UA fails to receive the expected message within that time, it shall repeat the same message (without changing the sequence number). The SIP client discards any messages that are not SIP messages and are not expected connectivity check responses.
If after five attempts the connectivity check has not passed, the SIP client should consider the TLS connection and/or its underlying TCP connection to have failed and shall attempt to establish a new TCP connection and a new TLS connection. On successful establishment of a new TLS connection the endpoint shall attempt to register again.
B ABNF Definition of SIP Headers Server and User-Agent
The Server header field contains information about the software used by the UAS to handle the request.The User-Agent header field contains information about the UAC originating the request.
The definition of these headers is (RFC 3261):
token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
Server = "Server" HCOLON server-val *(LWS server-val) User-Agent = "User-Agent" HCOLON server-val *(LWS server-val) server-val = product / comment
product = token [SLASH product-version] product-version = token
This procedure will apply when support is indicated in the response to the REGISTER request by means of the presence of the string "connectivity-check" in the Server header field e.g.
Server: OpenScape Voice_v3.0 connectivity-check or
Server: connectivity-check
Note: In particular this should deal with SIP client control switchover to another
node. The TLS connection to the old node will be found to be broken, and the subsequent connection attempt should result in connection to a different node.
A SIP client should be able to be configured with a time interval (T) that determines the time between connectivity checks. Following successful
completion of a connectivity check, a SIP Client should conduct the next check at time T-R later, where R is a random number between 0 and 20% of T. The Client should use an initial value of R that is seeded by MAC address.
Note: If T is 120s, then the interval between one check and the next will be a
random value between 96s and 120s. This randomness will help to even the load.
Note: Seeding in this way should ensure that if many endpoints start up at the
same time they will not all perform the first connectivity check at the same time. To perform a check, the SIP client sends a two-octet message, where the first octet has the value 0x00 and the second octet contains a sequence number in the range 0 to 255, which is incremented cyclically for each check. The check is successful if the SIP Client receives an appropriate response or a SIP message within 5 s.
Note: The two-octet message is chosen not to conflict with any SIP message. It
can therefore be handled before passing to the SIP stack.
Note: The value of 5s should normally be sufficient for at least one TCP
retransmission.
If the SIP UA fails to receive the expected message within that time, it shall repeat the same message (without changing the sequence number). The SIP Client discards any messages that are not SIP messages and are not expected connectivity check responses.
If after five attempts the connectivity check has not passed, the SIP Client should consider the TLS connection and/or its underlying TCP connection to have failed and shall attempt to establish a new TCP connection and a new TLS connection. On successful establishment of a new TLS connection the endpoint shall attempt to register again.