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 [email protected]IETF 80, Prague, March/April 2011
17
Embed
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:
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)
draft-ietf-sipclf-format-01(G. Salgueiro, V. Gurbani, and A. B. Roach)
• 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.
• 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.
• 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. [email protected]
• 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 messaget = received TCP message R = received messagel = received TLS messageU = sent UDP message Transport Protocol: U = UDPT = sent TCP message T = TCPL = sent TLS message S = SCTP
L = TLS
• Question: Do we separate encryption from plain text (i.e. yet another byte in the Flags field)?
Open Issues
• Current src/dest address: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. [email protected]
• 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?
• 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?
• 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? [email protected]