Service Providers
Polycom, Inc.
37
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
ITSP Profile X – SIP
::X_InsertRemotePartyID
parameter must be set to YES or 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.
STUN and ICE
The device supports standard STUN based on RFC3489 and RFC5389 for passing inbound RTP packets
to the device sitting behind NATs. The parameters that control the STUN feature are found in the
ITSP
Profile X – General::
section:
● STUNEnable
– Enables this feature (default is NO or FALSE).
● STUNServer
– The IP address or domain name of the external STUN server to use. The STUN
feature is disabled if this value is blank, which is the default.
● X_STUNServerPort
– The STUN Server’s listening UDP port. Default value is
3478
(standard STUN
port).
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 a STUN binding request right before making or answering a call on
SP1/2. 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 goes on without using external
address in the SDP.
Standard RTP requires the use of an even-numbered port in the m= line. If the external port is not an even
number, the device changes the local RTP port and redoes STUN, and continues to do this as many as four
times or until an even external port number is found. If the fourth trial still results in an odd external port
number, the call goes on without using an external address in the SDP.
The device 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
ITSP Profile X – General
::X_ICEEnable
parameter to YES (or TRUE). The default is NO (or FALSE).
ICE is effective if STUN is also enabled. However, STUN is 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 device
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.
If ICE is enabled and the peer’s SDP has more than one candidate, the 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. Otherwise, the
The devices uses the srflx address in the m= and c= lines of the SDP if STUN is enabled and
successful.
