Subject: [siprec] Session-id proposal in DISPATCH

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 Aug 2010 08:37:46 +0200

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

---

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

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:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 5 Aug 2010 10:48:46 +0200

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)

> -----Original Message-----
> 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
> 
> > 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:
> > The SIPREC list can, of course, be used to discuss SIPREC 
> requirements in this area, but please do not cross-post. Use:

---

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

Howdy,
Partha raised this on dispatch in relation to the SIPSCOTCH charter.  The scenario he described is the following:

SRC1            B2BUA             SRC2               SRS                                                          
 |                 |                 |                 |            
 |--INV(D1/S1)---->|--INV(D2/S1)---->|                 |    
 |                 |                 |                 |
 |-INV(D3/S2/MS1)------------------------------------->|
 |                 |                 |                 |
 |<-200(D1/S1)-----|<-200(D2/S1)-----|                 |            
 |                 |                 |-INV(D4/S3/MS1)->|
 |--ACK(D1/S1)---->|--ACK(D2/S1)---->|                 |
 |                 |                 |                 |
 |<-200(D3/S2/MS1)-------------------------------------| 
 |                 |                 |                 |
 |                 |                 |<-200(D4/S3/MS1)-|
 |                 |                 |                 |
 |--ACK(D3/S2/MS1)------------------------------------>|
 |                 |                 |                 |
 |                 |                 |-ACK(D4/S3/MS1)->|

SRC1 and SRC2 are in the same call and record it on the same SRS, but since the SIP Call-ID is changed by the B2BUA, the SRS doesn't know they're the same call.

My questions to the siprec folks are:
1) Does it really matter that the SRS doesn't know they're the same call?  Like is it a nice-to-have but not requirement?

2) Is it really the SIP messages of the recorded session that the SRS cares about correlating, or is it actually that they're the same media?  I ask because SIPSCOTCH is about correlating the SIP Messages, not media.  I think Mediactrl had a similar issue with using a SIP Call-ID across B2BUA's, but since what they cared about was *media*, they created a "cfw-id" SDP attribute for correlation.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elwell, John
> Sent: Thursday, August 05, 2010 4:49 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> 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 <[email-masked]>
Date: Fri, 20 Aug 2010 09:05:14 -0400

> My questions to the siprec folks are:

These are good questions.
AFAIK the answers to them are not yet known for certain.
Its certainly not known if session-id is the way to solve these problems.

> 1) Does it really matter that the SRS doesn't know they're the same call?  Like is it a nice-to-have but not requirement?

 From some use cases I have seen, it is at least somewhat important.
Otherwise there may end up being a lot of redundant recording.
If it can't be detected in some explicit way, then it may well be
determined heuristically by matching identities of endpoints, start
times of calls, etc. Such things may work some of the time but aren't ideal.

> 2) Is it really the SIP messages of the recorded session that the SRS cares about correlating, or is it actually that they're the same media?  I ask because SIPSCOTCH is about correlating the SIP M…

In this precise case it might be the media.
But the goal is to record all the relevant data about the call, or 
related calls. Some of that is media, while other parts (e.g. the 
identity of the participants) is available from the signalng.
So both are required to get it all.

	Thanks,
	Paul