Subject: [siprec] CS caller and callee in metadata

From: "Emil Andonov" <[email-masked]>
Date: Fri, 12 Dec 2014 10:32:29 +1100

Hi,

I may be missing something very obvious, but I do not see how the SRS will
determine who called whom in a communications session from the metadata it
receives from the SRC. Did Bob call Alice in section "3.2.1. Example 1:
Basic Call", or vice versa?  

Recorders store this information for each recording to help with searches
such as "give me all recordings of calls to Alice on  the dd/mm/yyyy .".

Unless I am missing something obvious, this information  can be part of the
"session" element - just a suggestion.

The issue becomes a bit more complex for recordings of calls with transfer.
Recorders store information such as "Bob called Alice. Alice transferred the
call to Emil ." about the recording. Again, this information is not
available in the metadata.

Thank you

Emil

--

Emil Andonov

Prolancer Pty Ltd

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 15 Dec 2014 16:03:08 +0000

I think you are right.

http://tools.ietf.org/html/draft-ietf-siprec-metadata-16#section-6.5.1 states that the roles of participants, which I assume could include calling/called party, are not specified here and would be the subject of some extension data.

So this would be a proprietary extension unless somebody defines additional standard metadata for this.

Andy

> -----Original Message-----
> From: siprec [mailto:[email-masked]] On Behalf Of Emil Andonov
> Sent: 11 December 2014 23:32
> To: [email-masked]
> Subject: [siprec] CS caller and callee in metadata
> 
> Hi,
> 
> I may be missing something very obvious, but I do not see how the SRS
> will determine who called whom in a communications session from the
> metadata it receives from the SRC. Did Bob call Alice in section
> "3.2.1. Example 1: Basic Call", or vice versa?
> 
> Recorders store this information for each recording to help with
> searches such as "give me all recordings of calls to Alice on  the
> dd/mm/yyyy .".
> 
> Unless I am missing something obvious, this information  can be part of
> the "session" element - just a suggestion.
> 
> The issue becomes a bit more complex for recordings of calls with
> transfer. Recorders store information such as "Bob called Alice. Alice
> transferred the call to Emil ." about the recording. Again, this
> information is not available in the metadata.
> 
> Thank you
> Emil
> --
> Emil Andonov
> Prolancer Pty Ltd

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2014 11:38:18 -0500

> So this would be a proprietary extension unless somebody defines additional standard metadata for this.

I think I recall a long discussion about this quite some time ago.
IIRC, as we got into it the roles got confusing and we sidestepped the 
effort of figuring it out. I *think* some of the issues were:
- in call centers the desired distinction is customer/vendor, not
   caller/callee. Sometimes the caller is the customer, sometimes the
   callee is.
- in the case of multiparty calls it gets hard to know who is caller
   and who is callee.

I can imagine that some work could be done to define some useful 
attributes here. But it will take work.

	Thanks,
	Paul

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 16 Dec 2014 06:42:46 +0000

+1 to Paul¹s comments. The main reason we did not include this in the
standard metadata was after several discussions we figured out it is not
always possible to determine the caller/callee properly. So it was decided
that this best conveyed as extension data to participant XML element.

Ram

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Monday, 15 December 2014 10:08 pm
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] CS caller and callee in metadata

>> http://tools.ietf.org/html/draft-ietf-siprec-metadata-16#section-6.5.1
>>states that the roles of participants, which I assume could include
>>calling/called party, are not specified here and would be the subject of
>>some extension data.
>>