Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Jan 2010 12:39:56 -0500

My experience is they also try to reduce opex and decrease service issues, and do spend big bucks on monitoring equipment and such in order to troubleshoot issues more easily and with fewer human employees.  The point of session-id is to help them with that, so I think it has a good chance of being used.  Or at least several carriers have asked me for it.  Whether it will really succeed or not we can't know a priori, until there's a spec which defines it.

-hadriel

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, December 29, 2009 2:16 AM
> To: [email-masked]
> 
> [email-masked] wrote:
> 
>  > Dean Said:
> > 	> Although I expect that somebody's SBC will remove it just for
> > fun...
> > I don't think so. People, also incumbent carriers, learn from
> > implementation experience, and they are the main customers for SBCs.
> 
> My experience with incumbent carriers is much less hopeful. As far as I
> can tell, they only learn from new legislation or regulation, and then
> ony when fined large amounts for ignoring the rules.
> 
> Are we aware of any regulators willing to issue large fines for removing
>   the proposed session-OD?
> 
> --
> Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jan 2010 17:08:03 +0200

Hi,

the requirement for session correlation has appeared a number of times:

1) We have Hadriel's draft.

2) We also have the following draft, which eventually led to the 
disaggregated media work:

http://www.watersprings.org/pub/id/draft-loreto-sipping-dialog-correlation-01.txt

3) We also have the SIP-XMPP work, which may also need to correlate 
sessions somehow.

What we need to understand is whether or not the requirements for these 
different use cases are similar enough so that a single correlation 
mechanism is enough to meet all of them. If we can kill two birds (in 
this case more than two) with one stone, it would be a good thing. On 
the other hand, if the requirements are sufficiently different to be met 
by a single mechanism, then we would need more than one solution.

I know there have been informal conversations about this among the 
proponents of these three topics. Let's try and conclude those 
discussions on the list so that we can make a decision on how to proceed 
with this.

Cheers,

Gonzalo

