Subject: Re: [dispatch] Proposal for Session ID charter

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Aug 2010 15:34:24 -0700

I would find it more useful to scope it by what is being correlated than what the many use cases for various correlations might be. One of the problems with saying the use is troubleshooting is that just about anything is useful for troubleshooting in some case. I have no objections to this proposed working group doing what the type of correlation the SIP REC WG needs but I have no idea what that is - I suspect this would not meet the needs as far as I understand them. 

On Jul 30, 2010, at 24:46 , Elwell, John wrote:

> Can somebody please remind me why this is scoped only for troubleshooting. For example, in SIPREC, we anticipate a need for a Session Recording Server to be able to correlate two recorded sessions from different Session Recording Clients. For example, if a customer call is transferred from one agent to a second agent, the two agents might be using different Session Recording Clients to send media to the Session Recording Server. What would be the barrier to using session ID for this case? Is it just the lack of guaranteed uniqueness, or are there other factors?
> 
> John
> 
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
>> Sent: 29 July 2010 23:50
>> To: Cullen Jennings
>> Cc: [email-masked] list
>> Subject: Re: [dispatch] Proposal for Session ID charter
>> 
>> I like it
>> 
>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings
>> <[email-masked]> wrote:
>>> 
>>> I tried to write a proposal that I think reflects what the
>> proponents of this WG want. Here's my stab at it.
>>> 
>>> ------------------
>>> 
>>> 
>>> Troubleshooting SIP networks can be improved by correlating
>> messaging across several devices. This working group will
>> define a correlation identifier to be used for the
>> troubleshooting and the for correlation of logging
>> information from different SIP devices in the network.
>>> 
>>> Sip transactions are often triggered by another SIP
>> transaction. Two transactions are in the same "session" if
>> one was triggered by the other due to redirection, REFER
>> processing, retargeting, or forwarding on a B2BUA. This
>> working group will define a correlation identifier that
>> identifies  all the transactions in the same session.  The
>> scope of the identifier pertains to the SIP signaling layer
>> only, and not media.   For example, several UA participating
>> in a conference call may be receiving the same media but
>> would not be in the same session.
>>> 
>>> The design of the correlation identifier needs to take into
>> account the issue of not revealing the topology of network.
>> The mechanism should be applicable for Proxies, UAs, PBXs,
>> SBCs, Application Servers, Softswitches, Phones, and Gateways.
>>> 
>>> This working group will coordinate with other relevant
>> working groups and area including Ops, and sipcore.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>> 
>> 
>> 
>> 
>> --
>> Victor Pascual Ávila
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
> 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Aug 2010 11:40:05 -0400

Cullen,

> I would find it more useful to scope it by what is being correlated than what the many use cases for various correlations might be. One of the problems with saying the use is troubleshooting is tha…

I share the concern about ambiguity of "troubleshooting".

But I don't see how picking what is to be correlated is the starting 
point. ISTM that the use cases provide the info to decide which dialogs 
should be correlated and which should not.

Use cases for widely varying purposes can end up being complementary in 
this regard. But of course there most likely will still be a need to 
throw some use cases "out of the boat" if they require incompatible 
correlations.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 11 Aug 2010 07:04:55 +0530

Hadriel,

I attached the use case which illustrates the session-id change during mid-dialog. As a individual use case, the use case is used for transfer based on "Re-INVITE" mechanism. The use case is useful for creating the complex supplementary services when use case is used as service primitive. This use case is deployed by B2BUA in Service Provider softswitches and Enterprise PBXs. The use case does not propose any solution but it just indicates the problem in creating the session-id. Even in case session-id is used for troubleshooting only, the session-id has to be generic enough to handle this use case.  Please let me know your thought on this.

I'll add more usecases based on the response for this mail.

Thanks

Partha

________________________________

From: [email-masked] on behalf of Parthasarathi R (partr)
Sent: Fri 7/30/2010 5:47 PM
To: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave
Cc: [email-masked]
Subject: Re: [dispatch] Proposal for Session ID charter

