Subject: [siprec] Participant role parameter in Metadata model

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 3 Jan 2011 17:23:25 +0530

Hi all,
 
>From the current metadata parameters, it is not possible for SRS to
deduce whether the participant is acting as "uac" or "uas" for a given
transaction in CS but SRC is aware of this information in most of the
scenarios. Participant role information in CS will be lost as RS is not
carry this information as part of metadata. IMO, it is better to add
this information as participant role with value as "uac" or "uas"  or
"don't know" in the metadata. 
 
This information helps to understand who initiated the dialog from SRS
perspective in case SRS has more configuration/metadata information
about the participant. Please let me know whether it is worth to add
this information as part of participant metadata information.
 
Thanks
Partha

---

From: Leon Portman <[email-masked]>
Date: Mon, 3 Jan 2011 14:05:55 +0200

Yes, it is very  important

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Monday, January 03, 2011 1:53 PM
To: [email-masked]
Subject: [siprec] Participant role parameter in Metadata model

Hi all,

>From the current metadata parameters, it is not possible for SRS to deduce whether the participant is acting as "uac" or "uas" for a given transaction in CS but SRC is aware of this information in most of the scenarios. Participant role information in CS will be lost as RS is not carry this information as part of metadata. IMO, it is better to add this information as participant role with value as "uac" or "uas"  or "don't know" in the metadata.

This information helps to understand who initiated the dialog from SRS perspective in case SRS has more configuration/metadata information about the participant. Please let me know whether it is worth to add this information as part of participant metadata information.

Thanks
Partha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Jan 2011 10:56:35 -0500

> this information as part of participant metadata information.

Its at least going to take some thought to get this right.
The metadata we have defined isn't really structured transactionally the 
same way sip is. Its more "declarative" than operational.

So for instance, there might be a metadata change that adds an 
additional media stream. There may have been multiple sip transactions 
take place to negotiate that new media stream. One specific participant 
may have sent the first transaction that initiated an o/a negotiation 
that resulted in the new media stream. But its possible the the first 
offer of that stream came from a different participant.

Now, perhaps there is some interest in recording all, or a summary, of 
all the sip traffic on the CS as part of the metadata. But that is 
likely to be overkill. If not, then I think roles such as UAC and UAS 
need to be translated into something that makes sense in the metadata. 
I'm not entirely sure what that would be - it varies for different 
pieces of the metadata.

	Thanks,
	Paul

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 5 Jan 2011 11:55:27 +0100

I agree with Paul that this needs some thought.

I suspect that the SRS does not need information about who is the uac or uas for a given SIP transaction but will want to know the role of each participant with regard to the session. For example who is the calling/called parties (i.e. who was the uac for the initial dialog creating INVITE). 

The SRS may also need information about who initiates any additional media streams during a session but I am not sure about this.

The requirements are not much help as we only have REQ-12 which states:

"The mechanism MUST provide the SRS with metadata describing CSs that are being recorded, including the media being used and the identities of parties involved".

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 03 January 2011 15:57
To: [email-masked]
Subject: Re: [siprec] Participant role parameter in Metadata model

	Thanks,
	Paul

---

From: "Sid Rao" <[email-masked]>
Date: Wed, 5 Jan 2011 08:36:11 -0500

Ideally, there would be additional data about the call (redirection, for example), with the ability to provide additional ancillary custom data.

Sid Rao - Chief Technology Officer - CTI Group, Inc. - +1 (317) 262-4677

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Paul Kyzivat <[email-masked]>; [email-masked] <[email-masked]>
Sent: Wed Jan 05 05:55:27 2011
Subject: Re: [siprec] Participant role parameter in Metadata model

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 03 January 2011 15:57
To: [email-masked]
Subject: Re: [siprec] Participant role parameter in Metadata model

	Thanks,
	Paul

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Jan 2011 15:03:47 -0500

> The SRS may also need information about who initiates any additional media streams during a session but I am not sure about this.

For this, we will need to be specific about what it means to initiate a 
media stream. For instance:

- is it a participant who offered a stream that wasn't yet in
   the session?