Spencer Dawkins wrote:
> Speaking as sipclf co-chair, I've been assured by my AD that session ID is 
> not part of what sipclf is currently chartered to do.
> 
> I believe the "dispatching" part is for DISPATCH to say (1) this work 
> matters, and (2) the right way to proceed is $PLAN... where $PLAN could be 
> sending it to sipclf and adding it to the sipclf charter, but there can also 
> be other $PLANs.
> 
> I'm not clear what the boundaries of what needs to be dispatched are - but 
> session ID isn't close to those boundaries!
> 
> Spencer
> 
>>> I'd like to have this dispatched to the appropriate WG, preferably the 
>>> SIP-CLF WG (since they're a prime customer of it).
>> Process question: If we think it is roughly in-scope for the CLF working 
>> group, do we need to "dispatch" it? Or just ask on their list and let them 
>> decide on whether to get the AD to add it to their charter?
>>
>> And for what it is worth, I think we do need a session-correlator. 
>> Although I expect that somebody's SBC will remove it just for fun...
>>
>> --
>> Dean
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 14 Jan 2010 09:47:16 -0600

Gonzalo was replying to my e-mail, listed three additional possible 
applications of session ID, and then referred to "these three topics" later 
in his e-mail. So, just to make sure the fourth of these three topics also 
stays on the radar :D

Again, speaking as SIPCLF co-chair... the following comments were extracted 
from the minutes from our Hiroshima meeting (available at 
http://www.ietf.org/proceedings/76/minutes/sipclf.htm).

I note that Adam proposed capturing before-and-after IDs if we DON'T have a 
session ID, but (speaking as an individual) that sounds like a good plan B - 
where session ID could be plan A.

Thanks,

Spencer

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

Laura Liess: Deutche Telecom: People use Wireshark for tracing and
analysis, troubleshooting. They need end-to-end session id. CLF is useless
without session-ID.

Daryl: Goal is a common format that can correlate, so there has to be some
identifier. Session ID is a dependency if this stuff is going to be real -
not going to be able to tell another carrier "show me your logs", but need
to troubleshoot end-to-end.

Vijay: Important to look at message as it crosses mesh, and have some sort
of global string that identifies messages.

Spencer (channeling Robert): Session ID may be important for us, but not in
scope now. We can talk about it if we find that helpful, but we can't put it
in a document _yet_.

Eric: What exists today often works for that product, but not across
multiple products, or products without CDR. There's a bunch of almost
compatible stuff that exists that may be useful (example Apache CLF).

Eric, restating for minutes: We need language on how log data is captured by
existing products in almost compatible ways. Our experience with Apache CLF
shows value in being able to correlate records across various pieces of
network equipment. Lots of open source tools have sprung up around Apache
CLF.

Daryl: For this to be useful, we need session ID. Most of these devices are
B2BUAs. Without a session ID you can only look at one system at a time. What
value is that over proprietary formats? Is this defining just CLF, or a
correlation methodology?

Vijay: Just the format.

Adam: Lots of SBCs out there, ability to correlate is absolutely necessary.
More than one way to skin the cat. One is an identifier, another is to
define the format to show before and after IDs. This is not intractable and
should not block starting the work.

Spencer: Chartering discussion allowed for inserting a session id later,
just not in scope for our work today. My previous gig was correlating SIP
calls monitored at multiple points as they moved through a network--it's a
hard problem and the heuristics sometime fail. Wants to make this a simple
problem.

Daryl: Problem does span beyond SBCs. Now more application servers are
b2buas that break signaling info.

Adam: Mean b2buas in general, not just SBCs.

> mechanism is enough to meet all of them. If we can kill two birds (in this
> case more than two) with one stone, it would be a good thing. On the other
> hand, if the requirements are sufficiently different to be met by a single
> mechanism, then we would need more than one solution.
>
> proponents of these three topics. Let's try and conclude those discussions
> on the list so that we can make a decision on how to proceed with this.
>
> Cheers,
>
> Gonzalo
>
>
> Spencer Dawkins wrote:
>> Speaking as sipclf co-chair, I've been assured by my AD that session ID
>> is not part of what sipclf is currently chartered to do.
>>
>> matters, and (2) the right way to proceed is $PLAN... where $PLAN could
>> be sending it to sipclf and adding it to the sipclf charter, but there
>> can also be other $PLANs.
>>
>> I'm not clear what the boundaries of what needs to be dispatched are -
>> but session ID isn't close to those boundaries!
>>
>> Spencer
>>
>>> group, do we need to "dispatch" it? Or just ask on their list and let
>>> them decide on whether to get the AD to add it to their charter?
>>>

---

From: <[email-masked]>
Date: Thu, 14 Jan 2010 17:28:00 +0100

Gonzalo,

My personal opinion is, that the Session-ID draft and the dialog-correlation draft cover quite different use cases. Session-ID is used for traffic monitoring and is needed to correlate the legs of the same e2e session across B2BUAs. The dialog-correlation is used to logically correlate two e2e sessions. I think we should not mix them and use different identifiers. 

One comment on the dialog-correlation draft: 
If I understood the draft corectly, the "Same-Session"-Header contains the Call-ID and implicitly the ED IP-address. In most cases, SBCs drop or change anything which contains the ED IP-address. Session-ID uses the hashed Call-ID to be able to cross SBCs.   

Kind regards
Laura

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Thursday, January 14, 2010 4:08 PM
> To: Spencer Dawkins
> Cc: [email-masked]; Hadriel Kaplan
> Subject: Re: [dispatch] FW: 
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> 
> Hi,
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 14 Jan 2010 11:55:19 -0500

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, January 14, 2010 10:08 AM
> To: Spencer Dawkins
> Cc: Dean Willis; Hadriel Kaplan; [email-masked]
> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-
> 00.txt
> 
> Hi,
> 

I think those two are very different, with different requirements.
The session-id concept is to provide an identifier which stays untouched/unmodified through any number of b2bua's, 3pcc controllers, whatever.  In other words both the UAC and UAS side of a b2bua need to use the same session-id value.  And it needs to do it in the initial messages of the initial dialog, not some later INVITE.  

The same can't be said of a same-session header value - it identifies a specific "side" of the b2bua, by identifying the specific callid+tags.  

I guess one question is if same-session could use a session-id kind of value instead of callid+tags.  For example, does it *need* to identify a specific side of a b2bua - if it goes to a b2bua which handled the initial dialog this same-session is referring to, how does the b2bua know which dialog "half" of its b2bua function the same-session is referring to?  Does it matter?

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Jan 2010 10:21:45 +0200

Hi,

thanks Spencer for pointing to yet another use cases where something 
like this is needed.

Answering to Hadriel and Laura, I know the approaches the drafts take to 
meet their particular requirements are different. What I am asking 
people is to step back and think whether or not the requirements are 
similar.

In all the use cases we have so far we need to correlate several 
sessions that terminate/originate in an entity. The differences are that 
in some use cases we are dealing with two sessions while in others we 
may have more than two. In some use cases all sessions are SIP while in 
others other protocols may be used (e.g., XMPP). In some use cases the 
correlation information tells the entity how the correlation needs to be 
performed. In others, the entity performs the session correlation and 
provides this information to other parties... etc.

This is the type of analysis I would like folks to think about. Let's 
focus on requirements instead of technical solutions at this point. If 
after such an analysis the WG decides that the requirements are 
sufficiently different, we can develop several mechanisms. If the 
requirements are sufficiently similar, we may be able to cover several 
use cases with a single mechanism.

Cheers,

Gonzalo

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 11:19:27 +0100

Hi, 

I think if we can show that having the same identifier for both use
cases has unacceptable consequences we can say that we need two diferent
identifiers.
If I understood the draft-loreto-sipping-dialog-correlation-01
correctly, my feeling is that we get a lot of problems if we try to use
the same identifier for both Session-ID and Dialog-correlation
(Same-Session).   

Let's assume we have a same identifier, called Correlation-ID , which
plays both roles, Session-ID and Same-Session.  

Consequence nr. 1) 
Significant performance reduction in UAS. 

When Correlation-ID in it's Session-ID role becomes implemented, every
INVITE received by every UAS will contain a Correlation-ID. The UAS will
have to  search for existing dialogs related to the received
Correlation-ID. For Gateways or Application Servers, this can be very
CPU consuming. They must search for related dialogs for every received
INVITE. If we have two identifiers are different, in most cases the UAS
receives only the Session-ID which it just copies into the Respose. The
search is done only for the use cases described in the dialog-corelation
draft.  

So I would propose following additional requirenment for the Session-ID
Header: 
"The mechanism should not lead to unnecessary performance reduction at
the UAS."
This requirement is not fulfilled if we have the same identifier. 

Consequence nr. 2)