Hadriel,

Instead working with solution in mind, Shall we start with the usecases
document. The usecase document will help us to decide whether the single
header or multiple header required. It will help to identify the generic
session-id if one exists. The usecase requirement will be very useful as
we are talking about the complex dialog scenarios which involves set of
B2BUA.

As I mentioned in the earlier mail thread, I'll come up with the usecase
document as a starting point, add more relevant usecases and we will
brainstorm whether the usecases are relevant for the session id or not.
Please let me know your opinion on the same.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Friday, July 30, 2010 5:14 PM
To: Paul Kyzivat (pkyzivat); Peter Musgrave
Cc: [email-masked] list
Subject: Re: [dispatch] Proposal for Session ID charter

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, July 30, 2010 6:08 AM
>
> 2) Other applications that require correlation of some class of
>     related dialogs for some purpose other than troubleshooting
>     are driven away, and so must define yet another header and id
>     for their own purposes.

I know adding more headers sucks.  But that may be the safest thing.

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 11 Aug 2010 09:34:10 +0200

Partha,

I see the point you are making, which sounds reasonable, although I think the diagram is confusing because separate dialog D2 starts off between B2BUA1 and B2BUA2, but suddenly changes to being between B2BUA1 and Bob. Likewise D5 changes its scope.

John

> [mailto:[email-masked]] On Behalf Of Parthasarathi 
> R (partr)
> Sent: 11 August 2010 02:35
> To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat 
> (pkyzivat); Peter Musgrave
> Cc: [email-masked]
> I attached the use case which illustrates the session-id 
> change during mid-dialog. As a individual use case, the use 
> case is used for transfer based on "Re-INVITE" mechanism. The 
> use case is useful for creating the complex supplementary 
> services when use case is used as service primitive. This use 
> case is deployed by B2BUA in Service Provider softswitches 
> and Enterprise PBXs. The use case does not propose any 
> solution but it just indicates the problem in creating the 
> session-id. Even in case session-id is used for 
> troubleshooting only, the session-id has to be generic enough 
> to handle this use case.  Please let me know your thought on this.
> 
>  
> 
> [mailto:[email-masked]] On
> > Behalf Of Paul Kyzivat

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 11 Aug 2010 14:48:58 +0530

John,

Thanks for accepting the use case and also for pointing out the flaw in
it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3 is
between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated the
use case and attached with this mail for avoiding the confusion.

The focus of the use case is to show that session-id may change during
the mid-dialog.

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2010 1:04 PM
To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat);
Peter Musgrave
Cc: [email-masked]
Subject: RE: [dispatch] Proposal for Session ID charter

Partha,

I see the point you are making, which sounds reasonable, although I
think the diagram is confusing because separate dialog D2 starts off
between B2BUA1 and B2BUA2, but suddenly changes to being between B2BUA1
and Bob. Likewise D5 changes its scope.

John

> [mailto:[email-masked]] On Behalf Of Parthasarathi R 
> (partr)
> To: Parthasarathi R (partr); Hadriel Kaplan; Paul Kyzivat (pkyzivat); 
> Peter Musgrave
> Cc: [email-masked]
> I attached the use case which illustrates the session-id change during

> mid-dialog. As a individual use case, the use case is used for 
> transfer based on "Re-INVITE" mechanism. The use case is useful for 
> creating the complex supplementary services when use case is used as 
> service primitive. This use case is deployed by B2BUA in Service 
> Provider softswitches and Enterprise PBXs. The use case does not 
> propose any solution but it just indicates the problem in creating the

> session-id. Even in case session-id is used for troubleshooting only, 
> the session-id has to be generic enough to handle this use case.  
> Please let me know your thought on this.
> 
>  
> 
> Instead working with solution in mind, Shall we start with the 
> usecases document. The usecase document will help us to decide whether

> the single header or multiple header required. It will help to 
> identify the generic session-id if one exists. The usecase requirement

