Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 3 Jul 2012 20:59:32 -0400

Laura,

I re-worded what you proposed.  Tell me if this is acceptable:

User Agent A (A) and User Agent B (B) communicate using SIP messaging with a
SIP B2BUA acting as a middlebox. For privacy reasons, the B2BUA changes SIP
headers that reveal information related to the SIP user, device or domain
identity. The service provider uses an external device to monitor and log
all SIP traffic coming from the B2BUA.  In the case of failures reported by
the customer or when security issue arise (e.g. theft of service), the
service provider has to analyze the logs, including its own logs and perhaps
logs provided by the customer, for the past several days or weeks and
correlate those messages which were messages for a single end-to-end SIP
session.

For this scenario, we must consider three particular use cases:

a) The software on A and B can be upgraded by the service provider to
support a single end-to-end Session Identifier.

Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8.

b) Only software on A can be upgraded by the service provider to support the
new identifier.

Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8.

c) Neither the software on A nor B can be upgraded by the service provider
to support the new identifier.

Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8.

Should I remove "eventually REQ1a" and just put "REQ1a"?

Paul

> -----Original Message-----
> From: Laura Liess [mailto:[email-masked]]
> Sent: Wednesday, June 27, 2012 5:19 AM
> To: Paul Jones
> Cc: [email-masked]
> Subject: Text proposal for the "SIP traffic monitoring" use case
> 
> Paul,
> 
> Please find enclosed a text proposal for the use case "SIP traffic
> monitoring":
> 
> 
> SIP traffic monitoring
> 
> UA-A and UA-B communicate using SIP phone calls and SIP messaging with a
> SIP B2BUA acting as a middlebox. The B2BUA changes any SIP header
> revealing information related to the SIP user, device or domain identity.
> The service provider uses an external device to monitor and log “on the
> wire” all SIP traffic passed through the B2BUA.  In case of failures being
> reported by the customers or of security issues (e.g. theft of service),
> the service provider has to analyse the logs for the past days or weeks
> and correlate those messages which where, at some point in time,
> components of a single end-to-end SIP session (e.g., parts of the same
> phone call or transfer of the same message).
> 
> For this scenario, we must consider three particular use cases:
> 
> a)      The UA-A and UA-B software can be upgraded by the service provider
> to support the new identifier. .
>        Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8.
> 
> b)      Only the UA-A software can be upgraded by the service provider to
> support the new identifier, the UA-B software can not.
>        Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7,
> REQ8.
> 
> c)      Neither the UA-A nor the UA-B software can be upgraded by the
> service provider to support the new identifier, the UA-B software can not.
>        Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7,
> REQ8.
> 
> Thanks
> Laura

---

From: Laura Liess <[email-masked]>
Date: Wed, 4 Jul 2012 10:14:37 +0200

Paul,

I am fine with the text. For use case c) please just remove
"(eventually REQ1a)" because REQ 1a is now included into REQ1.

Thank you
Laura

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 4 Jul 2012 20:18:37 -0400

I'm confused.  We did not add anything to REQ1 recently.  REQ1a is an
entirely separate requirement.

You really want to just remove that text from c)?

Paul

> Sent: Wednesday, July 04, 2012 4:15 AM
> To: Paul E. Jones
> Cc: [email-masked]
> Subject: Re: Text proposal for the "SIP traffic monitoring" use case
> 
> Paul,
> 
> I am fine with the text. For use case c) please just remove "(eventually
> REQ1a)" because REQ 1a is now included into REQ1.
> 
> Thank you
> Laura
> 
> > User Agent A (A) and User Agent B (B) communicate using SIP messaging
> > with a SIP B2BUA acting as a middlebox. For privacy reasons, the B2BUA
> > changes SIP headers that reveal information related to the SIP user,
> > device or domain identity. The service provider uses an external
> > device to monitor and log all SIP traffic coming from the B2BUA.  In
> > the case of failures reported by the customer or when security issue
> > arise (e.g. theft of service), the service provider has to analyze the
> > logs, including its own logs and perhaps logs provided by the
> > customer, for the past several days or weeks and correlate those
> > messages which were messages for a single end-to-end SIP session.
> >
> > b) Only software on A can be upgraded by the service provider to
> > support the new identifier.
> >
> > c) Neither the software on A nor B can be upgraded by the service
> > provider to support the new identifier.
> >
> >> UA-A and UA-B communicate using SIP phone calls and SIP messaging
> >> with a SIP B2BUA acting as a middlebox. The B2BUA changes any SIP
> >> header revealing information related to the SIP user, device or domain
> identity.
> >> The service provider uses an external device to monitor and log "on
> >> the wire" all SIP traffic passed through the B2BUA.  In case of
> >> failures being reported by the customers or of security issues (e.g.
> >> theft of service), the service provider has to analyse the logs for
> >> the past days or weeks and correlate those messages which where, at
> >> some point in time, components of a single end-to-end SIP session
> >> (e.g., parts of the same phone call or transfer of the same message).
> >>

