Subject: [siprec] Raw Minutes from SIPREC

From: Peter Musgrave <[email-masked]>
Date: Wed, 10 Nov 2010 14:57:44 +0800

SIPREC WG Wed 1pm Beijing

Requirements - near to finishing.

Meta-data is now a draft.

Ken Rehor is not available. Paul K to present:
(slides for req-04)
- pause resume working has taken some work. Side shows proposed wording
John: Is this on the list?
Paul: It's been in email
John: Any concerns in the room ? (none)

REQ-50 Authorization
- not entirely worked out yet
- SRS->SRC is more controversial
Paul: Is that out of scope
John: Yes, session initiated with SRC. 
Eric: Should SRS be allowed to do this? (no response from room)
John: If SRS receives request, Auth is internal matter for SRS. 
John: You are asking the floor that this is a non-requirment that it's a policy decision
Cullen: I am confused…hard to hear…
John: Only SRC can restate. Is there a requirement for SRS to ensure that only authorized SRCs? (Or is this a policy on SRS and we do not need a specific requirement)
John: There is no objection to removing this requirement. 

Slide:Privacy
- this becomes a big issue. In geopriv this became a lot of work
- proposal to define this as out of scope
John: Lots of off-line discussion with people think there is something which is simpler can be done. Included expert feedback from Alister. 
Probably have to discuss on list. 
Allysa: Agree with the conclusion not to go down the geopriv road….
Paul: Privacy will need more work
Privacy:Indicate Recording Reason
Allysa: My suggestion and standardizing a list of purpose is not the same thing. REQ is only that it must BE specified. A standardized list of purpose is not a good idea.
Paul: Are you suggesting need need to be dynamic?
John: Explanation. In the real world e.g. customer calling contact centre, customer hears recorded announce - don't need to standardize that. Agent gets notified as part of employment contract. Do we want to put this in requirements somehow. OTOH have discussed explicit requirements about audio announce which could be intercepted by machine, translated etc. SO should a machine readable purpose be provided. 
Allysa: Not sure if dynamic question got answered. Purpose could be given at the same time…
John: Not the issue, if we have signallnig saying purpose as well as fact that recording is provided - does this make a rat hole for how to specify the purpose….
Allysa: Going to solution - can just have purpose as a requirement. Don't need imp. details. 
John: What goes on the wire? Does the Rec header need to indicate the purpose.
Allysa: Sure, but content does not need to be restricted - could be free form
Eric: BTW if you do this you need to get into language tags etc. 
Ken: ?
Henry: Is this like Reason free form text
Dale: I assume recording announce means the recording could be used by company for any purpose - how would you ever know. (not sure if there are legal issues)
John: Depnds on jurisdiction. How enforceable? In UK reasonable enforceable by law, could not e.g. give to third party
John: Is there need for purpose as a requirement?
Hadriel: Are you guys nuts? This should be in media. Are you going to replace all the UAs? PSTN has always done this in media.
John: So this requirement is not needed…
Allysa: Agreed. 
(consensus is to nuke this)

Cullen: Can we be clear about REQ-50? (some stuff I missed)
John: A sperate req. on Auth 
Paul: Cullen's question is about SRS->SRC, not in scope. It will do so according to it's policies.

Slide: Request to clarify scope: Is SIPREC only to be used when participants informed. 
Allysa: There is a lack of clarity. Is the req it needs to be there but does not have to be used -
Paul: There is a requirement it be possible but not that it be used. Use may vary by location. 
John: Could say in solutions ..
Allysa: So then how is LI out of scope? You are building something which records without notification. 
Allysa: We need MUST in caps. 
Hadriel: Can't really ask people to set the not-Evil bit in solution. 
Cullen: If notification is not used then this is wiretap. 
Ken: Agencies that want to record secretly will just not obey the protocol…
John: We can put in MUST but people will ignore it if they want to.
Paul: In cases where recording is on a sampling basis (call-center) would there be the same req?
Ben C: We are using protocol to solve matter of law. This is something we can't do.
John: Agreed. Solution MUST might even exceed local legislation. 
(more discussion about enforceability and use of MUST)
Allysa: Seems belongs in solutions, not REQs
Eric: Need to allow protocol to let people do the right thing. I think we should say MUST in solution doc, let the bad guys be bad.
Ben: Many states have one-party rule. DO we say our rules are stricter. 
John: Summary: We're ok with REQ wording, intend to make MUST in solutions doc. 
Allysa: Has to be there if LI is to be out of scope. 
John: Ok we'll look for better wording on the list. 
Cullen: Charter requires notification.
Paul: Why is not a requirement - how can we be sure it goes in solution?
Hadriel: Will this be in signalling? Media? Won't possible work in signalling
John: Yes
Paul: I'm not sure I agree.
Hadriel: One EP may be PSTN - this has to go in media. PSTN will not carry it in signalling.
John: Yes - we need more words here. 
Paul: Hinges on what notification means? What constitutes it?
John: Let's continue on the list…

Slide: Confidentiality etc.
- still open - need more work
Ken: very generic security has been expanded into new sections