> will be very useful as we are talking about the complex dialog 
> scenarios which involves set of B2BUA.
> 
> As I mentioned in the earlier mail thread, I'll come up with the 
> usecase document as a starting point, add more relevant usecases and 
> we will brainstorm whether the usecases are relevant for the session 
> id or not.

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 11 Aug 2010 15:46:31 -0400

Hi,

I agree use cases like this are useful. I think they are covered by
the part of the charter which indicates that the specific behaviour
under REFER will be defined. It may not be what is ideal for every
scenario - but the behaviour will be predictable.

I think the main issue w.r.t the charter is whether siprec needs
something like session-id (and if that something requires dialog
correlation - which the current session-id does not claim to provide).

The path forward to me seems to be
1)  go down the dialog correlation rabbit hole
- or -
2) re-label this into something more representative of it's purpose
(i.e. Debug-Tag:) and keep the scope narrow.

Peter

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 12 Aug 2010 11:26:04 +0530

Peter/all,

Thanks for accepting that usecases are useful for this discussion. The mentioned usecase is not about REFER in B2BUA1, but it is about Re-INVITE changing the session-id between two B2BUAs. From B2BUA2 perspective, it does not have any intelligence that REFER received in B2BUA1. The same RE-INVITE session-id scenario may occurs in B2BUA2 due to some other trigger. The current Hadriel's session-id solution does not cover this. I wish that usecase document has to be considered as one of the work item for this charter to identify which are all the usecases will be covered by the proposed session-id charter.

The main issue is whether the charter is applicable only for troubleshooting or it is the new SIP infrastructure which shall be used for different purpose depends upon the application. In case session-id is possible for the mentioned usecase, session-id shall be used for session loopback identification in B2BUA2 with the combination of other SIP parameters. Without session-id in SIP message, it is not possible to identify the session loopback for all the usecases today. 

The other way to look at SIP loopback detection in B2BUA/SBC using session-id is as follows: The session loopback detection mechanism in B2BUA/SBC avoids the complicated troubleshooting of loop callflows in B2BUA SIP networks. I'm interested in hearing your and others opinion here.
 
I attached the mail thread by John Elwell which indicates the session-id usage in SIPREC. I also attached one of the possible callflow for the same. SIPREC is yet to define the callflows, so the callflow may change. 

Thanks
Partha
 
-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 1:17 AM
To: Parthasarathi R (partr)
Cc: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [dispatch] Proposal for Session ID charter

Hi,

I agree use cases like this are useful. I think they are covered by the part of the charter which indicates that the specific behaviour under REFER will be defined. It may not be what is ideal for every scenario - but the behaviour will be predictable.

I think the main issue w.r.t the charter is whether siprec needs something like session-id (and if that something requires dialog correlation - which the current session-id does not claim to provide).

The path forward to me seems to be
1)  go down the dialog correlation rabbit hole
- or -
2) re-label this into something more representative of it's purpose (i.e. Debug-Tag:) and keep the scope narrow.

Peter

On Wed, Aug 11, 2010 at 5:18 AM, Parthasarathi R (partr) <[email-masked]> wrote:
> John,
>
> Thanks for accepting the use case and also for pointing out the flaw 
> in it. As you already guess, D2 & D5 is between B2BUA1 and B2BUA2, D3 
> is between B2BUA2 and Bob, D6 is between B2BUA2 and Carol. I updated 
> the use case and attached with this mail for avoiding the confusion.
>
> between B2BUA1 and B2BUA2, but suddenly changes to being between 
> B2BUA1 and Bob. Likewise D5 changes its scope.
>
> John
>
>

Subject: Re: [siprec] Session-id proposal in DISPATCH
From: "Elwell, John" <[email-masked]>
To: "Paul Kyzivat (pkyzivat)" <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 5 Aug 2010 14:18:46 +0530

In fact there are at least two cases where there are multiple RSs for a single CS (in its broader sense).