Imprecise monitoring results

Consider the scenario in chapter 4
draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
B2BUA between Alice and Bob and the service provider monitors the trafic
E2E.  The trubleshooting people will want to distinguish which messages
belong to the phone call and which messages belong to  the video call.  

Alice
Bob

UA_A
-----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>UA_B
 
Correlation-ID_a
                                                          (based on
call-ID_a)     

UA_C
-----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>UA_B
          Correlation-ID_a
Correlation-ID_a
         (based on call-ID_a)                         (based on
call-ID_a)

Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
B2BUA constructs the Correlation-ID_a based on the Call-ID_a. 
Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
correlated to the existing phone call and the UA_B constructs the
Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
Correlation-ID_a to the UA_B transparently. Because both messages
between the B2BUA and UA_B have the same Correlation-ID, the monitoring
equipment will not be able to distinguish which message belongs to which
call.       

So I would propose following additional requirenment for the Session-ID
Header: 

"Different E2E SIP sessions must have different identifiers." 

I also would add following Requirement to Session-ID: 

"It must be possible to use the identifier without upgrading the end
devices software." 
This requirement is met by the Session-ID proposal but it is not
explicitely stated in the draft. 

Additional personal opinions on the correlation-draft:
- I think the Same-Session will is usefull for troubleshooting and
should be standardized. 

