Subject: Re: [siprec] CS caller and callee in metadata

From: "Emil Andonov" <[email-masked]>
Date: Tue, 3 Feb 2015 08:03:56 +1100

Thank  you all for clarifying.

I still think that it will be very useful to extend the Participant element
and add a parameter which tells if they made the call (dialled) or received
the call - from a SIP session perspective. Recorders can use this
information with configuration data to make decisions on what to store in
the recording meta data DB.

It is always possible to determine the party, or parties,  that initiated
and received a call in a SIP session, so it is not too difficult ask the SRC
to add this information in the Participant element from the From and To
headers even if the RS is for multiple CSes.

Note that I am suggesting to add basic information about each Participant
from the CS SIP messages. It is not necessary to complicate things by making
decisions on customer/vendor, agent/customer etc. at the SRC. The SRS can
make this decision, if required, from configuration but it still needs the
extra parameter that I am suggesting to classify calls (from, to, incoming,
outgoing ...) properly. 

Emil

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Ram Mohan R
(rmohanr)
Sent: Tuesday, 16 December 2014 5:43 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] CS caller and callee in metadata

+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

>On 12/15/14 11:03 AM, Hutton, Andrew wrote:
>> 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.
>
>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
>
>> 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
>>
>> _______________________________________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
>_______________________________________________
>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: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Feb 2015 17:16:16 -0500

Emil,

You think this is simple. The authors have explained that it was 
considered and found to not be so simple. At this time I'm not in favor 
of opening that for discussion again. If you want to do so, then you 
will have to get consensus to do so, and propose the new text to cover it.

	Thanks,
	Paul