1. Where there is a single SRC, which has time-separated RSs to the SRS (because recording is stopped and started again). This should not be a problem, because presumably the single SRC could provide appropriate metadata to correlate the two RSs as belonging to the same CS.

2. Where there are different SRCs, each with an RS to the SRS - these can be simultaneous, overlapping or time-separated). This is the case where some form of session-id might help.

However, it is quite difficult to write requirements for case 2, because of getting agreement on the precise circumstances in which two SIP dialogs at different entities can be considered to be the same CS. Features such as attended transfer, unattended transfer, local conferencing, centralized conferencing, shared appearance bridging, etc., can all be involved, and these can be implemented in different ways (end-to-end, 3PCC). Getting agreement on exactly how a mediating SIP entity (UA/B2BUA) should behave in ensuring that appropriate SIP dialogs are given the same session-id and that others are given a different session-id sounds like it could be a nightmare. Furthermore, the mediating SIP entity might not be SIPREC-compliant, and therefore would not be obliged to support whatever session-id mechanism SIPREC might mandate.

For example, consider the case where there is an SRC at an agent's UA (or at a B2BUA serving the agent), and an SRC at a supervisor's UA (or at a B2BUA serving the supervisor). The agent's UA transfers a call (unattended) to the supervisor by sending a REFER request to the remote UA (say a PSTN gateway). If that remote UA does not support whatever session-id mechanism SIPREC requires, it might not be possible to achieve correlation.

So I have doubts whether we are in a position to specify precise requirements in a form that would solve case 2 in the vast majority of situations. In the absence of a session-id usable for this purpose, we are back to the SRS using heuristics (e.g., recording start/stop times, caller ID, CCUS content, etc..) to correlate two CSs from different SRCs.

John (as individual)

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 04 August 2010 16:47
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [siprec] Session-id proposal in DISPATCH
> 
> To follow up on this we need to get some homework done here 
> in siprec, 
> to know what correlations we need help with.
> 
> I think session-id is not needed for siprec in those cases where a 
> single SRC is managing an RC. It can then provide all the needed 
> correlation data itself.
> 
> ISTM the case where session-id is useful is when there are 
> multiple RS 
> that involve a single CS (in the loose sense, since we don't 
> yet have a 
> clear def of CS.) Then it may be up to the SRS to recognize the 
> correlation, so session-id could be useful.
> 
> I don't think we (yet) have enough facts to turn that need into 
> requirements on session-id.
> 
> 	Thanks,
> 	Paul
> 
> Elwell, John wrote:
> > DISPATCH is considering a proposed charter for a WG to 
> specify a session-id header field for correlating dialogs 
> belonging to the same session across B2BUAs. At present, it 
> is being specified only for troubleshooting purposes.
> > 
> > During some of the discussions in SIPREC, I have sensed 
> that there may be a need for correlating recordings that 
> derive from the same communication session. If so, I don't 
> know whether reuse of the proposed session-id would be a 
> candidate solution. The present scoping of the session-id 
> charter, whilst not necessarily preventing its reuse for 
> SIPREC purposes, may not be adequate, depending on exact 
> requirements from SIPREC. Thus we may end up defining yet 
> another mechanism for correlation, where a single mechanism, 
> adequately scoped, would have sufficed.
> > 
> > I would urge anyone who expects the session-id charter to 
> deliver a solution suitable for SIPREC use to engage in 
> discussions on the DISPATCH list, e.g., in the following thread:
> > http://www.ietf.org/mail-archive/web/dispatch/current/msg02426.html
> > 
> > The SIPREC list can, of course, be used to discuss SIPREC 
> requirements in this area, but please do not cross-post. Use:
> > - the SIPREC list to discuss requirements for correlation;
> > - the DISPATCH list to influence the Session-ID charter, 
> based on requirements from SIPREC.
> > 
> > John
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> > 
> 
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 18 Aug 2010 16:37:23 -0400