---

From: Laura Liess <[email-masked]>
Date: Mon, 9 Jul 2012 15:50:00 +0200

Paul,

Sorry. Somehow I missed your e-mail. I think we have a misunderstanding here.

> entirely separate requirement.
[LL] I thought, based on
http://www.ietf.org/mail-archive/web/insipid/current/msg00166.html,
that  you intend to merge REQ1 and REQ1a into REQ1. Maybe I
misunderstood.
> You really want to just remove that text from c)?
[LL]  No. I don't.
Also in this scenario the service providers monitors and logs all
B2BUA traffic, incomming and outgoing.  There is no log provided by
the customer.

>From my point of view, the text would be :

--------------------------------------------
User Agent A (A) and User Agent B (B) communicate using SIP messaging with a
SIP B2BUA acting as a middlebox which belongs to a SIP service
provider. For privacy reasons, the B2BUA changes the SIP headers that
reveal information related to the SIP users, device or domain
identity. The service provider uses an external device to monitor and log
all SIP traffic coming to and from the B2BUA.  In the case of failures
reported by
the customer or when security issue arise (e.g. theft of service), the
service provider has to analyze the logs from the past several days or weeks and
correlates those messages which were messages for a single end-to-end SIP
session.

a) The UAs  A and B support the end-to-end Session Identifier.

Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8.

b) Only the UA A supports the end-to-end Session Identifier, the UA B does not.

Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8.

c) UA A and UA  B do not support the end-to-end Session Identifier.

Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8.
-----------------

What do you think?

Thank you
Laura

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 10 Jul 2012 00:07:10 -0400

Laura,

> that  you intend to merge REQ1 and REQ1a into REQ1. Maybe I misunderstood.

REQ1a exists because somebody wanted to split define something like REQ1 for
non-dialog exchanges.

What was proposed (by you?) was this:

REQ1a: It must be possible for an administrator or an external device which
monitors the SIP-traffic to use the identifier to identify those dialogs,
transactions and messages which were at some point in time components of a
single end-to-end SIP session (e.g., parts of the same call).

This is not presently in the draft that we just submitted to be a WG
document since I was told to base that document on the -03 draft.  I had
that text in my pending -04 draft, but ... it is still sitting there :-)

> Also in this scenario the service providers monitors and logs all B2BUA
> traffic, incomming and outgoing.  There is no log provided by the
> customer.
> 
> User Agent A (A) and User Agent B (B) communicate using SIP messaging with
> a SIP B2BUA acting as a middlebox which belongs to a SIP service provider.
> For privacy reasons, the B2BUA changes the SIP headers that reveal
> information related to the SIP users, device or domain identity. The
> service provider uses an external device to monitor and log all SIP
> traffic coming to and from the B2BUA.  In the case of failures reported by
> service provider has to analyze the logs from the past several days or
> weeks and correlates those messages which were messages for a single end-
> to-end SIP session.
> 

Sounds OK to me.  I'll put this into me -04 draft and when folks give me the
green light, move it into the WG -01 draft.

Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 10 Jul 2012 14:23:06 +0200

Paul,

> single end-to-end SIP session (e.g., parts of the same call).

[LL] The proposed text of the REQ1a (above) also covers the REQ1 (as
it is in draft-ietf-insipid-session-id-reqts-00). So I think we could
replace the current text of REQ1 by the proposed text of the REQ1a and
then drop REQ1a.

Thanks
Laura

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 10 Jul 2012 22:38:56 -0400

Indeed, you're right.  It does cover both, but folks called for a separate
requirement.

