Obihai OBi100 Administration Manual Download

Page: 97 / 220

STUN and ICE

The OBi supports standard STUN based on RFC3489 and RFC5389 for passing inbound RTP packets to the device sitting
behind NAT’s. The parameters that control STUN feature can be found under the section ITSP Profile X – General::

STUNEnable – To Enable this feature (default is NO or 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 does not require STUN). The device to send out a STUN binding request right before making or answering a call on
SP1/2. If the request is successful, the device decodes the mapped exteranal address and port from the binding response
and use 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 external address in the SDP.

Standard RTP requires the use of even number port in the m= line. If the external port is not a even number, device changes
the local RTP port and redo STUN, and will continue to do this up to 4 times or until an 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.

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, however, is NO (or FALSE).

Note that ICE would be 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, 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 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, device concludes ICE and uses this
candidate to communicate with the peer subsequently. Otherwise, the OBi allows up to 5s to wait for the response from all
the candidates, and selects the highest priority one that has a response. Once ICE is completed successfully, the device will
further apply symmetric RTP concept to determine the peer’s RTP address (i.e., send to the address where peer’s RTP
packets are coming from).

ITSP Driven Distinctive Ringing

OBi device offers 10 ring and 10 call-waiting tone patterns in each ring profile. These patterns are numbered from 1 to 10.
Each pattern also comes with a configurable name. A different default ring may be assigned to each trunk on the device.

An ITSP can tell OBi device which ring to use by name for a call routed to SP1/SP2 by inserting an Alert-Info header in the
SIP INVITE sent to the device. The Alert-Info must include a URI. For example:

Alert-Info:

http://www.xyz.com/some-folder/bellcore-dr4

When the device receives this, it will look for a ring tone name or call-waiting tone name in the ring profile that matches the
Alert-Info URI. Ring tone names are compared case- insensitively. If a match is found, device plays the corresponding ring or
call-waiting tone. Otherwise, device plays the default ring.