Copyright 2010-2015 Obihai Technology, Inc.
57
Regardless, if PAID exists or not, the device always takes the privacy setting from the RPID if it is present in the INVITE
request. Note that if the resulting caller name is “Anonymous” (case-insensitive), the device treats it as if the caller is
requesting full privacy.
For outbound calls, the caller’s preferred privacy setting can be stated by the device in a RPID header of the outbound
INVITE request. To enable this behavior, the parameter
ITSP Profile X – SIP
::
X_InsertRemotePartyID
must be set to
true
, which is the default value of this parameter. OBi only supports two outbound caller privacy setting: privacy=off
or privacy=full. The RPID header generated by the device carries the same name and number as the FROM header. If
outbound caller-ID is blocked, the device sets privacy=full in RPID and also sets the display name in the FROM and RPID
headers to “Anonymous” for backward compatibility. The device will not insert PAID in outbound INVITE requests. You
can further instruct the phone to use
sip:anonymous@localhost
in the FROM header by enabling the option
X_UseAnonymousFROM
(that is, the phone will use in this case
From: “Anonymous” <sip:anonymous@localhost>
).
The phone will also include a
Privacy: id
header if
X_InsertPrivacyHdr
is also enabled.
STUN and ICE
The OBi supports standard STUN based on RFC3489 and RFC5389 for passing inbound RTP packets to the device when
behind NAT. The parameters that control the STUN feature can be found under the section
ITSP Profile X – General
::
-
STUNEnable
– Enable this feature (default is
false
).
-
STUNServer
– The IP address or domain name of the external STUN server to use. STUN feature will be
disabled if this value is blank, which is the default.
-
X_STUNServerPort
– The STUN Server’s listening UDP port. Default value 3478 (standard STUN port).
It should be noted that the STUN feature used in this context is only for RTP packets, not SIP signaling packets (which
typically do not require STUN). The device sends out a STUN binding request right before making or answering a call on
SPx. If the request is successful, the device decodes the mapped external address and port from the binding response
and uses them in the m= and c= lines of its SDP offer or answer sent to the peer device. If the request fails, such as
STUN server not found or not responding, the call will go on without using an external address in the SDP.
Standard RTP requires the use of even numbered ports in the m= line. If the external port is not an even number, the
device changes the local RTP port, retries STUN and will continue to do this up to 4 times or until a even external port
number is found. If the 4th trial still results in an odd external port number, the call will go on without using external
address in the SDP.
The OBi supports standard ICE based on RFC5245. ICE is done on a per call basis for automatically discovering which
peer address is the best route for sending RTP packets. To enable ICE on the device, set the parameter:
ITSP Profile X –
General
::
X_ICEEnable
to YES (or TRUE). The default is NO (or FALSE).
Note that ICE is more effective if STUN is also enabled. However STUN not a requirement for using ICE on the device. If
STUN is enabled and an external RTP address different from its local address is discovered, the OBi offers two ICE
candidates in its SDP:
-
The local (host) address (highest priority)
-
The external (
srflx
or server reflexive) address
Otherwise only the local host candidate is shown in the device’s SDP. Note that the device uses the srflx address in the
m= and c= lines of the SDP if STUN is enabled and successful.
If ICE is enabled and the peer’s SDP has more than one candidate, device sends STUN requests to each peer candidate
from its local RTP port. As soon as it receives a response from the highest priority candidate, the device concludes ICE
and uses this candidate to communicate with the peer subsequently. Otherwise the OBi allows up to 5s to wait for a
response from all candidates and selects the highest priority one that responds. Once ICE is completed successfully, the
device will further apply the symmetric RTP concept to determine the peer’s RTP address (i.e. send to the address
where the peer’s RTP packets are coming from).