What is the wishes of the WG on this?  Shall I replace REQ1 with the below
text?

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Laura Liess
> Sent: Tuesday, July 10, 2012 8:23 AM
> To: Paul E. Jones
> Cc: [email-masked]
> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use
> case
> 
> Paul,
> 
> >
> > REQ1a: It must be possible for an administrator or an external device
> > which monitors the SIP-traffic to use the identifier to identify those
> > dialogs, transactions and messages which were at some point in time
> call).
> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is
> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace
> the current text of REQ1 by the proposed text of the REQ1a and then drop
> REQ1a.
> 
> Thanks
> Laura
> 
> 
> 
> 
> >
> > document since I was told to base that document on the -03 draft.  I
> > had that text in my pending -04 draft, but ... it is still sitting
> > there :-)
> >
> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service
> provider.
> >> traffic coming to and from the B2BUA.  In the case of failures
> >> reported by the customer or when security issue arise (e.g. theft of
> >> service), the service provider has to analyze the logs from the past
> >> several days or weeks and correlates those messages which were
> >> messages for a single end- to-end SIP session.
> >>
> > Sounds OK to me.  I'll put this into me -04 draft and when folks give
> > me the green light, move it into the WG -01 draft.
> >
> > Paul
> >
> >
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Laura Liess <[email-masked]>
Date: Wed, 11 Jul 2012 09:14:07 +0200

Paul,

After the discussion yesterday in the Webex meeting, it seems to me
that separate requirements for dialogs and transactions are needed.

Thanks
Laura

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 Jul 2012 08:09:40 -0400

What shall be the wording of REQ1a?

Paul

_____________________________________________
From: Laura Liess <[email-masked]>
Sent: Wed Jul 11 03:14:07 EDT 2012
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case

Paul,

Thanks
Laura

>> >>_____________________________________________

>>_____________________________________________

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Jul 2012 15:02:28 +0200

[As individual]

What I took away from the discussion yesterday was:

-                      that REQ 1 represents the session ID requirement for a number of transactions bound up in a dialog, whereas REQ 1A represents the session ID requirement for a transaction not so bound.
-                      For each of these requirements we need to cover the existence over time, and the existence over space.
-                      The existence over space requirement is identical for both, i.e. that UA A, UAB, and all the entities inbetween will be able to see the same session ID, such that some other entity trying to correlate information feeds from these entities will be able to do so.
-                      The existence over time requirement only applies to REQ 1, i.e. that all transactions within the same dialog should share the same session ID. I do not believe there is a requirement for session ID within the transaction, i.e. between request and response - that is dealt with by other mechanisms. We have no requirement for correlation between two transactions that are not within a dialog.

While it would be possible to draft this round the existing requirement split, I suggest maybe we just do the split round the time and space division. So the new revised requirements might look like (in place of the existing).

REQ 1B: It must be possible for the same identifier to appear at all entities participating in a SIP transaction, such that an external device that monitors the SIP traffic can use that identifier to correlate the same transaction at each of those entities.

REQ 1C: It must be possible for the same identifier to appear in all transactions that form part of a SIP dialog, such that the transactions that form part of the dialog can be correlated together. There is no requirement for the identifier to correlate parts of a single transaction (i.e. request and response) as existing SIP mechanisms are assumed to do that. There is no requirement for the identifier to correlate two transactions that do not form part of the same dialog (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a MESSAGE transaction and a subsequent MESSAGE transaction), except as expressed in other requirements.

Note the "except" in REQ 1C above is to allow the transfer requirements in REQ2.

If the new REQ 1B is acceptable, then we should also consider how distinct that is from REQ 4.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: 11 July 2012 13:10
To: Laura Liess
Cc: [email-masked]
Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case

Paul
________________________________

Paul,

Thanks

Laura

>> > This is not presently in t!

 he draft

that we just submitted to be a WG

________________________________

>> >> For privacy reasons, t!

 he B2BUA

changes the SIP headers that reveal

>> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B

>> >> does not.

________________________________

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 10:51:23 -0400

I get Keith's point. But the language isn't working for me.
There are indeed two cases, one related to transactions, and the other 
related to dialogs. But in neither case is it about a single transaction 
or a single dialog, because we have B2BUAs in place.

Rather, in one case we have a set of transactions spliced together by 
B2BUAs. In the other we have a set of dialogs spliced together by 
B2BUAs. Of course a dialog is itself a set of related transactions. But 
the grouping is different.