- The Same-Session header should use the Session-ID instead of the
call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
change it. (I hope there are no conflicts here with the tags.)  

Thanks  a lot
Laura

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Jan 2010 07:46:39 -0600

Hi, Laura,

Just to make sure I understand - are you saying something like "The 
mechanism should not lead to performance reduction at the UAS for dialogs 
that are not correlated with other dialogs."?

(I'm just trying to be more precise about "unnecessary performance 
reduction")

If so, that makes sense to me.

Thanks,

Spencer

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, January 19, 2010 4:19 AM
Subject: RE: [dispatch] FW: 
I-DAction:draft-kaplan-dispatch-session-id-00.txt

Hi,

Consequence nr. 1)

Consequence nr. 2)

Alice
Bob

UA_A

Correlation-ID_a
                                                          (based on
call-ID_a)

UA_C
          Correlation-ID_a
Correlation-ID_a

Thanks  a lot
Laura

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 19 Jan 2010 21:45:44 +0200

Hi there,

I have been thinking for a while on this three/four issues

So let me start with the Hadriel question: "same-session could use a 
session-id kind of value instead of callid+tags
the same-session-id is a quite an old draft"?
I do think it should use a session-id kind of value! (the mechanism 
proposed in same-session draft if stale, as it is the
all draft, so it is a waste of time talk about it. Lets instead talk of 
and compare with the disaggregate media one:
http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt )

In my opinion the scenario to correlate an original call with a new 
create by a B2BUA is quite
similar to the one where the calls that are going to be correlate are 
generate by the same UA.
That is even more true if the correlation identifier is generated by the 
UA and not by the B2BUA or any other server
within the network.
So the Hadriel's draft could be a good starting point to draft solution 
for disaggregated media, of course it we get
rid of the limitation for debug purpose.
I wouldn't be worried about about the performance issue raised by Laura, 
at the end it would be enough insert
a tag into the Session-ID header to discriminate the scenario when it is 
used for debugging and when for disaggregated purpose.
Moreover at the end both the disaggregated and especially the debug (I 
hope) will be used rarely.

Coming to the SIP-XMPP scenario: here I don't have a strong idea, but I 
guess that an identifier a la session-id
could work also in this scenario.

of course I may be wrong

cheers
Sal

---

From: Ian Elz <[email-masked]>
Date: Wed, 20 Jan 2010 12:52:25 +0100

Sal,

>From your quote: ' "same-session could use a session-id kind of value instead of callid+tags..." '

As was commented during the initial discussions on Hadriel's first draft the session-id as proposed will not replace call-id+tags. This occurs as forking will result in multiple dialogs containing the same session-id. This only really presents an issue during the early-dialog phase as only one early-dialog will result in an established session.

If you need session-id to be able to match early dialogs then you need session-id to have a different form.

E.g. Session-id: UAC-part;UAS-parameter

In this scenario for session tracking or established session identification only the UAC-part is required but for identification of an individual early dialog both parts would be required.

Ian

-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: 19 January 2010 19:46
To: [email-masked]
Cc: [email-masked]; Gonzalo Camarillo; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt

Hi there,

