TOC 
SIPD. Worley
Internet-DraftNortel Networks
Intended status: ExperimentalMarch 03, 2009
Expires: September 4, 2009 


SIP Tracing Facility
draft-worley-trace-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 September 4, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document defines a SIP option tag, "trace", to be used within SIP messages to request that SIP elements (both proxies and UASs) that receive the message reflect to the UAC the request they received and the response they gave by encapsulating the request and response in a provisional response. A new provisional response code "170" is defined to carry the request and response. This option tag is expected to be used solely for diagnostic purposes.


Table of Contents

1.  Purpose of the 'trace' option tag
2.  Syntax and Semantics
3.  Difficulties
4.  Example
5.  Security Considerations
6.  Revision History
    6.1.  draft-worley-trace-00
7.  Normative References
§  Author's Address



 TOC 

1.  Purpose of the 'trace' option tag

Currently it is very difficult to determine the routing of an out-of-dialog SIP request, even in situations without forking. In practice, the usual method is to obtain some identification of the request (usually the Call-Id value) and search through detailed logs taken at every SIP element that the request might have passed through. While effective tools to carry this out can be constructed for any particular SIP system, interoperation between different SIP systems rapidly makes this technique infeasible even if the systems have no policy of information-hiding regarding each other.

The purpose of this Internet-Draft is to propose an option tag, "trace" which requests that all recipients of all forks of a request echo a copy of the received request and the recipient's final response in a provisional response. A new provisional response code, "170", is defined to carry these echos.

Generally, retrieving tracing data is a difficult problem. An advantage of this technique for message tracing is that it uses SIP transport to gather the tracing information, which is the only transport mechanism that we have certain knowledge works.

The request and response copies carried in the 170 responses can be reassembled into the forking tree by examining their Via branch parameters. If the SIP elements involved implement the History-Info header, further information about the causes and consequences of the forks can be obtained.


 TOC 

2.  Syntax and Semantics

This Internet-Draft defines a new option-tag, "trace". If a SIP element which supports this option-tag receives a request containing "Supported: trace", the element SHOULD send a provisional response with status code 170 containing a body that contains the request and the final response that the element generated to the request. Stateless proxies will omit the body part containing the final response and transmit the 170 response upon receiving the request, since a stateless proxy has no method of retaining the request information until the final response is generated.

This Internet-Draft defines a new status code, "170", with the conventional reason-phrase "Trace". The body of a provisional response with status code 170 MUST be a multipart/related body with one or two parts, each of which has content-type message/sipfrag. One of the parts is a SIP request, and if there are two parts, the other is a SIP response.

A 170 response MUST NOT be sent with "Supported: 100rel", in order to ensure that the UAC is not compelled to send a PRACK. In any case, a UAC SHOULD never send a PRACK for a 170, even if it contains "Supported: 100rel". The element sending the 170 response must give it an appropriate to-tag, as it would with any response. The element MAY choose a different to-tag from that it uses for any other response (especially if the element normally uses 100rel for provisional responses) -- the conceit is that the 170 response is generated by a separate UAS to which the request is forked.

Technically, the receipt of a 170 response by a UAC establishes an early dialog. However, the 170 response has no further SIP-visible processing associated with it, so the UAC does not need to create an early dialog in practice, and the UAC MAY omit adding it to its dialog events. If no further responses arrive with the same to-tag (from the same SIP element as generated the 170), retaining an early dialog would have been useless. If a further response arrives with the same to-tag, the early dialog would be created by the later response.


 TOC 

3.  Difficulties

History-Info, if fully implemented by all the SIP elements, provides much of the information that "trace" would provide. On the other hand, History-Info does not capture changes in the propagated requests other than the request-URIs.

The generated 170 responses will be significantly larger than the requests that create them. (This problem is similar to that in draft-ietf-sip-hop-limit-diagnostics.) This is not a problem if a stream transport is used but can be problematic if UDP was used to send the request. This is somewhat mitigated by the fact that provisional responses are transmitted unreliably, so if an element is unable to transmit a particular 170 response, it will be dropped and not resent. In addition, the response pruning strategies discussed in draft-ietf-sip-hop-limit-diagnostics can be applied to substantially reduce the response size.

This mechanism does not provide any information regarding a request sent to a non-responding destination, which may be a very useful fact. One possible solution to that problem would be for the sending element to synthesize a 170 response apparently from the destination element, including the 408 Request Timeout response from the destination that the sending element has effectively synthesized. However, this still does not record requests sent to a non-responding destination if an alternative, responding destination is chosen via the RFC 3263 mechanisms. This suggests that trace responses should be generated not by the receipt of a request, but by the sending of a request.

This proposal to some degree parallels draft-kuthan-sipping-diag-00. The returning of copies of requests as seen by UASs covers one of the components of that draft. The other component is that proxies should identify in some way which "rule" was used to forward a request to a particular request-URI. That draft proposes to carry this information in an additional Via parameter. Within the machinery of this draft, rule information could be added to 170 responses, but only if they were generated regarding outgoing requests, not incoming requests.

The "trace" mechanism does not provide much diagnostic information regarding problems in the RFC 3263 process. In particular, failures to find a responding destination host/port/transport for a request-URI generate no 170 responses. This is improved if 170 responses are generated for transmitted requests, but the request itself does not carry information about the destination host and port. (The transport is coded in the topmost Via header.)


 TOC 

