Subject: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Oct 2012 11:29:35 +0300

Hi,

a few quick comments on the following draft:

http://www.ietf.org/id/draft-ietf-insipid-session-id-reqts-02.txt

Section 3.1 talks about identifying each communication session "per
transaction". I think that paragraph should be rephrased so that it is
clearer what it means.

With respect to defining a communication session, does a communication
session always consist of one or more dialogs, or can there be a
communication session without a dialog (e.g., a bunch of MESSAGE
transactions)? The document needs to be clear on this.

>    REQ4: It must be possible to pass the identifier unchanged through
>    SIP B2BUAs or other intermediaries.

This requirement is a bit strange since anything you carry in a SIP
message *can* potentially be passed unchanged through any intermediary.
A requirement about having a mechanism that does not disclose private
information and that is not used for other purposes apart from session
correlation so that intermediaries do not have incentives to remove it
would make more sense.

>    REQ9c: The identifier should be constructed in such a way as to make
>    it suitable for transmission in SIP and RTCP [3].

There have been discussions about removing this type of requirement,
since correlating media sessions and SIP sessions is well outside the
charter of INSIPID. Note that the ability to correlate SIP sessions with
media sessions is considered by some B2BUAs as a privacy concern. Those
B2BUA will have an incentive to remove the header.

I of course understand that the IETF cannot keep anyone from doing this
if they want (given that syntax wise RTCP can carry a session
identifier). That was discussed when this WG was chartered and that is
the reason why some people in the community thought B2BUAs will remove
whatever identifier is defined as soon as it starts being used for other
purposes, regardless of what the specs say. In any case, the INSIPID
documents should not try to explicitly address those types of use cases,
per those discussions (which are documented in the DISPATCH archives).

Cheers,

Gonzalo

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 01:40:42 -0400

Gonzalo,

> transaction". I think that paragraph should be rephrased so that it is

Should we just remove "per transaction"?  Cleaning up the text, we would
have:

    For SIP messaging that either does not involve SIP servers
    or only involves SIP proxies, the Call-ID header value
    sufficiently identifies each SIP message within a
    transaction or dialog. This is not the case when either
    B2BUAs or SBCs are in the signaling path between UAs.
    Therefore, we need the ability to identify each
    communication session through a single SIP header-value
    regardless of which type of SIP servers are in the signaling
    path between UAs. For transactions that create a dialog,
    each message within the same dialog MUST use the same
    identifier.

> transactions)? The document needs to be clear on this.

REQ1 intends to require a solution for transactions and lengthier dialogs.
The issues is defining a "communication session", which is a challenge since
even "session" is vaguely defined.  I welcome any suggested wording, perhaps
something in section 2?
 
> correlation so that intermediaries do not have incentives to remove it

We have requirements on privacy.  The real intent of REQ4 is that it will be
an identifier that intermediaries MUST NOT change. However, the problem is
that this requirements document is for the solution.  The solution must
specify the requirement that intermediaries not change it.

Perhaps this:
   The solution must require that the identifier pass unchanged through
   SIP B2BUAs or other intermediaries"?

> per those discussions (which are documented in the DISPATCH archives).

The requirement is not for correlation, but that it must be possible to
transport the identifier in RTCP.  We want to allow it to be used for
correlation since it's useful for diagnostics, quality of service, etc. to
be able to correlate media flows with SIP sessions.

We agree that any such correlation specification or other use in RTCP is
outside the scope, but we don't want this identifier to be something that is
totally unsuitable for transport in RTCP.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2012 12:59:13 -0400

> even "session" is vaguely defined.  I welcome any suggested wording, perhaps

If there is an expectation that this mechanism should work for 
correlating the "legs" of a single message/response sent outside a 
dialog as it traverses B2BUAs, then *something* needs to be said about it.

I raised early on the problem of inadequate terminology. And I think we 
still have it. I just did a search of 3261, and "communication session" 
is not defined there, and is used only once. So perhaps it is an 
available term that has no established definition in the sip context.

That leaves the need to adequately define what it means. This is tied up 
with the scope of this work. We want the new ID to correlate 1:1 with 
certain kinds of things, and so presumably we want "communication 
session" to be a name for those kinds of things.

But using "communication session" brings with it the baggage of 
"session". I think it is hard to make a definition of "communcation 
session" that doesn't relate in a clear and obvious way to the notion of 
"session" used in SIP. In particular, I find it difficult to use 
"communication session" to characterize a MESSAGE and its response that 
happen to traverse an SBC. OTOH, I can imagine coming up with *some* 
term to describe a set of related messages that are tightly coupled by 
B2BUAs. (But no good name for this comes to mind.) If we were to define 
that, then that can be applied to dialog establishing messages and used 
to extend the concept to related dialogs.

IMO this is really coming in the back door at the task of defining a 
whole new architectural layer on top of existing sip concepts, made up 
of SIP UAs connected in specific ways. (This is exactly what Hadriel has 
made a non-goal in STRAW.)

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 26 Oct 2012 17:53:00 -0400

Paul,

> > The issues is defining a "communication session", which is a challenge
> > since even "session" is vaguely defined.  I welcome any suggested
> > wording, perhaps something in section 2?
> 

If Alice calls Bob, Alice will allocate a Session-ID UUID value that will
traverse through any number of B2BUAs, regardless of how many "legs" that
might be.  I think that should be clear.

What may not be so clear is what we do with things like Subscribe/Notify.
Even to me, that's not as clear.  I think that was intended to be covered by
the REQ1 text.  If that isn't sufficiently addresses, I invite some
re-wording.

> available term that has no established definition in the sip context.