So let me start with the Hadriel question: "same-session could use a session-id kind of value instead of callid+tags the same-session-id is a quite an old draft"?
I do think it should use a session-id kind of value! (the mechanism proposed in same-session draft if stale, as it is the all draft, so it is a waste of time talk about it. Lets instead talk of and compare with the disaggregate media one:
http://tools.ietf.org/id/draft-loreto-dispatch-disaggregated-media-00.txt )

In my opinion the scenario to correlate an original call with a new create by a B2BUA is quite similar to the one where the calls that are going to be correlate are generate by the same UA.
That is even more true if the correlation identifier is generated by the UA and not by the B2BUA or any other server within the network.
So the Hadriel's draft could be a good starting point to draft solution for disaggregated media, of course it we get rid of the limitation for debug purpose.
I wouldn't be worried about about the performance issue raised by Laura, at the end it would be enough insert a tag into the Session-ID header to discriminate the scenario when it is used for debugging and when for disaggregated purpose.
Moreover at the end both the disaggregated and especially the debug (I
hope) will be used rarely.

Coming to the SIP-XMPP scenario: here I don't have a strong idea, but I guess that an identifier a la session-id could work also in this scenario.

of course I may be wrong

cheers
Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2010 09:00:45 -0500

> As was commented during the initial discussions on Hadriel's first draft the session-id as proposed will not replace call-id+tags. This occurs as forking will result in multiple dialogs containing…

While its "normal" that only one final dialog results from an INVITE, it 
is certainly possible to end up with more than one. While in that case 
its common to kill all but one, that isn't necessarily the case either.
(E.g. a conference server that is calling out to a potential participant 
may find that its INVITE is forked, and may well keep all resulting 
dialogs.)

So lets not design anything that depends on their being only one.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 16:47:58 +0100

Sal,

> similar to the one where the calls that are going to be correlate are 

I don't think so. While the B2BUA allways correlates an incoming and an outgoing dialog, the UA may correlate two outgoing dialogs. Additionaly, the UA may kill one of the dialogs and continue the other dialog.

> hope) will be used rarely.

The Session-ID will be in every INVITE, not only "on demand". 

Thanks a lot
Laura

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 16:50:16 +0100

It's true. And this is a very good example. 