A transaction is always between two neighboring nodes. When you insert 
proxies in the path there is a separate transaction on each side of the 
proxy, and they are correlated by dialog id. When we introduce a B2BUA 
the situation isn't much different, except that the dialog id isn't 
preserved. So in this case we want the session id to provide the 
correlation that the dialog id doesn't.

> REQ 1B: It must be possible for the same identifier to appear at all
> entities participating in a SIP transaction, such that an external
> device that monitors the SIP traffic can use that identifier to
> correlate the same transaction at each of those entities.

So, "SIP transaction" above is wrong.

> REQ 1C: It must be possible for the same identifier to appear in all
> transactions that form part of a SIP dialog, such that the transactions
> that form part of the dialog can be correlated together. There is no
> requirement for the identifier to correlate parts of a single
> transaction (i.e. request and response) as existing SIP mechanisms are
> assumed to do that. There is no requirement for the identifier to
> correlate two transactions that do not form part of the same dialog
> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a
> MESSAGE transaction and a subsequent MESSAGE transaction), except as
> expressed in other requirements.

and "SIP dialog" is wrong above.

We have coined the term "session" (as overloaded as it is) for the set 
of dialogs connected by B2BUAs. So maybe it could be used above.

But we have no term proposed for the transactions connected by B2BUAs, 
so its really hard to write 1B. If we want to cover this case then we 
need terminology to describe it.

	Thanks,
	Paul

On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote:
> -that REQ 1 represents the session ID requirement for a number of
> transactions bound up in a dialog, whereas REQ 1A represents the session
> ID requirement for a transaction not so bound.
>
> -For each of these requirements we need to cover the existence over
> time, and the existence over space.
>
> -The existence over space requirement is identical for both, i.e. that
> UA A, UAB, and all the entities inbetween will be able to see the same
> session ID, such that some other entity trying to correlate information
> feeds from these entities will be able to do so.
>
> -The existence over time requirement only applies to REQ 1, i.e. that
> all transactions within the same dialog should share the same session
> ID. I do not believe there is a requirement for session ID within the
> transaction, i.e. between request and response – that is dealt with by
> other mechanisms. We have no requirement for correlation between two
> transactions that are not within a dialog.
>
> While it would be possible to draft this round the existing requirement
> split, I suggest maybe we just do the split round the time and space
> division. So the new revised requirements might look like (in place of
> the existing).
>
> REQ 1B: It must be possible for the same identifier to appear at all
> entities participating in a SIP transaction, such that an external
> device that monitors the SIP traffic can use that identifier to
> correlate the same transaction at each of those entities.
>
> REQ 1C: It must be possible for the same identifier to appear in all
> transactions that form part of a SIP dialog, such that the transactions
> that form part of the dialog can be correlated together. There is no
> requirement for the identifier to correlate parts of a single
> transaction (i.e. request and response) as existing SIP mechanisms are
> assumed to do that. There is no requirement for the identifier to
> correlate two transactions that do not form part of the same dialog
> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a
> MESSAGE transaction and a subsequent MESSAGE transaction), except as
> expressed in other requirements.
>
> Note the “except” in REQ 1C above is to allow the transfer requirements
> in REQ2.
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Paul E. Jones
> *Sent:* 11 July 2012 13:10
> *To:* Laura Liess
> *Cc:* [email-masked]
> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring"
> use case
>
> ------------------------------------------------------------------------
>
> *From:*Laura Liess <[email-masked]>
> *Sent:* Wed Jul 11 03:14:07 EDT 2012
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring"
> use case
>
>
>
> Paul,
>
>
>
> 2012/7/11 Paul E. Jones<[email-masked]>:
>
>>>  Sent: Tuesday,July 10, 2012  8:23 AM
>
>>>  To: Paul E. Jones
>
>>>  Cc: [email-masked]
>
>>>  Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring"  use
>
>>>  case
>
>>>
>
>>>  Paul,
>
>>>
>
>>>  >
>
> ------------------------------------------------------------------------
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
>>>  insipid mailing list
>
>>>  [email-masked]
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Jul 2012 16:55:22 +0200

11 jul 2012 kl. 16:51 skrev Paul Kyzivat:

> There are indeed two cases, one related to transactions, and the other related to dialogs. But in neither case is it about a single transaction or a single dialog, because we have B2BUAs in place.
> 
> Rather, in one case we have a set of transactions spliced together by B2BUAs. In the other we have a set of dialogs spliced together by B2BUAs. Of course a dialog is itself a set of related transactions. But the grouping is different.
> 
> A transaction is always between two neighboring nodes. When you insert proxies in the path there is a separate transaction on each side of the proxy, and they are correlated by dialog id. When we introduce a B2BUA the situation isn't much different, except that the dialog id isn't preserved. So in this case we want the session id to provide the correlation that the dialog id doesn't.
> 
> We have coined the term "session" (as overloaded as it is) for the set of dialogs connected by B2BUAs. So maybe it could be used above.
Oh. Sorry for arriving late to the discussion table, but isn't session already taken by RTP? 
> 
> But we have no term proposed for the transactions connected by B2BUAs, so its really hard to write 1B. If we want to cover this case then we need terminology to describe it.
> 
Maybe "dialog-groups" and "transaction-groups" as defined by the group-id - t-group-id and d-group-id?

Just brainstorming ;-)

/O

>>>> >  me the green light, move it into the WG -01 draft.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 11:10:38 -0400

> Maybe "dialog-groups" and "transaction-groups" as defined by the group-id - t-group-id and d-group-id?

"session" is taken by lots of things. It is overloaded to the point of 
meaninglessness. My usual resolution to such things is to affix a 
modifier, such as foo-session. But frankly nothing better than foo comes 
to mind right now, and I don't think I can live with foo.

The alternative is to come up with something that doesn't involve 
session. But I'm finding "group" even less helpful than "session".

Another rule of thumb I use is that if you can't come up with a good 
term for a concept you are trying to define, then you probably haven't 
chosen the right concept.

How about "macro-dialog" and "macro-transaction"? I'm not loving them, 
but they start to bring in relevant concepts.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Jul 2012 18:01:57 +0200

I am not tied to the words, they were to get the idea across.

For my proposed 1B, I take the point that "transaction" is wrong. Maybe adding the words "(or set of concatenated transactions)" will solve that.

For my proposal 1C, I would argue that "dialog" is absolutely correct here. For 1C I am looking at a single point in space (one entity) and saying all the transactions I see in that dialog have the same identifier.

It is the combination of 1B (all the points that see the transaction) and 1C (all the transactions at this entity that form the dialog) that give me the same identifier for all transactions in a dialog, concatenated across the complete path.

Keith

> Of Paul Kyzivat
> Sent: 11 July 2012 15:51
> To: [email-masked]
> Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP
> traffic monitoring" use case
> 
> > transaction, i.e. between request and response - that is dealt with by
> it is

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 14:26:01 -0400

> For my proposed 1B, I take the point that "transaction" is wrong. Maybe adding the words "(or set of concatenated transactions)" will solve that.

Maybe, if "set of concatenated transactions" is explained somewhere.

> For my proposal 1C, I would argue that "dialog" is absolutely correct here. For 1C I am looking at a single point in space (one entity) and saying all the transactions I see in that dialog have the…

Its true that one goal is that all the transactions in the dialog get 
the same ID. But its also true that all the dialogs in the same session, 
or "set of concatenated dialogs" get the same ID.

> It is the combination of 1B (all the points that see the transaction) and 1C (all the transactions at this entity that form the dialog) that give me the same identifier for all transactions in a di…

We have something like:

        B2Bx    B2By
    did1 |  did2 |  did3
   ______|_______|______
   A-B-C | D-E-F | G-H-I
   J-K-L | M-N-O | P-Q-R

In the above, A,B,...,R are transactions.
Each row is a "set of concatenated transactions".
"A-B-C" represents related transactions as a request moves from the UAC 
through proxies, ending at B2Bx. Then more transactions, B2By, etc.
The columns did1, did2, did3 are dialogs with their dialog ids.

The two rows represent two requests in the same set of related dialogs.
So ABC,JKL all carry dialog id did1, etc.

So the *desire* is that A...R all get the same session id.

The distinction between the transaction case and the dialog case is 
really very small. Its just the degenerate case of the above where there 
is only one row.

I think what we're trying to say, more or less, is:
- all transactions with the same dialog id get the same session id
- whenever a b2bua correlates a transaction on one side with a
   transaction on the other side then both get the same session id.

Of course a transaction usually has more than one message - at least a 
request and a response. Ideally every *message* in every transaction 
would have the full session id. But that won't be met. The requests in 
the first message of each dialog will at best get half of the id. The 
responses will get the full id, except that any to the right of the last 
one supporting this mechanism won't get the 2nd half.