But I'm not sure we should be defining it.  If we drop "communication" from
the language, does that help?  Communication is what this is all about.
It's more or less an adjective that might be superfluous. A Session is a
phone call, conference call, etc.  Communication session is the same: phone
call, conference call, etc.  Any two entities communicating would be a
communication session.
 
> session" to be a name for those kinds of things.

I'm not hung up on that word.  But, I do think you can point to a phone call
and say "that's a phone call between Alice and Bob".  If it's between them
and not part of a conference, then there would be a Session-ID representing
that two-party phone call.
 
> "session".

:-)  The whole subject of 3261.

> I think it is hard to make a definition of "communcation

Yeah, it it was just a MESSAGE out of the blue, one might argue it's not a
communication session.  But, what is it?  The remote side will reply.  If
it's part of an ongoing phone call, then it's part of that "communication
session".  If it has no relationship with an ongoing phone call, then what
is that exchange and do we want a Session-ID applied to it?  For that, I
don't care.  Others seem to want it.
 
> made a non-goal in STRAW.)

And today SIP is 16 years, 247 days old...

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 27 Oct 2012 13:24:59 -0400

> the REQ1 text.  If that isn't sufficiently addresses, I invite some

Your comments seem to address something different than the point I was 
making. My point was regarding messages out-of-dialog that are not 
dialog-establishing, like MESSAGE, PUBLISH, OPTIONS.

"Session" in 3261 mostly refers to what is now more precisely called 
"invite dialog usage". (I draw this mostly from section 13 of 3261. It 
isn't exactly consistent with the definition in section 6, which is 
drawn from SDP.)

But for a lot of practical use is is probably sufficient to consider 
Session to by synonymous with Dialog. That would encompass sub/not.

It seems clear to me that Session doesn't encompass a MESSAGE and its 
response. Nor does Session in 3261 encompass a chain of dialogs strung 
together with B2BUAs.

> But I'm not sure we should be defining it.

What is it that you are not sure we should be defining?
I think we need to be defining what it is that a Session-ID identifies. 
Ideally that means defining a term that names those things an no others. 
IMO the only issue is what the name of that term is.

> If we drop "communication" from
> the language, does that help?

No, it makes it worse. It leaves us with just "session", which is 
hopelessly overloaded already, with none of the existing definitions 
being what is intended here.

As I tried to say, I think "communication session" is a plausible 
choice, because AFAIK it doesn't already have another definition in the 
context of SIP.

Or we could coin a new term. How about XYZZY? :-)

> Communication is what this is all about.

What I am concerned with is having the definition be "I know it when I 
see it". What you are describing is an *example*. Examples are good, but 
they are not enough.

What I am looking for is an algorithm (or predicate if you prefer) that 
can be applied to any example and will say if two messages should share 
the same session-id (or same half session-id) or not.

> don't care.  Others seem to want it.

Yes, people seem to want it, and it makes as much sense as the rest.
But it is clearly not a "session" or "communication session". It needs 
to be called something else.

But what is important is that if you start by defining *that*, then 
extending it to dialogs is easy. You decide to use the same ID with the 
chained dialog-establishing transactions. And then you add a rule that 
then also related other transactions in the same dialog.

> And today SIP is 16 years, 247 days old...

Is that a good thing or a bad thing? (I'm a lot older than that and I'm 
still alive and kicking.)

My point is that this is really not just sip, it is another layer built 
using sip as a component. We might be better off recognizing this.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 27 Oct 2012 17:39:31 -0400

Paul,

> response. Nor does Session in 3261 encompass a chain of dialogs strung

I think there should be a relationship to a dialog, I agree.  This gets back
to the original idea... if we removed any B2BUA and a dialog existed
directly between two devices, anything part of that dialog would have the
same Session-ID.
 
> >> I raised early on the problem of inadequate terminology. And I think
> >> we still have it. I just did a search of 3261, and "communication
> session"

That I agree with and would accept any wording. It's defining the word
"session" -- which is not consistently defined -- that I think we should not
approach.

> As I tried to say, I think "communication session" is a plausible choice,
> because AFAIK it doesn't already have another definition in the context
> of SIP.
> 

Does that mean "it's easy"? Sure... ;-)
 
> > It's more or less an adjective that might be superfluous. A Session is
> > a phone call, conference call, etc.  Communication session is the
> > same: phone call, conference call, etc.  Any two entities
> > communicating would be a communication session.
> >
> >> That leaves the need to adequately define what it means. This is tied
> >> up with the scope of this work. We want the new ID to correlate 1:1
> >> with certain kinds of things, and so presumably we want
> >> "communication session" to be a name for those kinds of things.
> >
> > I'm not hung up on that word.  But, I do think you can point to a
> > phone call and say "that's a phone call between Alice and Bob".  If
> > it's between them and not part of a conference, then there would be a
> > Session-ID representing that two-party phone call.
> 

Fully agreed, but I need that definition.  I'm not sure exactly how it
should be defined more precisely than it is now.
 
> > Yeah, it it was just a MESSAGE out of the blue, one might argue it's
> > not a communication session.  But, what is it?  The remote side will
> > reply.  If it's part of an ongoing phone call, then it's part of that
> > "communication session".  If it has no relationship with an ongoing
> > phone call, then what is that exchange and do we want a Session-ID
> > applied to it?  For that, I don't care.  Others seem to want it.
> 

I think you know what we should insert... I just feel it. ;-)
 
> >> whole new architectural layer on top of existing sip concepts, made
> >> up of SIP UAs connected in specific ways. (This is exactly what
> >> Hadriel has made a non-goal in STRAW.)
> >

I was only suggesting we've made it this far without a precise definition of
"Session".  So, there is a question of whether there is a new definition
needed.
 
> using sip as a component. We might be better off recognizing this.

Yeah, point taken.
 
Paul