Subject: [Insipid] Notes of INSIPID Session at IETF 89

From: <[email-masked]>
Date: Wed, 5 Mar 2014 11:24:27 +0100

Notes taken by Roland Jesske

INSIPID WG Status Update                                            
Chair Slides issue Kaplan Draft:
Kaplan Draft on Session-Id will be updated till end of this week.

1. Presentation
End-to-End Session Identification in IP-Based Multimedia Communication Networks   (James Polk, 15) 
draft-ietf-insipid-session-id

Follow-Up on BT's Comments:
Two classes of responses are proposed either these reached the endpoint and the others who have not reached the endpoint. 
Christer: why do we need this two classes. Why to include a session-id into a 181.
Hadriel: proposing to make such requirement optional.
Assumption is not to distinguish between different sorts of Responses. either if they are indicating a session progressing or a provisional response sent by the destination
Thus section 9.8.1. will cover all 1xx and 100 Trying responses with the same behavior.

Open Issue1:
. Section 9.3 (Basic Call Transfer using reINVITE) : 
. Standard SIP signaling does not use an INVITE to perform a call transfer.  However, it is common for PBX systems to perform a transfer "behind the scenes" wherein a REFER is not consistently utilized.  
Decision is to keep the scenario. And some descriptive text how to trigger such Call transfer.

Open  Issue 2:
. Section 9.9 (Session ID in an out-of-dialog REFER Transaction) : 
. In this section, we use {X,Y} as the Session-ID related to the OOD REFER exchange.  This ensures that the exchange is treated as a distinct session.
Decision: This was shifted to the list. Different opinions appeared to have either the same session-id or different session-id for this use case.

Open Issue 3:
. Section 11 (Security Considerations) : 
. IESG Review of Session-ID Requirements draft confirms we need to beef up the security considerations, especially privacy-related concerns. 
Decision: Editor will provide some text and this will be discussed on the list.

2. Presentation
Requirements for Marking SIP Messages to be Logged    (Peter Dawes, 5)
draft-dawes-insipid-logme-reqs

Presentation of draft and Problem description.
WG adoption was on 1. March 2014 as draft-ietf-insipid-logme-reqs-00
this draft does not include to transfer information towards an central server. This is only describing the requirements of collecting the log's.

Conclusion: It was commented that this document is still useful without this requirement. Nevertheless if somebody wants to have such requirement back it needs to have an indication. 

Proposal is to do some text so say that the transport of the logged file is out of scope of this document. Further discussion on this text needed.

3. Presentation  Solutions for Marking SIP Messages to be Logged (Peter Dawes, 25)
draft-dawes-insipid-logme-solutions

This version still contains some text with regard to the transfer of logged information to a central server.
Further consideration of this text needs further wordsmiting.

Three proposals on the mechanism are existing:

1. Define a new header: LogMe test CaseName="test01"
2. Use of Call-Info Header with purpose=debug
2. Extend the Session-ID with an additional value debug="testCaseName"

No decision was taken but discussion on the list is needed which of the three proposals should be used.

Best Regards

Roland

Mit freundlichen Grüßen; With Best Regards
Roland Jesske

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Carsten Müller
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262 
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.