Internet DRAFT - draft-kaithal-sipclf-sip-log-information
draft-kaithal-sipclf-sip-log-information
SIPCLF Adarsh. Kaithal
Internet-Draft Sandeep. K S
Intended status: Standards Track Cisco Systems, Inc.
Expires: October 11, 2012 April 9, 2012
Session Initiation Protocol (SIP) Extension for logging and debugging
draft-kaithal-sipclf-sip-log-information-00
Abstract
The current mechanisms to debug issues in SIP network are not very
efficient. It requires to enable debugging logs across different
devices, recreate the problem and then collect the logs. The idea is
to provide a solution to automatically enable relevant logs (SIP
messages and any other debugging logs meaningful to SIP devices), and
also to indicate where the logs are to be collected or stored. The
enabling of logs will happen at all the SIP devices(upstream or
downstream). This will help to get the logs from all the SIP devices
in a Common logging format (CLF). The solution extends SIP to
provide the infrastructure to enable logging for upstream and
downstream devices with each server deciding how much troubleshooting
information it wants to log - with freedom to simply ignore requests
if required. This document specifies a new header called "Log-Me"
Header in all the SIP messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 11, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kaithal & K S Expires October 11, 2012 [Page 1]
Internet-Draft SIP based debugging and logging April 2012
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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4
5. Log-me Header Field Definition and Syntax . . . . . . . . . . . 4
6. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Kaithal & K S Expires October 11, 2012 [Page 2]
Internet-Draft SIP based debugging and logging April 2012
1. Introduction
Session Initiation Protocol (SIP) is gaining popularity in the VoIP
Network. Many deployments, currently, have deployed SIP for their
VoIP network. Because of the huge deployments, isolating the problem
in the network and troubleshooting it becomes very difficult. Also,
If the problem happens in high traffic condition, or happens
intermittently, collecting the right set of debugging logs is very
difficult for further fault analysis.
There is need for an effective troubleshooting mechanisms embedded in
the signalling so that logs from all the devices can be collected for
that particular call and stored in a common location for
troubleshooting.
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]. This
document only uses these key words when referencing normative
statements in existing RFCs."
3. Background
Troubleshooting in VOIP network is challenging as the signaling and
media follow different path and Different equipment.
Scenario
UA1----B2BUA1-----P1------P2-------B2BUA2------UA2
UA1 wishes to make a call to UA2, However, due to network Topology,
UA1 has to go via B2BUA1 ,Proxy 1 (P1) , Proxy2 (P2) and B2BUA2 to
reach UA2. Likewise, all requests between UA2 and UA1 must also
traverse through the same path.
UA1 makes a SIP call to UA2. This call has some issue. In order to
debug the issue, logs need to be enabled at all the SIP devices in
the network. It involves a lot of time and effort collect the logs
and troubleshoot it.
The "Log-Me" extension header field allows all the SIP devices
(upstream and downstream) to start collecting desired logs, store it
in to a common location and available for debugging. It may store
the data in Common Logging Format so that It can be fed to a device
Kaithal & K S Expires October 11, 2012 [Page 3]
Internet-Draft SIP based debugging and logging April 2012
which make the troubleshooting faster moreover the logs are in a
standard format and easier to troubleshoot. This header element's
function is to invoke tracing and troubleshooting functions at each
"hop" in the signaling path for the call. Additionally, it includes
a unique "tag" to allow the information to be associated with the
particular call for proper correlation..
4. Applicability Statement
The Log-me mechanism is applicable to all the SIP entity in the
network which includes UAS,UAC, Proxy,B2BUA etc.
1) Each entity is free to simply ignore request , if it is not
interested in log collection, or busy with other activities..
2) Each entity can add its own "Log-Me" header and provide the path
for the log collection..
3) Each entity is free to log any information which is useful for
troubleshooting.
4) If an entity does not understand the header then it can simply
ignore it.However, it should not remove the header, as removing stops
the Possibility for logging at the next hop.
5) If SIP signalling is secure then logging MUST be secure.
6) If B2BUA gets a "Log-Me" header then it MUST NOT remove it. It
MAY modify or append "Log-Me" header.
5. Log-me Header Field Definition and Syntax
Kaithal & K S Expires October 11, 2012 [Page 4]
Internet-Draft SIP based debugging and logging April 2012
Log-Me = "Log-Me" HCOLON log-value *(COMMA log-value)
log-value = log-type 1*(SEMI log-params)
log-type = "mailto" / "http"/ "syslog" / "tftp" /
"ftp" /"sftp" / "local" / other-type
log-params = log-maddr /log-uri/
log-username/log-password/log-tag
log-maddr= "maddr" EQUALS host
log-uri = "uri" EQUALS userinfo
userinfo = user "@" host
log-username = "username" EQUALS user
user = 1*( unreserved / escaped / user-unreserved )
log-password= "password" EQUALS*( unreserved /
escaped / "=" / "+" / "$" / "," )
log-tag = tag EQUALS token
other-type = token
Example :
Log-Me:mailto;uri=akaithal@cisco.com;tag=sdfrfgf43
Log-Me:syslog;maddr=9.45.45.34;username=akaithal;
password=addfere2;tag=sdfdsfe
Log-Me:local;tag=sdfdsfe
local means it should store the data locally.
Support for the Log-me header field MAY be indicated by a UA by
including the option-tag "log" in a Supported header field.
Log-me header field value MUST consist of exactly one log-type. If
the log-type is mailto then it should have a log-uri (i.e. an email
address). For any other log-type log-username.log-password and log-
maddr is MUST. One entity can put more than one Log-me header in
multiple line or separated by comma. In case there are more than one
Log-me header then it is the intermediate end point's decision to put
the log in all places mentioned, or choose any one of them. If log-
uri and log-username are present then user portion of log-uri and
log-username MUST be same.
This is an optional header and can be built only in a SIP request and
response. The header can also be inserted by any intermediate entity
in the network.
Kaithal & K S Expires October 11, 2012 [Page 5]
Internet-Draft SIP based debugging and logging April 2012
Header field where proxy ACK BYE CAN INV OPT REG
---------------------------------------------------------------
Log-Me R o - o - o o o
1xx o - o - o o o
2xx o - o - o o o
3xx o - o - o o o
4xx o - o - o o o
5xx o - o - o o o
6xx o - o - o o o
SUB NOT REF INF UPD PRA
---------------------------------
o o o - o -
o o o - o -
o o o - o -
o o o - o -
o o o - o -
o o o - o -
o o o - o -
If a SIP REFER message is sent to an endpoint and contains the
"Log-Me" header, not only is the REFER method itself traced, but any
call initiated via the REFER mechanism is also traced. If "Log-Me"
header is present in the request then entity should at least log SIP
messages and any other relevant information which is required for
debugging.
6. UAC Behaviour
If UAC supports this extension the it should add "log" tag in the
supported header in the request or response. In case UAC wants the
call to be logged then it MUST add a Log-me header with the details
to enable logging.
UAC receives response with the "Log-Me" header then it starts
collecting the data from that response on words till the end of the
call. It logs messages which is mandatory along with other logging
information which is essential for troubleshooting from that device
point of view.
Kaithal & K S Expires October 11, 2012 [Page 6]
Internet-Draft SIP based debugging and logging April 2012
7. UAS Behaviour
UAS receives request with the "Log-Me" header then it starts
collecting the data from that request on words till the end of the
call. It logs messages which is mandatory along with other logging
information which is essential for troubleshooting from that device
point of view.
If UAS supports this extension the it should add debug tag in the
supported header in the request or response. In case UAS wants the
call to be logged then it MUST add a "Log-Me" header with the details
in any of the responses to enable logging.
8. Proxy Behaviour
1) If proxy supports "log" extension and it gets "Log-Me" header in
any of the request or response then it SHOULD process it and collect
relevant logs. Additionally it can do one of the following
a) Forward the received "Log-Me" header as is.
b) Add additional "Log-Me" header with details.
c) Add its own "Log-Me" header and removing the received "Log-Me"
header.
The above action are applicable for the forked requests as well.
2) If proxy does not support "log" extension and it receives "Log-Me"
header then it MUST NOT remove it from the requests or responses.
9. Security Considerations
There are security consideration with this header as password is
exposed.
1) It is RECOMMENDED to have calls over TLS to send "Log-Me" header.
2) It is RECOMMENDED for Intermediate devices to remove "Log-Me"
header if the next hop is not TLS. Alternatively it MAY modify
"Log-Me" header local log type.
10. IANA Considerations
There is no IANA consideration for this draft.
Kaithal & K S Expires October 11, 2012 [Page 7]
Internet-Draft SIP based debugging and logging April 2012
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Adarsh Kaithal
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: akaithal@cisco.com
Sandeep K S
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: sandks@cisco.com
Kaithal & K S Expires October 11, 2012 [Page 8]
