Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)
Extracted elements (18)
B2BUAs use mandatory ICE termination (generating new ice-ufrag/ice-pwd per leg) to ensure they remain on the media path for purposes such as address hiding for privacy or interworking between ICE and non-ICE endpoints.
ICE is preferred over earlier proprietary NAT traversal mechanisms (e.g., Hosted NAT Traversal / restricted-latching) because it provides cryptographic identity verification via short-term credentials, path selection in dual-stack environments, and path verification before call connection.
Optional ICE termination mode is provided for B2BUAs that do not require being on the media path under normal conditions; they insert themselves only as a fallback when direct endpoint connectivity fails, by giving their candidates lower priority.
B2BUAs that pass ICE attributes unmodified but alter the default 'm=' and 'c=' destination will be detected as an ice-mismatch by ICE endpoints, causing ICE processing to abort; the session may continue only if endpoints can reach each other on the default candidate.
In optional ICE termination mode, if the B2BUA wants to remain in the media path when direct ICE connectivity between endpoints fails or one endpoint does not support ICE, it SHOULD overwrite its candidate address as the default in the 'm=' and 'c=' lines.
When two independent ICE contexts on either side of a mandatory-termination B2BUA conclude at different times, media received by the B2BUA before the second ICE context concludes is forwarded to the other side using the default candidate address from the 'c=' line.
A B2BUA in ICE lite mode MUST send an a=ice-lite attribute and MUST include host candidates for each component of each media stream.
A B2BUA in mandatory ICE termination mode MUST NOT propagate the candidate list received in incoming SDP to the outbound SDP; it MUST only advertise its own candidate list and set its default candidate in the 'c=' and 'm=' lines.
Media plane B2BUAs MUST use the mechanism described in Section 2.2 of RFC 5245 to demultiplex STUN packets that arrive on the RTP/RTCP port.
SDP-Modifying Signaling-only B2BUAs MUST NOT change the IP address in the 'c=' line, the port in the 'm=' line, or the ICE semantics of SDP, as doing so can cause an ice-mismatch.
The signaling channel between endpoints and the B2BUA MUST be encrypted so that ICE short-term credential keys (ice-ufrag, ice-pwd) are not visible to eavesdroppers.
When a B2BUA receives multiple answers for a single outbound INVITE due to forking, it SHOULD follow the ICE termination behaviors in Sections 3.2 or 3.3 for all received answers.
When one or both endpoints are behind a NAT and a B2BUA is between them, the B2BUA MUST support ICE or at minimum ICE lite functionality as described in RFC 5245.
A B2BUA operating in mandatory ICE termination mode terminates ICE on each media leg independently, maintaining two separate ICE contexts — one with each endpoint — and bridges them together.
A B2BUA operating in optional ICE termination mode copies the received candidate list and appends its own candidates in the outbound SDP, while propagating the ufrag/password values from the originating endpoint to the remote side.
ICE short-term credentials consist of authentication tokens conveyed in the ice-ufrag and ice-pwd SDP attributes; STUN connectivity checks include a MESSAGE-INTEGRITY attribute computed as HMAC-SHA1 using the exchanged key.
In optional ICE termination mode, the B2BUA's candidates MAY be given lower priority than endpoint candidates so that direct endpoint-to-endpoint paths are tested before paths through the B2BUA.
ICE uses STUN short-term credential mechanism (HMAC-SHA1 MESSAGE-INTEGRITY) for authentication and message integrity on connectivity checks. If the signaling channel carrying ice-ufrag/ice-pwd is not encrypted, eavesdroppers can obtain the keys and defeat STUN authentication, eliminating the security benefit over Hosted NAT Traversal solutions.