Version 7.2 163 Mediant 800B Gateway & E-SBC
User's Manual 12. Network
T.38 No-Op: T.38 No-Op packets are sent only while a T.38 session is activated. Sent
packets are a duplication of the previously sent frame (including duplication of the
sequence number).
To configure the No-Op packet feature:
1. Enable the feature, using the NoOpEnable ini file parameter.
2. Configure the time interval during which the device sends No-Op packets when
silence occurs (i.e., no RTP or T.38 traffic), using the NoOpInterval ini file parameter.
3. For RTP No-Op packets, configure the payload type of the No-Op packets, using the
RTPNoOpPayloadType ini file parameter.
Note:
• The No-OP Packet feature requires DSP resources.
• Receipt of No-Op packets is always supported.
12.7.2.2.3 Fax Transmission behind NAT
The device supports transmission from fax machines (connected to the device) located
inside (behind) a Network Address Translation (NAT). Generally, the firewall blocks T.38
(and other) packets received from the WAN, unless the device behind the NAT sends at
least one IP packet from the LAN to the WAN through the firewall. If the firewall blocks T.38
packets sent from the termination IP fax, the fax fails.
To overcome this, the device sends No-Op (“no-signal”) packets to open a pinhole in the
NAT for the answering fax machine. The originating fax does not wait for an answer, but
immediately starts sending T.38 packets to the terminating fax machine upon receipt of a
re-INVITE with T.38 only in the SDP, or T.38 and audio media in the SDP. This feature is
configured using the T38FaxSessionImmediateStart parameter. The No-Op packets are
enabled using the NoOpEnable and NoOpInterval parameters.
12.7.2.2.4 ICE Lite
The device supports Interactive Connectivity Establishment (ICE) Lite for SBC calls. ICE is
a methodology for NAT traversal, enabling VoIP interoperability across networks to work
better across NATs and firewalls. It employs Session Traversal Utilities for NAT (STUN)
and Traversal Using Relays around NAT (TURN) protocols to provide a peer with a public
IP address and port that can be used to connect to a remote peer.
In order for clients behind NATs and/or firewalls to send media (RTP) between one
another, they need to discover each others P address and port as seen by the "outside"
world. If both peers are located in different private networks behind a NAT, the peers must
coordinate to determine the best communication path between them.
ICE first tries to make a connection using the client's private local address. If that fails
(which it will for clients behind NAT), ICE obtains an external (public) address using a
STUN server. If that fails, traffic is routed through a TURN relay server (which has a public
address).
These addresses:ports (local, STUN, TURN and any other network address) of the client
are termed "candidates". Each client sends its' candidates to the other in the SDP body of
the INVITE message. Peers then perform connectivity checks per candidate of the other
peer, using STUN binding requests sent on the RTP and RTCP ports. ICE tries each
candidate and selects the one that works (i.e., media can flow between the clients). The
following figure shows a simple illustration of ICE:
To Next Page
Loading...