Its actually hard to word the requirements so that they won't be 
violated for some nodes in some common cases. We'll have to decide 
whether to leave such requirements and be satisfied with a mechanism 
that doesn't meet them fully, or find a way to relax the requirements so 
that we can find a mechanism that fully meets them.

	Thanks,
	Paul

>>> *From:*Laura Liess<[email-masked]>
>>> *To:* "Paul E. Jones"<[email-masked]>
>>> *Cc:* [email-masked]

---

From: James Polk <[email-masked]>
Date: Wed, 11 Jul 2012 15:14:44 -0500

I was there during the discussions, so I know what Keith is after, 
therefore I understand the meaning of what he's saying (i.e., I can 
read between the text he wrote to determine he's after what was 
agreed to yesterday). At the same time, Paul is right, that the words 
don't yet match what we need.

Paul K. - where this is coming from, is we realized when discussing 
REQ#1 and (the lack of text for) 1A that we hadn't covered 
transactions that create dialogs (the original intent for REQ#1) and 
what was suggested as missing during Interim#1 for non-dialog 
creating transactions. There was no requirement covering the latter.

 From that, I like your "set of concatenated transactions" 
modification to Keith's 1B, but like "set of concatenated non-dialog 
generating transactions" better, because that's what we're talking 
about (covering the MESSAGE, OPTIONS, REGISTER, & PUBLISH Methods). 
Each of these 4 methods are individual and complete transactions that 
don't carry state between transactions, so the Session-ID must be the 
same across however many B2BUAs that concatenated series of 
transactions only until a final response is delivered

 From that, why don't we go after "set of concatenated dialog 
generating transactions" for Keith's 1C covering INVITE, ACK, BYE, 
UPDATE, REFER, SUBSCRIBE, NOTIFY, PRACK, CANCEL, & INFO Methods). 
When an INVITE, REFER or SUBSCRIBE creates a dialog, regardless of 
how many B2BUAs that transaction crosses, we want all related 
concatenated series of transactions to have the same Session-ID, right?

isn't SIP complicated?

;-)

James

At 01:26 PM 7/11/2012, Paul Kyzivat wrote:
>>For my proposed 1B, I take the point that "transaction" is wrong. 
>>Maybe adding the words "(or set of concatenated transactions)" will solve that.
>
>>For my proposal 1C, I would argue that "dialog" is absolutely 
>>correct here. For 1C I am looking at a single point in space (one 
>>entity) and saying all the transactions I see in that dialog have 
>>the same identifier.
>
>Its true that one goal is that all the transactions in the dialog 
>get the same ID. But its also true that all the dialogs in the same 
>session, or "set of concatenated dialogs" get the same ID.
>
>>It is the combination of 1B (all the points that see the 
>>transaction) and 1C (all the transactions at this entity that form 
>>the dialog) that give me the same identifier for all transactions 
>>in a dialog, concatenated across the complete path.
>
>We have something like:
>
>        B2Bx    B2By
>    did1 |  did2 |  did3
>   ______|_______|______
>   A-B-C | D-E-F | G-H-I
>   J-K-L | M-N-O | P-Q-R
>
>"A-B-C" represents related transactions as a request moves from the 
>UAC through proxies, ending at B2Bx. Then more transactions, B2By, etc.
>really very small. Its just the degenerate case of the above where 
>there is only one row.
>
>Of course a transaction usually has more than one message - at least 
>a request and a response. Ideally every *message* in every 
>transaction would have the full session id. But that won't be met. 
>The requests in the first message of each dialog will at best get 
>half of the id. The responses will get the full id, except that any 
>to the right of the last one supporting this mechanism won't get the 2nd half.
>
>that doesn't meet them fully, or find a way to relax the 
>requirements so that we can find a mechanism that fully meets them.
>
>         Thanks,
>         Paul
>
>>Keith
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 16:43:19 -0400

What I realized while writing the last message (and tried to convey, 
perhaps unsuccessfully) is that I don't think there is any need to 
distinguish between dialog establishing, non-dialog establishing, and 
in-dialog transactions.

A even non-dialog-forming transactions have callids and dialog ids. Its 
just that the non-dialog-forming ones are only used once, while the 
dialog forming ones are used for the duration of the dialog. So a 
non-dialog transaction is just like a dialog with just one transaction. 
(E.g. an OPTIONS and an INVITE that gets an immediate 4xx are treated 
the same with regard to dialog id and session id.)

