Internet DRAFT - draft-kaplan-dispatch-sip-traceroute
draft-kaplan-dispatch-sip-traceroute
twork Working Group H. Kaplan
Internet Draft Acme Packet
Intended status: Standards Track October 14, 2011
Expires: April 21, 2012
A Media-based Traceroute Function for
the Session Initiation Protocol (SIP)
draft-kaplan-dispatch-sip-traceroute-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 14, 2011.
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Kaplan, et al Expires April 24, 2012 [Page 1]
Internet-Draft Media-Traceroute for SIP October 2011
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License.
Abstract
SIP already provides the ability to perform hop-by-hop traceroute
for SIP messages using the Max-Forwards header field, in order to
determine the reachability path of requests to a target. A new
mechanism for media-loopback calls is also being defined separately,
which enables test calls to be generated which result in media being
looped back to the originator. This document is a strawman proposal
for a means of performing hop-by-hop traceroute-style test calls
using the media-loopback mechanism, in order to test the media path
when SIP sessions go through media-relaying B2BUAs.
Table of Contents
1. Terminology...................................................2
2. Introduction..................................................3
2.1. Existing SIP Traceroute Mechanism........................4
3. Solution Overview.............................................4
4. Solution Details..............................................5
4.1. Generating a B2bua-Hops Header Field.....................5
4.2. Processing a Received B2bua-Hops Header Field............5
4.3. Answering the INVITE.....................................6
5. Open Issues...................................................6
6. Security Considerations.......................................6
7. IANA Considerations...........................................7
8. Acknowledgments...............................................7
9. References....................................................7
9.1. Normative References.....................................7
Authors' Addresses................................................7
1. 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 RFC 2119. The
terminology in this document conforms to RFC 2828, "Internet
Security Glossary".
B2BUA: a SIP Back-to-Back User Agent, which is the logical
combination of a User Agent Server (UAS) and User Agent Client
(UAC).
UAS: a SIP User Agent Server.
Kaplan Expires - April 2011 [Page 2]
Internet-Draft Media-Traceroute for SIP October 2011
UAC: a SIP User Agent Client.
Traceroute: a mechanism to trace a path of hops from an originator
to a destination. For IP, this is typically done using the TTL
field of the IP header, starting at the value 1 and incrementing by
1 as each IP hop responds with an ICMP error. For SIP this can be
done using Max-Forwards header field starting with the value 0, in a
similar fashion to the TTL field.
It is assumed the reader is already familiar with [draft-media-
loopback].
2. Introduction
In many deployments, the media for SIP-created sessions does not
flow directly from the originating user's UAC to the answering
user's UAS. Often, SIP B2BUAs in the SIP signaling path participate
in the media plane, 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, SRTP termination, media steering, etc.
As more and more SIP domains get deployed and interconnect, the odds
of a SIP session crossing such media-plane B2BUAs increases, as well
as the number of such B2BUAs any given SIP session may go through.
In other words, any given SIP session may cross any number of
B2BUAs both in the SIP signaling plane as well as media-plane.
If failures or degradation occurs in the media plane, it is
difficult to determine where in the media path they occur. In order
to aid managing and troubleshooting SIP-based sessions and media
crossing such B2BUAs, it would be useful to be able to test the
media path to each B2BUA separately from the source. A mechanism to
perform media-loopback test sessions is being defined in [draft-
media-loopback], but it would be difficult to use the mechanism
directly to test B2BUAs because typically the B2BUAs do not have an
AoR to be targeted, nor is it known a priori which B2BUAs will be
crossed for any given session.
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, because she
doesn't know what 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.
Kaplan Expires - April 2011 [Page 3]
Internet-Draft Media-Traceroute for SIP October 2011
This document defines how such a mechanism can be employed, using
the [draft-media-loopback] mechanism with a new SIP header field
such that a SIP User Agent can make multiple test calls, each
reaching a B2BUA further downstream. Each B2BUA in the path that
supports this mechanism would answer the media-loopback call, and
thus the originating SIP UA can test the media path up to that
B2BUA.
2.1. Existing SIP Traceroute Mechanism
The Max-Forwards header field can already be used to perform a SIP-
request traceroute mechanism 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, thereby reaching SIP devices further and
further downstream and receiving 483 from each of them.
Unfortunately, using the Max-Forwards header field for a media-
loopback traceroute will not work for this document's purpose, for
several reasons. The first problem is that Max-Forwards
verification is done early in SIP message receive processing.
Secondly, SIP Proxies that have no involvement in the media-plane
handle it as a failure event, responding with 483. Third, a 483
response may not contain a Contact URI, so that the reached SIP
device isn't even known. Lastly and most importantly, many SIP
B2BUAs reset the Max-Forwards header field value to 70 or some new
value - even those that have no involvement in the media-plane.
3. Solution Overview
This document proposes a new SIP header field named "B2bua-Hops",
with behavior similar to Max-Forwards. Like Max-Forwards, B2bua-
Hops encodes an integer value from 0-255 which gets decremented by
each SIP hop and if it reaches 0 stops subsequent forwarding.
Unlike Max-Forwards, only B2BUAs involved in the media-plane would
decrement the B2bua-Hops value.
[Note: it is TBD if this should be done using a SIP header, or an
SDP attribute instead, or both]
To perform a SIP media-plane traceroute, the originating UAC
generates a SIP INVITE to a target AoR, with SDP based on [draft-
media-loopback], and a B2bua-Hops header value of 0. When the
request reaches the first B2BUA that supports this mechanism, that
B2BUA will answer the INVITE to establish the dialog and create a
media-loopback session. The originating UAC can then generate
another INVITE to the same target AoR with a B2bua-Hops header value
Kaplan Expires - April 2011 [Page 4]
Internet-Draft Media-Traceroute for SIP October 2011
of 1, which will reach the second B2BUA that supports this
mechanism, and so on.
Using this mechanism a SIP UAC can test the path from itself to each
successive B2BUA on the path to a target. Such a mechanism could
also be useful for establishing a permanent test call between an
Enterprise and a Service Provider across a SIP Trunk, for example,
or for automated measurement systems to test the media path between
domains, etc.
4. Solution Details
The focus of this document is enabling UACs to perform media-path
loopback test calls using a traceroute-style mechanism. Currently
this involves using a new SIP header, and the procedures for the
header comprise the majority of the normative text in this section.
Arguably the new SIP header is useful beyond the purposes of media-
loopback testing, for example to detect looped calls. This document
makes no judgment in that regard, and further discussion is needed
in the IETF beforehand.
4.1. Generating a B2bua-Hops Header Field
A SIP User Agent Client MAY generate a B2bua-Hops header field in
any dialog-creating INVITE request, and SHOULD use the default value
of 70 unless it has some reason to use another value. Using another
value may make sense for cases such as traceroute testing, for
example.
[Note: it is TBD if the recommendation should be a "SHOULD" or
"MUST" to generate the header in all out-of-dialog requests, instead
of "MAY"]
B2BUAs logically generate all SIP headers on their UAC side as a
User Agent, but for the purposes of this document the value of the
B2bua-Hops header field generated on the UAC side MUST be copied
from the value received on the UAS side of the B2BUA. If the B2BUA
is involved in the media plane, it MUST decrement the copied value
by 1 before encoding. All dialog-creating INVITE requests generated
by a B2BUA based on receiving a dialog-creating INVITE request MUST
use the same (decremented) value.
SIP devices MUST NOT reset or increase the B2bua-Hops value of
received SIP messages, ever.
4.2. Processing a Received B2bua-Hops Header Field
When a SIP B2BUA or UAS receives an out-of-dialog SIP INVITE
request, it checks for the existence of the B2bua-Hops header field.
Kaplan Expires - April 2011 [Page 5]
Internet-Draft Media-Traceroute for SIP October 2011
If one exists and its value is 0, the device MAY act as the final
recipient and process the request as defined in section 5; otherwise
the request MUST be rejected with a 483 (Too many hops) response,
and a local Contact URI MUST be included in the 483 response. If
the B2bua-Hops header field value is greater than 0, the SIP device
MUST decrement it by 1 as described in the previous section and
continue SIP processing.
[Note: it is TBD if responding with 483 is appropriate, vs. a new or
other existing response code]
4.3. Answering the INVITE
If a SIP B2BUA or UAS receives a dialog-creating INVITE request with
a B2bua-Hops header value of 0, with SDP based on [draft-media-
loopback], and the policies of the B2BUA/UAS allow it to answer such
a request, then it is answered as if the target of the request were
the local SIP B2BUA/UAS. The normal procedures of SIP apply, as
well as [draft-media-loopback], as if the request had been targeted
at the local device all along.
[Open Issue: how does the UAC know the request reached a B2BUA vs.
the final UAS? (e.g., how does it know when to stop testing?)]
5. Open Issues
There are many ways to achieve the goals of this document, each with
pros/cons. If the IETF decides to take this work on in a Working
Group, the Working Group can debate which approach is the best.
This section highlights some of the known open issues or options.
- Should the mechanism be done using separate INVITEs as described
in this document, or rather as a single INVITE and forked at each
B2BUA, creating separate dialogs implicitly?
- Should we use a SIP header or an SDP attribute, or both?
- Should we attempt to "fix" Max-Forwards instead of creating a new
header? (is it even fixable?)
- Should we use B2bua-Hops for things beyond media-loopback? (e.g.,
in other method types, for all requests all the time)
- How does the UAC know when the request finally reached the
ultimate UAS? (e.g., use a param somewhere)
6. 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; therefor,
B2BUAs should have some means of controlling who can make such test
Kaplan Expires - April 2011 [Page 6]
Internet-Draft Media-Traceroute for SIP October 2011
calls, how many concurrent calls can be established and maintained,
and for how long. Such policies are typically vendor-specific and
do not need to be defined in this document.
7. IANA Considerations
This document makes no request of IANA yet - if the new header
approach is maintained, then a new header will be registered.
8. Acknowledgments
The general concept of performing media-loopback on a hop-by-hop
basis using a decrementing header traceroute style approach came out
of discussions several years ago, between the author, Kaynam
Hedayat, Nagarjuna Venna, Patrick MeLampy, and others. Other people
that have contributed to the topic over the years since then: Zaid
Ally, Dianna Stiller, Jon Boone, and several others whom I have lost
the names of since.
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
9. References
9.1. Normative References
[draft-media-loopback] Hedayat, K., et al, "An Extension to the
Session Description Protocol (SDP) for Media Loopback", draft-ietf-
mmusic-media-loopback-16, September 2011.
Author's Address
Hadriel Kaplan
Acme Packet
Email: hkaplan@acmepacket.com
Kaplan Expires - April 2011 [Page 7]
