A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)
Extracted elements (12)
B2BUAs in SIP deployments frequently insert themselves into the media plane for transcoding, NAT traversal, SRTP termination, etc., making it difficult to diagnose media failures because no AOR exists to target individual B2BUAs and targeting them directly would not guarantee the same media path as a real call.
The mechanism reuses the existing Max-Forwards traceroute approach (analogous to IP TTL) combined with RFC 6849 media-loopback SDP, allowing the originating UAC to test the media path to each successive B2BUA without requiring knowledge of their addresses or URIs.
B2BUAs that do not support this mechanism respond to a Max-Forwards 0 INVITE with 483 Too Many Hops, which is indistinguishable from the original SIP traceroute behavior defined in RFC 3261; the UAC will not receive a media-loopback session from such hops.
The traceroute mechanism depends entirely on RFC 6849 for media-loopback SDP semantics and on RFC 7332 for correct Max-Forwards handling by B2BUAs; deployments where B2BUAs do not support RFC 7332 will not be able to use this traceroute function.
A B2BUA supporting the traceroute mechanism defined in this document MUST also comply with RFC 7332, which requires B2BUAs to inspect the Max-Forwards value to prevent loops and to copy and decrement it as if acting as a proxy.
If a B2BUA receives a media-loopback INVITE with Max-Forwards of 0 but its local policy does not allow answering it, it SHOULD respond with 483 Too Many Hops per RFC 3261, behaving as it would without this traceroute support.
In the 200 response to a traceroute INVITE, the B2BUA MUST add a Reason header (per RFC 3326) with protocol field 'SIP', cause field '483', and reason-text 'Traceroute Response' to distinguish a traceroute hop answer from a final UAS answer.
The Reason header with SIP/483/"Traceroute Response" in a 200 OK signals to the UAC that Max-Forwards reached 0 at this B2BUA; the absence of this Reason header in a 200 OK from a loopback INVITE signals that the final target UAS was reached, completing the traceroute.
To initiate a media-plane traceroute, the UAC sends a SIP INVITE to the target AOR with Max-Forwards set to 0 and SDP constructed per RFC 6849 media loopback. Each subsequent test call increments Max-Forwards by 1 to reach the next B2BUA further downstream.
When a B2BUA receives a dialog-creating INVITE with Max-Forwards of 0 and RFC 6849 media-loopback SDP, and its policy permits, it answers the INVITE as if it were the intended destination, establishing a media-loopback session per RFC 6849.
Answering media-loopback calls consumes B2BUA resources and network bandwidth, creating a denial-of-service vector. B2BUAs should provide configuration options to control who may initiate such test calls, the maximum number of concurrent loopback sessions, and maximum call duration.
Since B2BUAs are not end-user devices, there is no human to monitor loopback session activity as recommended by RFC 6849; B2BUAs should instead log such events or provide administrative notification mechanisms.