4.  Example

This example shows a typical use of "Supported: trace". Only the more significant messages are shown. 

    UAC            Proxy           UAS1         UAS2

     |               |              |            |
     |  F1 INVITE    |              |            |
     |-------------->|              |            |
     |               |  F2 INVITE   |            |
     |               |------------->|            |
     |               |  F3 180 Ring.|            |
     |               |<-------------|            |
     |  F4 180 Ring. |              |            |
     |<--------------|              |            |
     |               |  F5 CANCEL   |            |
     |               |------------->|            |
     |               |  F6 487 Term.|            |
     |               |<-------------|            |
     |               |  F7 170 Trace|            |
     |               |<-------------|            |
     |  F8 170 Trace |              |            |
     |<--------------|              |            |
     |               |  F9 INVITE   |            |
     |               |-------------------------->|
     |               |  F10 180 Ringing          |
     |               |<--------------------------|
     |  F11 180 Ring.|              |            |
     |<--------------|              |            |
     |               |  F12 200 OK  |            |
     |               |<--------------------------|
     |  F13 200 OK   |              |            |
     |<--------------|              |            |
     |               |  F14 170 Trace            |
     |               |<--------------------------|
     |  F15 170 Trace|              |            |
     |<--------------|              |            |
     |  F16 170 Trace|              |            |
     |<--------------|              |            |
     |               |              |            |

F1 INVITE

   INVITE sip:alice@atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 20
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]


F2 INVITE

   INVITE sip:alice@pc1.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]


F6 487 Request Terminated

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=qazwsx
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE


F7 170 Trace (containing F2 and F6)

   SIP/2.0 170 Trace
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=qazwsx
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Content-Type: multipart/related;boundary=trace
   Content-Length: ...

   --trace
   Content-Type: message/sipfrag

   INVITE sip:alice@pc1.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace
   Content-type: message/sipfrag

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=qazwsx
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE


   --trace--


F8 170 Trace (containing F2 and F6)

   SIP/2.0 170 Trace
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=qazwsx
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Content-Type: multipart/related;boundary=trace
   Content-Length: ...

   --trace
   Content-Type: message/sipfrag

   INVITE sip:alice@pc1.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace
   Content-type: message/sipfrag

   SIP/2.0 487 Request Terminated
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK23SX
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=qazwsx
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE


   --trace--


F9 INVITE

   INVITE sip:alice@pc2.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]


F12 200 OK

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@pc2.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]


F13 200 OK

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@pc2.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]


F14 170 Trace (containing F9 and F12)

   SIP/2.0 170 Trace
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Content-Type: multipart/related;boundary=trace
   Content-Length: ...

   --trace
   Content-Type: message/sipfrag

   INVITE sip:alice@pc2.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace
   Content-type: message/sipfrag

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@pc2.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace--


F15 170 Trace (containing F9 and F12)

   SIP/2.0 170 Trace
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Content-Type: multipart/related;boundary=trace
   Content-Length: ...

   --trace
   Content-Type: message/sipfrag

   INVITE sip:alice@pc2.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace
   Content-type: message/sipfrag

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@pc2.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace--


F16 170 Trace (containing F1 and F13)

   SIP/2.0 170 Trace
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Content-Type: multipart/related;boundary=trace
   Content-Length: ...

   --trace
   Content-Type: message/sipfrag

   INVITE sip:alice@pc2.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   Max-Forwards: 19
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:bill@pc.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace
   Content-type: message/sipfrag

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP atlanta.example.com:5061
    ;branch=z9hG4bK50UI
   Via: SIP/2.0/TCP pc.biloxi.example.com:5061
    ;branch=z9hG4bK74HH
   From: Bill <sip:bill@biloxi.example.com>;tag=8675310
   To: Alice <sip:alice@atlanta.example.com>;tag=RTYU
   Call-ID: 563456212@b2.biloxi.example.com
   CSeq: 1 INVITE
   Contact: <sip:alice@pc2.biloxi.example.com>
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
   Supported: trace
   Content-Type: application/sdp
   Content-Length: ...

   [SDP omitted]

   --trace--

 TOC 

5.  Security Considerations

A service provider desiring to keep hidden the topology of its network will not want to permit trace data to be transmitted outward from their network. This can be accomplished by removing "Supported: trace" from any request that enters the network, and by dropping any 170 responses that attempt to exit the network.

Generating trace responses increases the volume of messages generated by a SIP request. However, the increase is limited to a factor slightly larger than 2, although the increase in message traffic is concentrated toward the UAC end of the forking tree. so the trace mechanism is particularly effective in generating a denial-of-service attach. In any case, UACs SHOULD never apply "Supported: trace" to a message routinely.


 TOC 

6.  Revision History


 TOC 

6.1.  draft-worley-trace-00

Initial version.


 TOC 

7. Normative References

[sip] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT).

 TOC 

Author's Address

  Dale R. Worley
  Nortel Networks Corp.
  600 Technology Park Dr.
  Billerica, MA 01821
  US
Phone:  +1 978 288 5505
Email:  dworley@nortel.com
URI:  http://www.nortel.com