- does it matter what "direction" was offered? (If a participant
   offers the stream, but in recvonly mode, is it still the originator?

- what about changes to an existing stream? E.g. if a reinvite offers
   a codec change on a stream that was initiated by a different
   participant, does that mean a new replacement stream originated
   by the new offerer?

- what if an existing stream is replaced by a totally different
   stream. (This is allowed, but kind of unusual.) For instance an
   audio stream could be replaced by a t38 fax stream.

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 5 Jan 2011 12:11:36 -0800

I agree the wording for uac and uas may be a bit too technical or too
raw and it can be confusing to interpret what it really means. For
example, if a caller uses a 3pcc application to place a call to a
callee, the 3pcc app would place two SIP dialogs to the caller and
callee and join them together, and you will end up with two uas parties
which can be difficult to interpret the result. 

Ideally I think it should be something like calling party or called
party. If the SRC understands how to interpret the party role then it
can record it in the metadata.

Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sid Rao
> Sent: Wednesday, January 05, 2011 8:36 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Ideally, there would be additional data about the call (redirection,
> for example), with the ability to provide additional ancillary custom
> data.
> 
> I suspect that the SRS does not need information about who is the uac
> or uas for a given SIP transaction but will want to know the role of
> each participant with regard to the session. For example who is the
> calling/called parties (i.e. who was the uac for the initial dialog
> creating INVITE).
> 
> The SRS may also need information about who initiates any additional
> media streams during a session but I am not sure about this.
> 
> "The mechanism MUST provide the SRS with metadata describing CSs that
> are being recorded, including the media being used and the identities
> of parties involved".
> 
> Regards
> Andy
> 
> 
> 

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Sid Rao" <[email-masked]>
Date: Wed, 5 Jan 2011 15:18:24 -0500

The challenge I see is that in real-world applications of this
specification, UAC to UAS is not descriptive enough for real-world call
center supervisors and financial regulatory authorities to truly find
and recognize a call.  As you note, in the 3PCC scenario noted below, 2
recordings of essentially an identical conversation from an end-user
perspective.

Another scenario, which is a typical use case, is cradle-to-grave
recording scenarios.  UAC to UAS conversations represent, in effect, in
a B2BUA environment individual conversation legs.  However, in
cradle-to-grave scenarios, we would need a mechanism to relate all
related UAC to UAS calls into a single presentable call.  If the
metadata model included a concept of diversion (transfer) or a "global
call ID" this could be accommodated.  Forgive me if I'm mistaken, but I
did not see this accommodated in the requirements.

Otherwise we risk the specification being less functional than existing
solutions, reducing the motivation for adoption and compliance.

Best Regards,

Sid Rao

-----Original Message-----
From: Henry Lum [mailto:[email-masked]] 
Sent: Wednesday, January 05, 2011 3:12 PM
To: Sid Rao; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [siprec] Participant role parameter in Metadata model

Henry

> Behalf Of Paul Kyzivat

> The metadata we have defined isn't really structured transactionally 
> the same way sip is. Its more "declarative" than operational.
> 

> I'm not entirely sure what that would be - it varies for different 

------------------------------------------------------------------------
-------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is
authorized. Any liability arising from any party acting, or refraining
from acting, on any information contained in this e-mail is hereby
excluded. If you are not the intended recipient, please notify the
sender immediately, destroy the original transmission and its
attachments and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
and/or its affiliated entities.

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 5 Jan 2011 13:35:37 -0800

For cradle-to-grave scenarios, the SRC may choose to use a CS group to
represent a series of call transfers to different parties in the call,
where each transfer may be considered a separate CS. There is a use case
outlined in the metadata draft to describe such scenario (use case 3).

Regards,
Henry

> From: Sid Rao [mailto:[email-masked]]
> Sent: Wednesday, January 05, 2011 3:18 PM
> To: Henry Lum; [email-masked];
> [email-masked]; [email-masked]
> > > scenarios. Participant role information in CS will be lost as RS
is
> > not
-----------------------------------------------------------------------
> -

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 6 Jan 2011 11:52:58 +0530

The main notion for starting this mail thread is to

1) Identify the initiator of the call (caller, callee)
2) To track which Participant puts on hold/resume or other media changes

I proposed "uac" & "uas" as they are well accepted in SIP world (RFC
3261). It is possible to SRS to deduce the different meaning based on
the other attributes and configuration. I completely agree that it is
too generic term for call-centre applications. 

The individual attributes like "caller" and "callee" may mislead in few
B2BUA based transfer scenarios. The example is as follows:

1) A calls B --->   A - Caller, B - Callee
2) A put B on hold
3) A calls c --->   A - Caller,  B - Callee
4) A transfer C to B ---->     B - Callee, C - Callee