Hi Partha,
Right, so this is the re-invite transfer use-case we talked about in Maastricht I believe.  I think B2BUA-2 is not necessary in the call flow drawing to show the issue you want to solve, right?  It's just B2BUA-1 that's important.

Like this:

Alice          B2BUA1            Bob             Carol
|                 |               |                |
|--INV(D1/S1)---->|--INV(D2/S1)-->|                |
|                 |               |                |
|<-200(D1/S1)-----|<-200(D2/S1)---|                |
|                 |               |                |
|---ACK(D1/S1)--->|--ACK(D2/S1)-->|                |
|                 |               |                |
|<==Alice Put Bob on Hold (RE-INV/200/ACK S1)====> |
|                 |               |                |
|--INV(D4/s2)---->|--INV(D5/S2)------------------->|
|                 |               |                |
|<-200(D4/S2)-----|<-200(D5/s2)--------------------|
|                 |               |                |
|--ACK(D4/S2)---->|--ACK(D5/S2)------------------->|
|                 |               |                |
|<===Alice put Carol on Hold (RE-INV/200/ACK S2)==>|
|                 |                |               |
|                 |                |               |
|--REFER/200(D1)->|                |               |
|<-NOTIFY/200(D1)-|                |               |
|                 |--Re-INV(D2/S?)>|               |
|                 |                |               |
|                 |--Re-INV(D5/S?)---------------->|
|                 |                |               |
|                 |<--200(D2/S?)---|               |
|                 |                |               |
|                 |<--200(D5/S?)-------------------|
|                 |                |               |
|                 |---ACK(D2/S?)-->|               |
|                 |                |               |
|                 |---ACK(D5/S?)------------------>|
|<-NOTIFY/200(D1)-|                |               |
|                 |                |               |
|<-BYE/200(D4/S2)-|                |               |
|                 |                |               |
|-BYE/200(D1/S1)->|                |               |
|                 |                |               |

In terms of the currently proposed SIPSCOTCH charter, this use-case has no impact, since the charter arguably includes it in scope... of course whether we solve it, or how we solve it, is not answered by the charter and would be a decision for the new WG I think.

-hadriel

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: Wednesday, August 11, 2010 5:19 AM
> To: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 18 Aug 2010 16:42:25 -0400

> Sent: Thursday, August 12, 2010 1:56 AM
> To: Peter Musgrave
> 
> Thanks for accepting that usecases are useful for this discussion. The
> mentioned usecase is not about REFER in B2BUA1, but it is about Re-INVITE
> changing the session-id between two B2BUAs. From B2BUA2 perspective, it
> does not have any intelligence that REFER received in B2BUA1. The same RE-
> INVITE session-id scenario may occurs in B2BUA2 due to some other trigger.
> The current Hadriel's session-id solution does not cover this. I wish that
> usecase document has to be considered as one of the work item for this
> charter to identify which are all the usecases will be covered by the
> proposed session-id charter.
>
> The main issue is whether the charter is applicable only for
> troubleshooting or it is the new SIP infrastructure which shall be used
> for different purpose depends upon the application. 

Just to be clear - all we're talking about right now is a SIPSCOTCH charter, not a solution to it.  The session-id draft is just one possible solution.
The re-Invite due to transfer call flow is still about troubleshooting, presumably, and the currently proposed charter would cover it.  That doesn't mean we'd have to solve it or support it, I think... just that it's in scope to be considered.

The currently proposed charter is:

Troubleshooting SIP networks can be improved by correlating messaging across several devices. This working group will define a correlation identifier to be used for the troubleshooting and the for correlation of logging information from different SIP devices in the network. 

Sip transactions are often triggered by another SIP transaction. Two transactions are in the same "session" if one was triggered by the other due to redirection, REFER processing, retargeting, or forwarding on a B2BUA. This working group will define a correlation identifier that identifies  all the transactions in the same session.  The scope of the identifier pertains to the SIP signaling layer only, and not media.   For example, several UA participating in a conference call may be receiving the same media but would not be in the same session. 

