IETF-89, London, UK

Minutes: INtermediary-safe SIP session ID (INSIPID) Working Group
=================================================================

Chairs:  Gonzalo Salgueiro (gsalguei@cisco.com)
         Keith Drage (keith.drage@alcatel-lucent.com)

Note Takers: Christer Holmberg
             Roland Jesske

Jabber Scribe: Gonzalo Salgueiro

Audio: http://www.ietf.org/audio/ietf89/ietf89-balmoral-20140304-1300-pm1.mp3

----------------------------------------------


INSIPID WG Status Update
========================



Topic:              Status update
Presenter:          WG chairs
Presentation:       http://tools.ietf.org/agenda/89/slides/slides-89-insipid-0.pdf
==================================================================================
 
It was confirmed that Hadriel will, within the week of the IETF#89 meeting, update the draft-kaplan-session-id draft, based on comments provided by Gonzalo.

 
 

Topic:              End-to-End Session Identification in IP-based Multimedia Communication Networks
Presenter:          James Polk
Draft:              draft-ietf-insipid-session-id
Presentation:       http://tools.ietf.org/agenda/89/slides/slides-89-insipid-3.pdf
==================================================================================
 
ISSUE:   1xx responses broken into two classes
 
Question:    Do we need to drop the example, as using reINVITE for call transfer is not "standard SIP"?
 
Decision:    1xx text in -05 will be changed, to not have differentite between 18x responses. Text in 9.8.1 will cover all 1xx responses, and 100 Trying, and the behavior will be the same.
 
Paul: Could we say that an endpoint that does not intend to send a final response would return a null value instead of a UUID? Requires further consideration.
 
 
ISSUE:   Secion 9.3 (Basic Call Transfer using reINVITE):
 
Question: Do we need to drop the example, as using reINVITE for call transfer is not "standard SIP"?
 
Decision: Example will be kept, but something which shows the triggering of the call transfer.
 
 
ISSUE:   Section 9.9 (Session ID in an out-of-dialog REFER Transaction)
 
Question: Can an OOD REFER contain the same Session-ID value that the SIP session which is affected?
 
Hadriel: Yes. The purpose is to be able to associate the old a new dialog, as they are part of the same call.
 
Roland agrees with Hadriel.
 
Decision:    Discussions will continue on the list.
 
 
ISSUE:    Section 11 (Security Considerations)
 
IESG review of the requirements draft indicate that more text is needed for the Security Considerations.
 
Decision:    The author will provide text, which will be discussed on the list.

 
 

Topic:              Requirements for marking SIP Sessions for logging
Presenter:          Peter Dawes
Draft:              draft-dawes-insipid-logme-reqs
Presentation:       http://tools.ietf.org/agenda/89/slides/slides-89-insipid-1.pdf
==================================================================================
 
Requirement REQ9, regarding a logging server address and related sub-clause 6.2.2, has been removed. How logged information is transferred to a server is outside the scope of the document. It was discussed whether the mechanism is still useful without REQ9.
 
Decision:    WGLC before next meeting. People asked to read the draft, and see whether something is missing.

 
 

Topic:              Protocol for Marking SIP Sessions for Logging
Presenter:          Peter Dawes
Draft:              draft-dawes-insipid-logme-solutions
Presentation:       http://tools.ietf.org/agenda/89/slides/slides-89-insipid-2.pdf
==================================================================================
             
Next version of the draft will not say anything about transferring information to a server.
 
Hadriel: Session-Id header field is good. It is included in all requests and responses, so it allows statelessness.
James: No new header, no Call-Info. Add it as Session-Id header field parameter.
 
If anyone has another solution, he/she is asked to provide it to the list.