SIP session-ID (INSIPID) WG
Wednesday March 13th (15:10 pm - 17:10 pm)
takers: Charles Eckel, Andrew Allen
Scribe: Brian Rosen
- Chairs: Keith Drage & Gonzalo Salgueiro
bash, Note Well, Note-takers and Jabber scribes, etc.
status since IETF85
Milestone dates slipped and will need to be pushed out again
Solution draft has been now been adopted as WG document
Need to make a decision about whether to publish the Kaplan
draft as Historic in order to be referenced by the solution
of Requirements Draft (James Polk)
since IETF85 in Atlanta:
Introduced RFC 2219 conventions
Enhanced terminology section
Deprecated a couple requirements
Replaced protocol interworking section
many people have reviewed this of previous version? Almost all
hands in room raised.
discussion for the requirements draft:
What is a "communication session"? Still an open issue despite
current expansion of the Terminology section of the draft
Have we handled open issues since last meeting (i.e.,
Forking scenarios, needed to provide clarification on three
questions raised by Robert Sparks on the list:
parallel fork: consensus to treat it as two communication
sessions, one to each fork, and they need to be correlatable
serial fork: consensus to treat as two communication
sessions, one to each fork, and they need to be correlatable
B2BUA doing hunt group to two destinations: consensus is to
treat as two communcaition sessions and optionally could be
three depending upon how it is implemented. They do not need
to be correlatable in that case (if there are three).
Copious discussion on these three scenarios and whether the
requirements in the draft cover these and their
correlatability only the definition of communication session
needs to be clearer
Next question, what needs to be done to make this clear in
Section 3 draft? The defintion of communication session needs
to cover these three scenarios Robert has raised.
We need to make sure requirements are aligned and cover
explain the session id in these need for correlation in these
We have done multiple iterations of producing text that
clarifies this definition of communication session and still
have fallen short. Possibly this discussion of Robert's
scenarios will allow us to finally make a breakthrough.
Action Item: Paul Jones to produce new text for the
Terminology section that defines a 'Communication Session'
in such a way that it answers Robert's three scenarios.
Robert Sparks agrees to review and provide alternative text,
for WGLC once the forking scenarios are addressed? A few
addional issues raised that would need to be addressed prior
to a WGLC:
Robert Sparks: do we care if someone can guess the identifier?
Can someone do something bad if they can guess it? We need to
enhance security considerations section to address this.
James: using UUID so should not be guessable
Keith: no private info in there, so okay to Session ID is
public. What is left is to cover is the ability to spoof
the identifier or not and what happens if you do spoof it.
James: need to call out MAC address and any other address as
something that should not be used in creation of ID
Paul: cannot prevent someone making a new call using a spoofed
ID to create a new ID that looks like it should be correlated
with the spoofed ID.
Action Item: James Polk to
produce text for the Security Considerations section that
provides some details on spoofing and interception of the
Session ID. To be hashed out on list prior to updating
Once we have handled these final two outstanding issues we are
ready to take this draft to LC
and discussion of proposed solution (James Polk)
adopted as WG draft draft-ietf-insipid-session-id-00
Summary of changes since -01 version:
more text covering handling of uuids by network elements
that are not session ID aware
changed Section 10 compatibility section to new/old rather
than version 1/0 of Kaplan draft
Changes to Security Considerations section
Do we publish the draft-kaplan-session-id as Historic to
complete backwards compatibility?
- Robert: just need to be careful to make it clear that this
is what someone has done in the past
- Mary: if historic appropriate, should be experimental or
- Robert: take this offline to see if historic is
appropriate or not
- Christer: make sure we use the version of draft that has
ABNF compatible with that in
draft-ietf-insipid-session-id-00. It may not be the recent
version of draft-kaplan-session-id
- - Gonzalo S: we made the
decision on what version we need to publish at the last
meeting. Hadriel needs to confirm.
Andrew: don't publish as Historic, rather just leave it as a
draft and refer to proprietary and pre-standard
- Keith: can include normative statements for what new
implementations need to interwork with legacy
implementations but cannot place requirements on legacy
Mary (channeling Paul Jones) Why not come up with a new
header other than Sess-ID:
Keith: If possible, we should avoid going back on a decision
through WG consensus
Paul K: publishing the Kaplan draft as Historic does not
give it any legitimacy relative to the solution produced by
Andrew: It does make a difference with other standard
bodies, like 3GPP that reference the old Kaplan draft
Keith: this is something that 3GPP needs to solve and not
something this WG needs to be concerned with
Keith: (Question to Hadriel): Do you need this draft to made
Historic or do you prefer to keep it as a draft?
Hadriel: making it Historic would make things easier,
especially for referencing it from the INSIPID solution
Gonzalo S: That is the principal reason for doing this. We
simply need something to point to. I don't think making it
Historic affects what people will implement.
Christer: I agree. Folks will implement what they want
regardless of whether we make this Historic or not.
James: We can do this is the ADs allow a charter change.
Keith: This is not something that would require a charter
Mary: This would be good as it adds integrity to the draft
being produced by this WG
- Keith: do ADs see any problem with having this be an
individual AD sponsored draft. Answer: no problem.
- Show of hands show consensus (12 to 1) to proceed with
plans to publish as a Historic RFC and reference it from INSIPID
- Action Item: Hadriel
Kaplan to confirm appropriate version of
Action Item: Hadriel Kaplan to proceed working with ADs to
sponsor publication of the appropriate version of the
Kaplan draft as Historic
- Currently lower case. Paul K made a proposal to make it be
either case. This could cause issues with compatibility with
draft-kaplan-session-id. Take discussion to the list.
Cascading Conference Bridges Call Flow
- James explained the newly added Section 9.6 of cascading
This isn't defined anywhere and would require normative text
conference bridges SHOULD provide the same uuid for the
- Charles: bridging together two existing conferences, each
created with its own uuid, will not conform to this. Need to
call it out as exception case.
Paul K: I understand what you are doing but it feels wrong.
- Hadriel and Mary: Let's keep this simple. We should just
drop this since we don't need to monitor to this degree.
Keith: So what does this mean for the document?
Hadriel: Take this stuff out entirely as it is unnecessarily
Paul K: This is the first slide down a slippery slope. How
many more of these corner cases would we consider?
- Action Item: Paul Kyzivat to initiate discussion on the
list about whether (and how) we consider cascading conference
bridge call flow (Section 9.6)
Disaggregated Media Call Flow
- - This scenario was raised by
Brett Tate on the list
Call from Alice to Bob forked by B2BUA to Bob's phone and Bob's
computer for audio call leg and video call leg, respectively.
Hadriel pointed out that B2BUA could make two of them be the
same (e.g. Alice to Bob's phone is one, B2BUA to Bob's computer
is a second)
Paul K: From
the point of view of the Session-ID this is
topologically identical to a conference
- Agreement there are 3 communication sessions, similar to a
conference of 3.
James: This is not in the current version of the draft, so would
need to be added if we reach consensus it needs to be there
Paul K: This is a perfectly legitimate example.
Andrew: Support having it in the document but keeping it simple.
Keith: Do we ask the editors to make any changes as a result of
- Action Item: James Polk to
initiate discussion on the list about how we handle
disaggregated media call flow raised by Brett Tate
- Right now the solution draft swaps the value and the param
in the messages coming the opposite direction.
Hadriel proposes that we do not do that at least for the
responses to the requests. At least within the transaction
we keep the value and remote value in the same order.
James: this breaks the current ABNF
Hadriel: No it doesn't
- Hadriel: motivation is two-fold (1) compatibility with
Kaplan draft and (2) in parsing engine don't want to swap,
just limit it to copying headers
Keith: running out of time must go to the list
Action Item: Hadriel Kaplan to raise on list the backwards
compatibility request to keep value and remote value in
the same order (i.e. swapping of value and param not
Next steps, action items, etc.
Editors to update docs with agreements reached so far in -01
version of the WG draft
Are more virtual interims needed?
Item: Keith Drage to take to list discussion of whether
further virtual interims are required to make progress in a