Recording:
Charles Ekyl: Media from many participants, server gives each participant different audio based on loudest speakers. How does a recorder have a view of the total and each participants reqs?
Paul: Two points of view. We could record a view as a participant in the con. Or it could be special, i.e. SRC be the focus and have a special relationship and record in a different way.  (Maybe Brian said SRS would connect directly). Though was this a more complex beast and should be out of scope. 
John: Thought this was SRC at focus (i.e. central view), or could be at each party and get party centric. Both are valid things to do. 
John: This may impact meta-data, but not clear what the specific req is. 
Brian: Might want meta-data from entity which request con. focus requirement?
John: Need more concrete proposal if people think a requirement is needed. 

Media Delays:
Paul: Not sufficient if SRC buffer whole call and sent to SRS at the end, but recorder may not get the thing instantly….so is there a specific requirement?
Eric: Is this not purely implementation? Real time analytis would do a better job, and in two years it will be faster etc.
James: So at a high level would not want this to be UDP - since you might not want to lose packets. 
John: Could put this in a "desired" section for SHOULDs….we want this in seconds not days….
Leon(?): Could be transcoding etc. May need to report the delay to ensure correct playback. RTP does not carry e.g. wall clock time. 
Paul: There is a different requirement about when media was generated. 
John: Can someone propose a wall clock time REQ?
John: Some people want to listen to something (with a time lag) while still being recorded…
John: Is anyone keen to have a REQ - or it can wait for solution?
(no response)
John: There is a requirement for wall clock time.

Next Steps:
- plan for -05, need more discussion on privacy, notification and security
- would like to see discussion in the next few days and capture in another rev. 
Paul: Privacy issues seem murky

METADATA MODEL
- ram-metadata-01
John: RS figures in model only because this the way the data is delivered
Andrew: So reason should not be an attribute of the RS
John: Not clear we do need this at all, but if we do purpose might change - but seems like we do not need to consider
Paul: Which discussion? Maybe - might not be the same thing here. 
Paul: This is here because people on list kept saying they still wanted this. 
John: Do you have examples of values? Unless someone comes forward with some then take this out.
(agreement)

CSG
John: This came from cases where sessions on-hold or in call transfer were linked in cases where they come through different SRCs.
Ram: Do we need application data? 
Paul: Some discussion on list about other ways to model relationships between CSs or make CSG optional…most are superficial differences. This seems to do the job. 
John: Let's seek input on list

CS
Paul: Participants used to be hooked to media - so we changed to this link of Participant to CS. Here we relate it to the signalling. There are other ways…
John: So e.g. if I get your name from conf-event are you a participant by signalling?
Paul: No sure - I think not. 
Ram: Agreed. 
John: Need better articulation on list to understand implications. 
John: Why would a participant be allowed to be involved in zero CS?
Ram: Zero is for when part. is not contributing to signalling…
John: Asking about more than one..
Ram: Transfer case….
John: Direction/initiator attributes for CS or participant
Paul: Initiator is a relationship…
Ram: What other attributes do we need? App data??
(silence)
John: So answer is no…
Paul: I don't believe that. Implicit assumption is stuff will come out of the wood-work.

Participant:
PeterM: Do we want Contact/GRUU so we know which exact UA was involved. 
Paul: Sounds reasonable. We are likely missing lots of stuff. 
Leon: Lots of stuff we need to add. Privacy stuff etc. MAC, IP, multi-line etc. 
Paul: Can you send text?
Leon: Ok
Paul: Earlier models did not show receiving relationship. That's new. Mixing policies are also not in the data model here. Could get very complicated…
John: It's a case of where do we stop…
Leon: e.g. do we want to calculate volume etc. or record that a person turned down their volume

Media Stream
PeterM: 
PeterM: how do I know if sent media streams are left and right??
Eric: What are units for start/end. We did agree we needed to record wall time. Maybe this is the place. 
Paul: We need help from people who understand media to indicate what we need here. 
Charles: In terms of video will need something about what granularity you can search to…you need an I-frame frequency or a list of where I frames are.
Paul: PLease those of you who know send text. 
Peter: Rat hole about video retransmission
Paul: Assumes xmit to SRS is lossy.
Ram: Do we need to model information which did not get recorded (i.e. that video was declined)
Leon: Yes. May be cases where we want to know video was an option. 
Leon: Can just reflect what the communication session offered…
John: Supose you offer to rec audio+video and only audio is accepted does SRS need to know if video is paused?
Leon: Yes, I think so. e.g. Might want to know that there was a video stream so if e.g. part of audio goes silent you might infer visual information was being exchanged.
Ram: SHould privacy stuff go here

App Data:
Can be attached to anything. Hearing people want other stuff which could fit in here. e.g. Location data

John: Some similarity between this and an ecru question on additional data. 

Ram: Delivery mechanism should be a seperate draft. Might be more than one. 

John: We need input from more areas before we can adopt this. Do not currently have this as a milestone - but will ask ADs. 
Let's try and get more input on the list

Sohal: When you do rec? Audio & video? Yes. So need much more information….

Gonzalo: As long as its in charter text, then changing Milestones is ok. Go ahead with that.

John: Let's try to do interim in mid-Dec. Try and have docs revved by then. 

Hadriel: Recommend a physical face to face meeting....
John: I can ask - but may be hard to get people together.