SIP Tracing Facility

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.

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.

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.)

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

| | | | | 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| | | |<--------------| | | | | | | ]]>

;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;tag=RTYU Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;tag=RTYU Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;tag=RTYU Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;tag=RTYU Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;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 ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: 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 ;tag=8675310 To: Alice ;tag=RTYU Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: trace Content-Type: application/sdp Content-Length: ... [SDP omitted] --trace-- ]]>

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.

Initial version.