Copyright 2010-2015 Obihai Technology, Inc.
55
rport parameter value in the response; it should also prompt the server to send the response to the port where the
request originated from (i.e. according to the source port of the IP header of the packet). However, as such behavior on
the server is considered standard by many, the empty rport parameter has become superfluous in practice.
Keep Alive Messages
In addition to periodic registration with the server, the phone can be instructed to send out periodic keep alive
messages on the same network path to keep the NAT pin hole open. For this purpose, it is recommended the keep alive
messages are sent to the same proxy server responsible for registration. The keep alive messages may be dropped by
the server unprocessed. However if STUN binding request are used as keep alive messages, it is recommended that the
server return a valid STUN binding response to each request. The parameters that control the sending of keep alive
messages are:
Parameter Group
Parameter
Description
SPn Service
X_KeepAliveEnable
Enable sending of keep alive message. If set to
true
, device sends
periodic keep-alive messages to the destination specified in
X_KeepAliveServer
and
X_KeepAliveServerPort
, at the
interval specified in
X_KeepAliveExpires
. The content of this
message is the ascii string
keep-alive\r\n
SPn Service
X_KeepAliveExpires
Keep alive period in seconds
SPn Service
X_KeepAliveServer
Hostname or IP address of keep alive server
SPn Service
X_KeepAliveServerPort
UDP port of the keep alive server
SPn Service
X_KeepAliveMsgType
The type of keep alive messages to send out periodically if keep-alive is
enabled. It can be one of the following choices:
-
keep-alive: The string “keep-alive”
-
empty: A blank line
-
stun: A standard STUN binding request; device will use the
binding response to form its contact address for REGISTRATION
-
custom: use the value of
X_CustomeKeepAliveMsg
(note: option not available on OBi100/OBi110)
-
options: a valid SIP OPTIONS request. No response to this
request from the server will trigger a proxy failover if proxy redundancy is
eanbled
-
notify: a valid SIP NOTIFY request. No response to this request
frin the server will trigger a proxy failover if proxy redundancy is enabled.
SPn Service
X_CustomKeepAliveMsg
Defines the custom message to be used when
X_KeepAliveMsgType
is “custom”. The value should have the following format:
mtd=NOTIFY;event=
{
whatever
}
;user=
{
anyone
}
Where
-
NOTIFY may be replaced by any other SIP method, such as PING,
-
event parameter is optional and is only applicable if method is
NOTIFY. If event is not specified, the 'keep-alive' event will be used with
NOTIFY
-
user parameter is optional; if not specieifed, the request-uri will
not have a userid, and the TO header field will use the same userid as the
FROM header (which is the local account userid). If user is specified, it will
be used as the userid in the Request-URI and TO header.
SIP messages for keep-alive are sent only once without retransmission;
response to the SIP messages are ignored by the OBi.
SIP Proxy Server Redundancy and Dual REGISTRATION
Server Redundancy specifically refers to the OBi device’s capability to a) look for a working server to REGISTER with
from a list of candidates, and b) switch to another server once the server that it currently registers with becomes
unresponsive. As such, DEVICE REGISTRATION MUST BE ENABLED in order to use the server redundancy feature. Other
SIP requests, such as INVITE or SUBSCRIBE, are sent to the same server that the device currently registers with.
Содержание OBi1062
Страница 136: ...Copyright 2010 2015 Obihai Technology Inc 136...
