1 / 17

Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)

Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) draft-ietf-sipclf-format-01 (G. Salgueiro, V. Gurbani, and A. B. Roach) Presenter: Vijay Gurbani IETF 80, Prague, Czech Republic April 1, 2011. gsalguei@cisco.com IETF 80, Prague, March/April 2011.

lysandra-dodson
Download Presentation

Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) draft-ietf-sipclf-format-01 (G. Salgueiro, V. Gurbani, and A. B. Roach) Presenter: Vijay Gurbani IETF 80, Prague, Czech Republic April 1, 2011 gsalguei@cisco.com IETF 80, Prague, March/April 2011

  2. Current CLF Format gsalguei@cisco.com IETF 80, Prague, March/April 2011

  3. Sample CLF Record • Example: gsalguei@cisco.com IETF 79, Beijing, November 2010

  4. Major Changes Since IETF 79 • Three versions released since then: • draft-salgueiro-sipclf-indexed-ascii-03 • draft-ietf-sipclf-format-00 • draft-ietf-sipclf-format-01 • Introduced the <allOneLine/> notation from RFC 4475 to better represent within the confines of I-D formatting the long lines seen in a SIP CLF record. gsalguei@cisco.com IETF 80, Prague, March/April 2011

  5. Major Changes Since IETF 79 • To improve document organization and simplify syntax discussion, the SIP CLF record format is logically subdivided into three component parts: • <IndexPointers> • <MandatoryFields> • <OptionalFields> • Changed all the ip addresses and DNS names to be documentation friendly. gsalguei@cisco.com IETF 80, Prague, March/April 2011

  6. Major Changes Since IETF 79 • Introduced mechanism for treatment of empty and unparsable fields (both how they are represented and escaped). • Logging of optional fields is now divided into two sections: • Pre-Defined Optional Fields • Vendor-Specific Optional Fields gsalguei@cisco.com IETF 80, Prague, March/April 2011

  7. Major Changes Since IETF 79 • Added an additional tag to the pre-defined optional fields to log message bodies • Added text about what body types we will log and the mechanism to do so • Added an example of an optionally logged body gsalguei@cisco.com IETF 80, Prague, March/April 2011

  8. Major Changes Since IETF 79 • Added the section on logging vendor-specific optional fields • Introduced the notion of a Vendor-ID and defined its syntax (based on Syslog SD-ID format) • Fixed minor issues raised on SIPCLF list • Very extensive formatting changes gsalguei@cisco.com IETF 80, Prague, March/April 2011

  9. Open Issues • The “TLV Start Pointer” field is set to 0x0000 if there is no optional fields present. This case adds an additional and unnecessary level of implementation complexity when calculating the length of the final mandatory field (e.g. client-txn). • Proposed Solution: <TLV Start Pointer> points to the terminating line-feed (0x0A) at the end of the record. gsalguei@cisco.com IETF 80, Prague, March/April 2011

  10. Open Issues • The <IndexPointers> portion of the SIP CLF record should be restricted to only meta-data. • Proposed Solution: Move the Flag Field from <IndexPointers> to <MandatoryFields> to ensure that <IndexPointers> is purely meta-data and can be ignored if desired. This maintains all the real “data” on the second line of the record. gsalguei@cisco.com IETF 80, Prague, March/April 2011

  11. Open Issues • Current Sent/Received Flag is overloaded • Proposed Solution: Separate transport protocol and send/receive from the current Flag. Current (1 Byte)Proposed (2 Bytes) u = received UDP message Sent/Received: S = sent message t = received TCP message R = received message l = received TLS message U = sent UDP message Transport Protocol: U = UDP T = sent TCP message T = TCP L = sent TLS message S = SCTP L = TLS • Question: Do we separate encryption from plain text (i.e. yet another byte in the Flags field)?

  12. Open Issues • Current src/destaddress:port representation is not well suited for IPv6. • Proposed solution: IPv4 and IPv6 address and port SHALL be logged with the syntax: [address]:port This square bracket notation is recommended format for IPv6 address and port [RFC 5952] and it is perfectly suitable for IPv4. gsalguei@cisco.com IETF 80, Prague, March/April 2011

  13. Open Issues • Currently there are two formats to log pre-defined and vendor-specified optional fields. • Proposed solution: • A single TLV format for both pre-defined and vendor-specified optional fields • This single format is still syslog-like using tag@PEN format for the "Tag" in the TLV. PEN=0 used if it is not a vendor-specified optional field. gsalguei@cisco.com IETF 80, Prague, March/April 2011

  14. Open Issues • If an optional field occurs more than once in a SIP message (e.g. Contact, Route, Record-Route, etc.) how should this be logged? As several optional fields with the same tag? Or as a single concatenated value? Preference: Multiple TLVs with the same tag gsalguei@cisco.com IETF 80, Prague, March/April 2011

  15. Open Issues • Do we specify that pre-defined optional fields MUST be logged in ascending tag order? Or allow any order? • If pre-defined optional fields exist MUST they be logged before the vendor-specified optional fields as shown in the format diagram? Or allow any order? gsalguei@cisco.com IETF 80, Prague, March/April 2011

  16. Open Issues • Need to make a final determination of what other fields we think could be useful and need to be added to the list of pre-defined optional fields (e.g. Reason-Phrase, Refer, History-Info, Session-ID, etc.). This might become a bit of a long list that could virtually include all fields in a SIP message. Is this the desired purpose or does it become counter-productive and unwieldy to sweep everything in as a pre-defined optional field? gsalguei@cisco.com IETF 80, Prague, March/April 2011

  17. Thanks! gsalguei@cisco.com IETF 80, Prague, March/April 2011

More Related