Thanks a lot
Laura

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, January 20, 2010 3:01 PM
> To: Ian Elz
> Cc: [email-masked]; Gonzalo Camarillo; 
> [email-masked]; Liess, Laura; Hülsemann, Martin; 
> Pinker, Gerold
> >>From your quote: ' "same-session could use a session-id 
> kind of value instead of callid+tags..." '
> > 
> > As was commented during the initial discussions on 
> Hadriel's first draft the session-id as proposed will not 
> replace call-id+tags. This occurs as forking will result in 
> multiple dialogs containing the same session-id. This only 
> really presents an issue during the early-dialog phase as 
> only one early-dialog will result in an established session.
> 
> > If you need session-id to be able to match early dialogs 
> then you need session-id to have a different form.
> > 
> > In this scenario for session tracking or established 
> session identification only the UAC-part is required but for 
> identification of an individual early dialog both parts would 
> be required.
> > 
> > Ian
> > 
> > Cc: [email-masked]; Gonzalo Camarillo; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > So let me start with the Hadriel question: "same-session 
> could use a session-id kind of value instead of callid+tags 
> > I do think it should use a session-id kind of value! (the 
> mechanism proposed in same-session draft if stale, as it is 
> the all draft, so it is a waste of time talk about it. Lets 
> instead talk of and compare with the disaggregate media one:
> > 
> > In my opinion the scenario to correlate an original call 
> with a new create by a B2BUA is quite similar to the one 
> where the calls that are going to be correlate are generate 
> by the same UA.
> > That is even more true if the correlation identifier is 
> generated by the UA and not by the B2BUA or any other server 
> within the network.
> > So the Hadriel's draft could be a good starting point to 
> draft solution for disaggregated media, of course it we get 
> > I wouldn't be worried about about the performance issue 
> raised by Laura, at the end it would be enough insert a tag 
> into the Session-ID header to discriminate the scenario when 
> it is used for debugging and when for disaggregated purpose.
> > Coming to the SIP-XMPP scenario: here I don't have a strong 
> idea, but I guess that an identifier a la session-id could 
> work also in this scenario.
> > 
> > 
> > of course I may be wrong
> > 
> > cheers
> > Sal
> >

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 21 Jan 2010 10:40:20 -0600

Laura,

> The Session-ID will be in every INVITE, not only "on demand".

Just trying to be careful here - my understanding is that we would encourage 
people to use Session-ID this way (adding it "on demand" doesn't help us 
troubleshoot a call that's already failed), but we would not require that 
(Session-ID at MUST strength for every INVITE).

Am I understanding what you're saying correctly?

Thank you,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2010 12:21:53 -0500

> I don't think so. While the B2BUA allways correlates an incoming and an outgoing dialog, the UA may correlate two outgoing dialogs. Additionaly, the UA may kill one of the dialogs and continue the…

You've identified two extremes that seem different.
There are also cases that fall between those extremes.
For instance I'll fall back on 3pcc (which provides a never ending 
source of counter examples):

Once again the classic 3pp case:

	A ------ B ----- C
  	         |------ D

Initially B connects A and C in a call.
Later, B does a "transfer" by inviting D and reinviting A with D's media 
replacing C's, and sends a BYE to C.

I guess there is a demand that there be a session id that is shared by 
A-B and B-C. After the transfer, there should be a session id shared by 
A-B and B-D. Is there a single session id shared for all of that, or is 
there a different one after the transfer?

What if subsequent to that transfer (that resulted in A-B-D) there is 
another transfer that results in E-B-D?

Another hybrid would be:

	A ------ B
  	|        |------ D
	|--------------- D2

where A, after talking to D, added a separate session to D's separate 
device D2. (I don't know if there is any real use case for this.)

When you want the id's to be common, and when you want them to be 
separate depends on what you want to use them for. The one that is 
useful for billing may not be the one that is useful for correlation of 
behavior at the UA.

	Thanks,
	Paul

>> idea, but I

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 21 Jan 2010 20:22:38 +0200

> I don't think so. While the B2BUA allways correlates an incoming and an outgoing dialog, the UA may correlate two outgoing dialogs. Additionaly, the UA may kill one of the dialogs and continue the…
right,
what you really need in the B2BUA scenario is a mechanism to identify 
one single dialog that happens to be split  in two (incoming and 
outgoing) going through the B2BUA.

In the disaggregated media instead is to correlate a session made by two 
or more different outgoing dialogs generated by the same user so that 
they are treated by
the far end of the session as a single media session. Here the 
correlation mechanism should also have the property to pass 
transparently through the B2BUA.

So having thought more on this, thanks also to the mail discussion, I 
think it should be better taking the two Id's separate,
as using the same could generate a lot of confusion in several scenarios.

/Sal

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 14:35:33 +0100

Spencer, 

> Am I understanding what you're saying correctly?

The current Session-ID draft states: 
" If an out-of-dialog request is received by a B2BUA compliant with
   this document, and the request does *not* contain a Session-ID
   header field, the B2BUA MUST generate a new Session-ID. "  

Most EDs will probably not generate a Session-ID, but the first B2BUA in the path will, if a carrier intends to use Session-ID.

Does this answer your question? 

Thanks a lot
Laura

---

From: <[email-masked]>
Date: Fri, 22 Jan 2010 15:59:24 +0100

Paul,

Thank you for the examples. The scenarios can be really complex. I hope we can get these correlation identifiers, whatever their names, to work correctly in all cases.... 

I am not sure I understood your message correctly. Do you say we should have two different identifiers because we use them for two different things? 

Thanks a lot
Laura

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, January 21, 2010 6:22 PM
> To: Liess, Laura
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> Hülsemann, Martin; Pinker, Gerold
> with a new 
> > I don't think so. While the B2BUA allways correlates an 
> incoming and an outgoing dialog, the UA may correlate two 
> outgoing dialogs. Additionaly, the UA may kill one of the 
> dialogs and continue the other dialog.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Jan 2010 11:05:57 -0500

> I am not sure I understood your message correctly. Do you say we should have two different identifiers because we use them for two different things? 

I think there may be more than two distinct usages that will require 
different ones.

IMO use cases should be gathered and then bucketed into sets that can be 
satisfied by a single mechanism, without assuming initially how many 
buckets there will be.

(But I'm still on record as not being convinced that a correlation id is 
needed *at all* for the case when multiple sip UAs are participating on 
behalf of a single user in a call.)

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 16:14:47 +0100

Sal, 

Sorry for the late answer. Somehow I overlooked your mail. 

> .... I 

This is also my opinion. 

Thanks a lot
Laura