Service Providers
49
● 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
don’t 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 isn’t 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 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. 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, 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 subsequently.
Otherwise, the device allows as long as 5 seconds to wait for the response from all the candidates, and
selects the highest priority candidate that has a response. Once ICE completes successfully, the device
further applies symmetric RTP concept to determine the peer’s RTP address (that is, sends them to the
address from which the peer’s RTP packets are coming).
RTP Statistics – the X-RTP-Stat Header
When ending an established call, the device can include a summary of the RTP statistics collected during
the call in the SIP BYE request or the 200 response to the SIP BYE request sent by the peer device. The
summary is carried in an X-RTP-Stat header in the form of a comma-separated list of fields. The reported
fields are:
● PS = Number of Packets Sent
● PR = Number of Packets Received
● OS = Number of bytes sent
● OR = Number of bytes received
● PL = Number of packets lost
● JI = Jitter in milliseconds
● LA = Decode latency or jitter buffer size in milliseconds
To Next Page
Loading...
