Internet Engineering Task Force (IETF) H. Kaplan Request for Comments: 7403 Oracle Category: Standards Track November 2014 ISSN: 2070-1721A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)
Kaplan Standards Track [Page 1]
RFC 7403 Media Traceroute for SIP November 2014
Copyright Notice
1. Introduction
In many deployments, the media for SIP-created sessions does not flow directly from the originating User Agent Client (UAC) to the answering User Agent Server (UAS). Often, SIP B2BUAs in the SIP signaling path also insert themselves in the media plane path by manipulating Session Description Protocol (SDP), either for injecting media such as rich ringtones or music-on-hold or for relaying media in order to provide functions such as transcoding, IPv4-IPv6 conversion, NAT traversal, Secure Realtime Transport Protocol (SRTP) termination, media steering, etc.
Kaplan Standards Track [Page 2]
RFC 7403 Media Traceroute for SIP November 2014
For example, suppose calls from Alice to Bob have media problems. Alice would like to test the media path to each B2BUA in the path to Bob separately, to determine which segment has the issues. Alice cannot target the B2BUAs directly for each test call; she doesn't know which URIs to use to target them, nor would using such URIs guarantee the same media path be used as a call to Bob. A better solution would be to make a test call targeted to Bob, but with a SIP traceroute-type mechanism that makes the call terminate at the B2BUAs, such that she can perform test sessions to test the media path to each downstream B2BUA.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Kaplan Standards Track [Page 3]
RFC 7403 Media Traceroute for SIP November 2014 3. The SIP Traceroute MechanismThe Max-Forwards header field can already be used to generate a simple SIP-request traceroute by generating a SIP request initially using a Max-Forwards value of 0, receiving a 483 Too Many Hops response from the next-hop, and then incrementing the value for subsequent SIP requests; one would thereby reach SIP devices further and further downstream, receiving 483 from each of them.
3.1. Processing a Received Max-Forwards Header Field
As currently defined in [RFC3261], the UAS half of a B2BUA does not technically need to inspect the Max-Forwards header field value for received requests: only Proxies do. This behavior was updated by [RFC7332], such that a compliant B2BUA needs to both inspect the value in order to prevent loops, as well as copy and decrement the value as if it were a Proxy. This document also requires such behavior in order for the mechanism to succeed; therefore, a B2BUA supporting the traceroute mechanism defined in this document MUST also comply with [RFC7332].
Kaplan Standards Track [Page 4]
RFC 7403 Media Traceroute for SIP November 2014 3.2. Answering the INVITEIf a SIP B2BUA receives a dialog-creating INVITE request with a Max- Forwards header value of 0, with SDP for media-loopback based on [RFC6849], and the policies of the B2BUA allow it to answer such a request, then it is answered as if the original target of the request were the local SIP B2BUA. The normal procedures of SIP apply, as well as [RFC6849], as if the request had been targeted at the local B2BUA device as the intended destination all along.
4. Security Considerations
There are security implications for the mechanism defined in this document. Answering media-loopback calls in a B2BUA consumes resources on the B2BUA, and network bandwidth in between and, thus, exposes a vector for denial-of-service (DoS) attacks; therefore, B2BUAs should provide configuration options to control who can make such test calls, how many concurrent calls can be established and maintained, and how long calls can continue. Entities that deploy B2BUAs should set these options to values that reduce the DoS risk to an acceptable level. For example, a B2BUA might perform digest- challenge authentication with specific credentials for such calls or it might only allow specific sources to make such calls, at a specific time. Such policies are typically vendor specific based on local policies and deployment usage scenarios and cannot be explicitly defined in this document.
Kaplan Standards Track [Page 5]
RFC 7403 Media Traceroute for SIP November 2014
The security considerations of [RFC6849] also apply to this document. Since B2BUAs are not end-user devices, there is no human user to monitor the loopback session activity on the B2BUA as recommended in [RFC6849]; instead, B2BUAs should log such events or provide some form of administrative notification.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Kaplan Standards Track [Page 6]
RFC 7403 Media Traceroute for SIP November 2014
Acknowledgments