The design of the correlation identifier needs to take into account the issue of not revealing the topology of network. The mechanism should be applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Phones, and Gateways. 

This working group will coordinate with other relevant working groups and area including Ops, and sipcore.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Aug 2010 21:10:55 -0400

Hadriel,

The problem I have with using "troubleshooting" as the criterion for 
what things are in scope for this id is: it can include anything you 
might have trouble with:

if I'm trying to debug problems with conferencing, then it might be 
helpful to have the same session-id for all the participant connections 
to the focus;

if I was called by a conference focus, and then transfer that call to my 
other phone, then I want all that to have the same session-id;

yada yada

I would understand if the criterion was "troubleshooting the problems an 
SBC has correlating the logs of customers on both sides of the calls it 
handles".

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 19 Aug 2010 06:17:33 -0400

Hi Paul,

I don't have any issues with limiting the charter in that form -
although I would use the term B2BUA to be consistent with paragraph 2
of the charter.

Peter Musgrave

On Wed, Aug 18, 2010 at 9:10 PM, Paul Kyzivat <[email-masked]> wrote:
> Hadriel,
>
> The problem I have with using "troubleshooting" as the criterion for what
> things are in scope for this id is: it can include anything you might have
> trouble with:
>
> if I'm trying to debug problems with conferencing, then it might be helpful
> to have the same session-id for all the participant connections to the
> focus;
>
> I would understand if the criterion was "troubleshooting the problems an SBC
> has correlating the logs of customers on both sides of the calls it
> handles".
>
>        Thanks,
>        Paul
>
> Hadriel Kaplan wrote:
>>
>> Just to be clear - all we're talking about right now is a SIPSCOTCH
>> charter, not a solution to it.  The session-id draft is just one possible
>> solution.
>> The re-Invite due to transfer call flow is still about troubleshooting,
>> presumably, and the currently proposed charter would cover it.  That doesn't
>> mean we'd have to solve it or support it, I think... just that it's in scope
>> to be considered.
>>
>>
>> Troubleshooting SIP networks can be improved by correlating messaging
>> across several devices. This working group will define a correlation
>> identifier to be used for the troubleshooting and the for correlation of
>> logging information from different SIP devices in the network.
>> Sip transactions are often triggered by another SIP transaction. Two
>> transactions are in the same "session" if one was triggered by the other due
>> to redirection, REFER processing, retargeting, or forwarding on a B2BUA.
>> This working group will define a correlation identifier that identifies  all
>> the transactions in the same session.  The scope of the identifier pertains
>> to the SIP signaling layer only, and not media.   For example, several UA
>> participating in a conference call may be receiving the same media but would
>> not be in the same session.
>> The design of the correlation identifier needs to take into account the
>> issue of not revealing the topology of network. The mechanism should be
>> applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches,
>> Phones, and Gateways.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Aug 2010 08:06:51 -0400

> although I would use the term B2BUA to be consistent with paragraph 2

That isn't what I meant to suggest.

If the charter were drawn that narrowly then IMO it wouldn't be worth 
doing at all.

My point was that the scope needs to be specific enough that what is in 
and what is out can be determined.

I'm pretty sure that most people interested in this work are interested 
in it for some reason other than "troubleshooting". But 
"troubleshooting" has been used in the charter in order to avoid the 
conflict and/or political incorrectness of mentioning the actual reasons.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 19 Aug 2010 13:37:12 -0400

> Sent: Wednesday, August 18, 2010 9:11 PM
> To: Hadriel Kaplan
> 

Sure, but the proposed charter doesn't say it will solve all troubleshooting needs imaginable, nor does it say it will cover such conference scenarios.  And it does NOT say "troubleshooting is the criterion for what things are in scope".

It just says:
 Sip transactions are often triggered by another SIP transaction. Two
 transactions are in the same "session" if one was triggered by the other
 due to redirection, REFER processing, retargeting, or forwarding on a
 B2BUA. This working group will define a correlation identifier that
 identifies  all the transactions in the same session.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 19 Aug 2010 13:42:04 -0400