Initial proposal of "Initiator" and "direction" are removed from the
metadata model. I'm fine in case we come up the most acceptable
attribute specific for recording.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Thursday, January 06, 2011 3:06 AM
To: Sid Rao; [email-masked]; Paul Kyzivat
(pkyzivat); [email-masked]
Subject: Re: [siprec] Participant role parameter in Metadata model

Regards,
Henry

is

> attachments and do not disclose the contents to any other person, use 
> it for any purpose, or store or copy the information in any medium.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 6 Jan 2011 11:14:28 +0100

I think most points have already been made by others, but my view is as follows (some of this was also discussed some time ago in other threads).

1. The UAC and UAS terms are transaction-oriented - during the lifetime of a CS there can be many transactions, some in one direction and some in the other direction.

2. We could limit it to the dialog-forming transactions - whether the SRC is associated with the UAC or UAS of that initial transaction. I am not sure why this information would be of any use to the SRS in many cases. For example, if calls are established by 3PCC, the UA with which the SRC is associated might always be the UAS of the dialog-forming transaction, so no meaningful information will be delivered to the SRS.

3. Where the SRC is associated with a B2BUA, the B2BUA would act as both SRC and SRS during dialog formation, i.e., the SRS or one dialog and the SRC of the other dialog, both dialogs being part of the same CS. Perhaps we have to consider the B2BUA as acting on behalf of one party.

4. There are also issues where the SRC is associated with a conference focus.

5. Information that might really benefit the SRS would be direction of CS establishment, i.e., whether the SRC is acting on behalf of the calling or called party. However, particularly in 3PCC situations, this might not be known. Also this might not be meaningful in conference situations.

I would be curious what existing implementations use and how this works in 3PCC, B2BUA and conference situations.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 13 Jan 2011 05:58:12 +0530

John,
 
Sorry for the delay response. Please read inline.
 
Thanks
Partha

________________________________

From: Elwell, John [mailto:[email-masked]]
Sent: Thu 1/6/2011 3:44 PM
To: Parthasarathi R (partr); Henry Lum; Sid Rao; Hutton, Andrew; Paul Kyzivat (pkyzivat); [email-masked]
Subject: RE: [siprec] Participant role parameter in Metadata model

1. The UAC and UAS terms are transaction-oriented - during the lifetime of a CS there can be many transactions, some in one direction and some in the other direction.
<Partha> Agreed </Partha>
2. We could limit it to the dialog-forming transactions -

<Partha> It depends upon the level of analysis and service provided by SRS. For example:

Example 1:

1) Audio dialog is established between A and B and A is the caller.

2) B send new offer with Video and the dialog is escalated to video between A and B after A answer

>From Recording, it may be required to understand who make the dialog as video apart who initiated the dialog

Example2:

Agent performance shall be measured by the amount of time the customer is in the call hold by Agent but hold put by customer should not be considered for the performance. 

IOW, The initiator of the new offer within dialog may be of interest for few services. Please let me know your opinion here. UAC and UAS  may be very crude terms, but we need to work for better terminology which is specific to recording </Partha>

 whether the SRC is associated with the UAC or UAS of that initial transaction. I am not sure why this information would be of any use to the SRS in many cases. 

<Partha> The information is useful to derive caller/callee in case caller/callee information is not passed across </Partha>

For example, if calls are established by 3PCC, the UA with which the SRC is associated might always be the UAS of the dialog-forming transaction, so no meaningful information will be delivered to the SRS.

<Partha> Agreed. Caller/Callee is not applicable for all SIP devices but it is critical for few SIP devices (Call Centre solution). This information shall be optional parameter rather than mandatory </Partha>

3. Where the SRC is associated with a B2BUA, the B2BUA would act as both SRC and SRS during dialog formation,

<Partha> I guess that you are intended to say B2BUA acts as both UAC and UAS. </Partha>

 i.e., the SRS or one dialog and the SRC of the other dialog, both dialogs being part of the same CS. Perhaps we have to consider the B2BUA as acting on behalf of one party.
<Partha> B2BUA has convert UAC or UAS information appropriately as it is middle box in the dialog </Partha>
4. There are also issues where the SRC is associated with a conference focus.

<Partha> Participant role information may be irrelevant. As I mentioned, this information is not generic enough. </Partha>

5. Information that might really benefit the SRS would be direction of CS establishment, i.e., whether the SRC is acting on behalf of the calling or called party. 

<Partha> For -03 metadata draft, we will keep initiator attribute in CS </Partha>

However, particularly in 3PCC situations, this might not be known. Also this might not be meaningful in conference situations.