So, we don't need to treat them separately. So I was suggesting what 
seemed like a simpler way to look at it.

	Thanks,
	Paul

On 7/11/12 4:14 PM, James Polk wrote:
> therefore I understand the meaning of what he's saying (i.e., I can read
> between the text he wrote to determine he's after what was agreed to
> yesterday). At the same time, Paul is right, that the words don't yet
> match what we need.
>
> REQ#1 and (the lack of text for) 1A that we hadn't covered transactions
> that create dialogs (the original intent for REQ#1) and what was
> suggested as missing during Interim#1 for non-dialog creating
> transactions. There was no requirement covering the latter.
>
>  From that, I like your "set of concatenated transactions" modification
> to Keith's 1B, but like "set of concatenated non-dialog generating
> transactions" better, because that's what we're talking about (covering
> the MESSAGE, OPTIONS, REGISTER, & PUBLISH Methods). Each of these 4
> methods are individual and complete transactions that don't carry state
> between transactions, so the Session-ID must be the same across however
> many B2BUAs that concatenated series of transactions only until a final
> response is delivered
>
>  From that, why don't we go after "set of concatenated dialog generating
> transactions" for Keith's 1C covering INVITE, ACK, BYE, UPDATE, REFER,
> SUBSCRIBE, NOTIFY, PRACK, CANCEL, & INFO Methods). When an INVITE, REFER
> or SUBSCRIBE creates a dialog, regardless of how many B2BUAs that
> transaction crosses, we want all related concatenated series of
> transactions to have the same Session-ID, right?
>
> isn't SIP complicated?
>
> ;-)
>
> James
>
>>> For my proposal 1C, I would argue that "dialog" is absolutely correct
>>> here. For 1C I am looking at a single point in space (one entity) and
>>> saying all the transactions I see in that dialog have the same
>>> identifier.
>>
>> the same ID. But its also true that all the dialogs in the same
>>> It is the combination of 1B (all the points that see the transaction)
>>> and 1C (all the transactions at this entity that form the dialog)
>>> that give me the same identifier for all transactions in a dialog,
>>> concatenated across the complete path.
>>
>> We have something like:
>>
>> B2Bx B2By
>> did1 | did2 | did3
>> ______|_______|______
>> A-B-C | D-E-F | G-H-I
>> J-K-L | M-N-O | P-Q-R
>>
>> responses will get the full id, except that any to the right of the
>> last one supporting this mechanism won't get the 2nd half.
>>
>> that doesn't meet them fully, or find a way to relax the requirements
>> so that we can find a mechanism that fully meets them.
>>
>> Thanks,
>> Paul
>>
>>> Keith
>>>
>>>>> Note the "except" in REQ 1C above is to allow the transfer
>>>>> requirements
>>>>> in REQ2.
>>>>>

---

From: James Polk <[email-masked]>
Date: Wed, 11 Jul 2012 15:49:24 -0500

Not having to parse out the differences between dialog establishing, 
non-dialog establishing, and in-dialog transactions would be far 
easier to write.

I guess what I'm proposing is to have a single requirement cover all 
types of transactions (or just SIP messages) equally - i.e., they all 
have a Session-ID, with the in-dialog transactions using the same 
Session-ID as the dialog establishing message(s).

Do others agree?

James

At 03:43 PM 7/11/2012, Paul Kyzivat wrote:
>distinguish between dialog establishing, non-dialog establishing, 
>and in-dialog transactions.
>
>A even non-dialog-forming transactions have callids and dialog ids. 
>Its just that the non-dialog-forming ones are only used once, while 
>the dialog forming ones are used for the duration of the dialog. So 
>a non-dialog transaction is just like a dialog with just one 
>transaction. (E.g. an OPTIONS and an INVITE that gets an immediate 
>4xx are treated the same with regard to dialog id and session id.)
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 24 Jul 2012 22:53:14 -0400

Keith,

Was there any consensus on modifications to REQ1 or REQ1a?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Wednesday, July 11, 2012 9:02 AM
To: [email-masked]
Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP
traffic monitoring" use case

[As individual]

-             that REQ 1 represents the session ID requirement for a number
of transactions bound up in a dialog, whereas REQ 1A represents the session
ID requirement for a transaction not so bound.