Hi Partha,
In one of our emails you attached the description of why SIPREC might need an identifier like session-id.  I'll respond to that in the siprec list, to see if they really mean a SIP session identifier, or if they mean a media identifier.

-hadriel

> [snip]
> I attached the mail thread by John Elwell which indicates the session-id
> usage in SIPREC. I also attached one of the possible callflow for the same.
> SIPREC is yet to define the callflows, so the callflow may change.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Aug 2010 09:27:09 -0400

Hadriel,

OK, my bad. :-(

(I've been following the thread for too long without going back to 
reread what the charter proposal actually said.)

Its true that "troubleshooting" is largely gratuitous in the proposal - 
it has little to do with what the group is chartered to work on.
The "session" is the focus, and the things that belong in the same 
session is, more or less, defined in the charter itself.

So the bottom line here is that anybody who wants the definition of 
"session" tweaked needs to accomplish that by proposing changes to the 
charter text. Right?

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 23 Aug 2010 18:54:49 +0530

Hi Hadriel,

I put B2BUA-2 in usecase with different application in mind. 

<Snip> The main issue is whether the charter is applicable only for
troubleshooting or it is the new SIP infrastructure which shall be used
for different purpose depends upon the application. In case session-id
is possible for the mentioned usecase, session-id shall be used for
session loopback identification in B2BUA2 with the combination of other
SIP parameters. Without session-id in SIP message, it is not possible to
identify the session loopback for all the usecases today. 

The other way to look at SIP loopback detection in B2BUA/SBC using
session-id is as follows: The session loopback detection mechanism in
B2BUA/SBC avoids the complicated troubleshooting of loop callflows in
B2BUA SIP networks. I'm interested in hearing your and others opinion
here. </Snip>

In case B2BUA2 has the intelligence of session-id, it will be possible
for B2BUA2 to build the signaling loopback application which is beyond
the current scope of SIP SCOTCH. The current charter restricts itself to
troubleshooting. IMO, the charter should not restrict the
application/usage (troubleshooting) of the generic session-id header
rather the charter shall define the "session" like mentioned in Para 2
of current SIP SCOTCH charter.

I wish to add the usecase document as a workitem in the charter as it
will help in coming up with the proper solution for session-id.

Thanks
Partha

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 2:07 AM
To: Parthasarathi R (partr); Elwell, John; Paul Kyzivat (pkyzivat);
Peter Musgrave
Cc: [email-masked]

Hi Partha,
Right, so this is the re-invite transfer use-case we talked about in
Maastricht I believe.  I think B2BUA-2 is not necessary in the call flow
drawing to show the issue you want to solve, right?  It's just B2BUA-1
that's important.

Like this:

Alice          B2BUA1            Bob             Carol
|                 |               |                |

In terms of the currently proposed SIPSCOTCH charter, this use-case has
no impact, since the charter arguably includes it in scope... of course
whether we solve it, or how we solve it, is not answered by the charter
and would be a decision for the new WG I think.

-hadriel

> > session-id. Even in case session-id is used for troubleshooting 
> > only, the session-id has to be generic enough to handle this use
case.

> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Hadriel Kaplan

Subject: RE: [dispatch] Proposal for Session ID charter
From: "Parthasarathi R (partr)" <[email-masked]>
To: "Peter Musgrave" <[email-masked]>
Cc: "Elwell, John" <[email-masked]>, "Hadriel Kaplan" <[email-masked]>, "Paul Kyzivat (pkyzivat)" <[email-masked]>, <[email-masked]>
Date: Thu, 12 Aug 2010 11:26:04 +0530

Peter/all,

 

Thanks
Partha
 
-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 1:17 AM
To: Parthasarathi R (partr)
Cc: Elwell, John; Hadriel Kaplan; Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [dispatch] Proposal for Session ID charter

Hi,

Peter

John (as individual)