<Partha> From the discussion in SIPREC, my understanding is that the participant role information is required in most of the call centre solution to distinguish whether Agent initiated the call or customer initiated the call </Partha>

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Jan 2011 08:32:20 +0100

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 13 January 2011 00:28
> To: Elwell, John; Henry Lum; Sid Rao; Hutton, Andrew; Paul 
> Kyzivat (pkyzivat); [email-masked]
> To: Parthasarathi R (partr); Henry Lum; Sid Rao; Hutton, 
> Andrew; Paul Kyzivat (pkyzivat); [email-masked]
> I think most points have already been made by others, but my 
> view is as follows (some of this was also discussed some time 
> ago in other threads).
> 
> 1. The UAC and UAS terms are transaction-oriented - during 
> the lifetime of a CS there can be many transactions, some in 
> one direction and some in the other direction.
> From Recording, it may be required to understand who make the 
> dialog as video apart who initiated the dialog
> 
> Example2:
> 
> Agent performance shall be measured by the amount of time the 
> customer is in the call hold by Agent but hold put by 
> customer should not be considered for the performance. 
> 
> IOW, The initiator of the new offer within dialog may be of 
> interest for few services. Please let me know your opinion 
> here. UAC and UAS  may be very crude terms, but we need to 
> work for better terminology which is specific to recording </Partha>
> 
>  whether the SRC is associated with the UAC or UAS of that 
> initial transaction. I am not sure why this information would 
> be of any use to the SRS in many cases. 
> 
> <Partha> The information is useful to derive caller/callee in 
> case caller/callee information is not passed across </Partha>
> 
> For example, if calls are established by 3PCC, the UA with 
> which the SRC is associated might always be the UAS of the 
> dialog-forming transaction, so no meaningful information will 
> be delivered to the SRS.
> 
> <Partha> Agreed. Caller/Callee is not applicable for all SIP 
> devices but it is critical for few SIP devices (Call Centre 
> solution). This information shall be optional parameter 
> rather than mandatory </Partha>
[JRE] But even a call centre solution could be implemented by 3PCC, so the direction of call establishment would not necessarily be available to the SRC. The direction of the initial offer might sometimes give a clue, but there are different approaches that can be taken for 3PCC. so I am not sure this would be a lot more reliable than the direction of the INVITE request.

> 
> 3. Where the SRC is associated with a B2BUA, the B2BUA would 
> act as both SRC and SRS during dialog formation,
> 
[JRE] Yes, sorry for the confusion. I meant, of course, that the B2BUA acts as both UAC and UAS.

> 
>  i.e., the SRS or one dialog and the SRC of the other dialog, 
> both dialogs being part of the same CS. Perhaps we have to 
> consider the B2BUA as acting on behalf of one party.
> <Partha> B2BUA has convert UAC or UAS information 
> appropriately as it is middle box in the dialog </Partha>
> <Partha> Participant role information may be irrelevant. As I 
> mentioned, this information is not generic enough. </Partha>
> 
> 5. Information that might really benefit the SRS would be 
> direction of CS establishment, i.e., whether the SRC is 
> acting on behalf of the calling or called party. 
> 
> However, particularly in 3PCC situations, this might not be 
> known. Also this might not be meaningful in conference situations.
> 
> I would be curious what existing implementations use and how 
> this works in 3PCC, B2BUA and conference situations.
> 
> <Partha> From the discussion in SIPREC, my understanding is 
> that the participant role information is required in most of 
> the call centre solution to distinguish whether Agent 
> initiated the call or customer initiated the call </Partha>
[JRE] Yes, I understand people have said it is required, but I am still curious how they solve it today, particularly for 3PCC and conference situations.

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jan 2011 09:15:05 -0500

I think the best we can do for call (and media) origination is to 
provide a way for the SRC to specify this when it knows, while 
recognizing that it may not always be known.

	Thanks,
	Paul

On 1/13/2011 2:32 AM, Elwell, John wrote:
>> <Partha>  Agreed</Partha>
>> work for better terminology which is specific to recording</Partha>
>>
>> case caller/callee information is not passed across</Partha>
>>
>> rather than mandatory</Partha>
>> <Partha>  I guess that you are intended to say B2BUA acts as
>> both UAC and UAS.</Partha>
>> appropriately as it is middle box in the dialog</Partha>
>> mentioned, this information is not generic enough.</Partha>
>>
>> <Partha>  For -03 metadata draft, we will keep initiator
>> attribute in CS</Partha>
>>
>> initiated the call or customer initiated the call</Partha>