-             For each of these requirements we need to cover the existence
over time, and the existence over space.

-             The existence over space requirement is identical for both,
i.e. that UA A, UAB, and all the entities inbetween will be able to see the
same session ID, such that some other entity trying to correlate information
feeds from these entities will be able to do so.

-             The existence over time requirement only applies to REQ 1,
i.e. that all transactions within the same dialog should share the same
session ID. I do not believe there is a requirement for session ID within
the transaction, i.e. between request and response - that is dealt with by
other mechanisms. We have no requirement for correlation between two
transactions that are not within a dialog.

While it would be possible to draft this round the existing requirement
split, I suggest maybe we just do the split round the time and space
division. So the new revised requirements might look like (in place of the
existing).

REQ 1B: It must be possible for the same identifier to appear at all
entities participating in a SIP transaction, such that an external device
that monitors the SIP traffic can use that identifier to correlate the same
transaction at each of those entities.

REQ 1C: It must be possible for the same identifier to appear in all
transactions that form part of a SIP dialog, such that the transactions that
form part of the dialog can be correlated together. There is no requirement
for the identifier to correlate parts of a single transaction (i.e. request
and response) as existing SIP mechanisms are assumed to do that. There is no
requirement for the identifier to correlate two transactions that do not
form part of the same dialog (e.g. an OPTIONS transaction and a subsequent
INVITE transaction, or a MESSAGE transaction and a subsequent MESSAGE
transaction), except as expressed in other requirements.

Note the "except" in REQ 1C above is to allow the transfer requirements in
REQ2. 

If the new REQ 1B is acceptable, then we should also consider how distinct
that is from REQ 4.

Keith

  _____  

Of Paul E. Jones

Paul

  _____  

Paul,

Thanks

Laura

 he draft

  _____  

 he B2BUA

  _____

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 25 Jul 2012 10:59:05 +0200

Not that I saw yet - you may want to summarise where it got to and see if that produces more input.

Keith

________________________________
From: Paul E. Jones [mailto:[email-masked]]
Sent: 25 July 2012 03:53
To: DRAGE, Keith (Keith); [email-masked]
Subject: RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case

Keith,

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Wednesday, July 11, 2012 9:02 AM
To: [email-masked]
Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case

[As individual]

Keith

Paul

Paul,

Thanks

Laura

 he draft

 he B2BUA

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Jul 2012 10:48:07 -0400

I don't think I can summarize it.  I looked over the thread, but I didn't
see convergence.  I didn't see divergence, either.

I think James said he knows what you're after.  There was discussion on the
definition of "session".  I didn't see anything resembling a conclusion.

Do we want to form REQ1a,b,c?  There was a call to merge REQ1 and REQ1a
together.  So, what I have as the current proposal is a single REQ1:

"It must be possible for an administrator or an external device which
monitors the SIP-traffic to use the identifier to identify those dialogs,
transactions and messages which were at some point in time components of a
single end-to-end SIP session (e.g., parts of the same call)."

Paul

From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 4:59 AM
To: Paul E. Jones; [email-masked]
Subject: RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP
traffic monitoring" use case

Not that I saw yet - you may want to summarise where it got to and see if
that produces more input.

Keith

  _____  

From: Paul E. Jones [mailto:[email-masked]] 
Sent: 25 July 2012 03:53
To: DRAGE, Keith (Keith); [email-masked]
Subject: RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP
traffic monitoring" use case

Keith,

Paul

[As individual]

-        that REQ 1 represents the session ID requirement for a number of
transactions bound up in a dialog, whereas REQ 1A represents the session ID
requirement for a transaction not so bound.

-        For each of these requirements we need to cover the existence over
time, and the existence over space.

-        The existence over space requirement is identical for both, i.e.
that UA A, UAB, and all the entities inbetween will be able to see the same
session ID, such that some other entity trying to correlate information
feeds from these entities will be able to do so.

-        The existence over time requirement only applies to REQ 1, i.e.
that all transactions within the same dialog should share the same session
ID. I do not believe there is a requirement for session ID within the
transaction, i.e. between request and response - that is dealt with by other
mechanisms. We have no requirement for correlation between two transactions
that are not within a dialog.

Keith

  _____  

Paul

  _____  

Paul,

Thanks
Laura

 he draft

  _____  

 
 he B2BUA

  _____