Network Settings
38
If PAID is present, the device takes the name and number from it. Otherwise, it takes the name and number
from RPID if it’s present, or from the FROM header otherwise. RPID, if present, includes the privacy setting
desired by the caller. This privacy can indicate one of the following options:
● off = no privacy requested. The device shows name and number.
● full = full privacy requested. The device hides both name and number.
● name = name privacy requested. The device shows the number but hides the name.
● uri = uri privacy requested. The device shows the name but hides the number.
Regardless, if PAID exists or not, the device always takes the privacy setting from the RPID if it’s present in
the INVITE request. Note that if the resulting caller name is “Anonymous” (case-insensitive), 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 an RPID header of
the outbound INVITE request. To enable this behavior, the ITSP Profile X –
SIP::X_InsertRemotePartyID parameter must be set to True, which is the default value of this
parameter. The device supports only two outbound caller privacy settings: 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 won’t insert PAID in outbound INVITE
requests.
You can further instruct your phone to use sip:anonymous@localhost in the FROM header by enabling
the option X_UseAnonymousFROM (that is, in this case your phone uses From: “Anonymous”
<sip:anonymous@localhost>).
Your phone also includes a Privacy: id header if X_InsertPrivacyHdr is also enabled.
NAT Traversal Considerations
If your phone sits behind a NAT router, it can discover the mapped external address corresponding to its
local SIP contact address as seen by the serverin one of the following ways:
● From the “received=” and “rport=” parameters of the VIA header of the REGISTER response sent by
the server. These two parameters tell your system its mapped IP address and port number. Your
system uses this method if you’ve enabled periodic registration on your system.
● From the response to a STUN binding request your system sent to a STUN server. This method is
used by enabling X_KeepAliveEnable and setting X_KeepAliveMsgType to stun. The
keep-alive messages are sent to the same server where a REGISTER request would be sent.
● From the value of theX_PublicIPAddress parameter. Your system always uses the mapped
external contact address in all outbound SIP requests instead of its local contact address if one is
discovered by either method when the ITSP Profile X – SIP::X_DiscoverPublicAddress option
is also enabled. The substitution of private addresses with public addresses applies to the Contact
header of any SIP requests and the c= line in SDP. If the option X_UsePublicIPAddressInVia is also
enabled, the Via address is also substituted. However, this usually isn’t necessary.
Your phone can also include an empty rport parameter in the Via header of outbound SIP requests if the
option ITSP Profile X – SIP::X_UseRport option is enabled. This parameter is sometimes needed to
prompt the server to insert an rport parameter value in the response. It should also prompt the server to
send the response to the port where the request originated from (that is, 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.