Subject: [siprec] Initial protocol draft

From: Leon Portman <[email-masked]>
Date: Mon, 13 Dec 2010 13:16:36 +0200

Hello, 

Please review the initial attempt to put together some protocol flows. 

Regards

Leon

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 13 Dec 2010 20:12:02 +0530

Leon,

I skimmed through the draft. My comments/queries are as follows:

1) Please add the callflow with UA+SRC as the first diagram before fig 3
with SRC as B2BUA.

2) In Fig 3, INFO is proposed as a method for metadata updation. IMO, it
shall be done using Re-INVITE because SDP metadata portion may be
required to be updated.  

3) Moreover, Fig 3 and Sec 4 (SIP extensions) textual details are not in
sync. Please show Re-INVITE in the callflow

4) Fig 6, RE-INVITE is triggered from SRS. Whether this callflow address
any specific requirement in SIPREC?

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Monday, December 13, 2010 4:47 PM
To: [email-masked]
Subject: [siprec] Initial protocol draft

Hello, 

Regards

Leon

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 13 Dec 2010 21:04:02 +0530

Leon,

I skimmed through the draft.

Here are some of my initial comments. 

Architecture draft has three different architectures (based on location
of SRC). I see this draft addressing only the second one where SRC is a
middle box (B2BUA). Is your thought that the others will be taken care
by other drafts ?

In figure 3 you have mentioned call ID in the RS INVITE. Which call ID
is it ? 

INFO may be one mechanism to carry additional metadata, however as
Partha mentioned RE-INVITE/UPDATE with SDP could be more appropriate
many times.
I think we need more clarity on what data is being carried here before
we decide on the message in which it has to be carried.

This text needs to be edited. You have mentioned SRS in place of SRC and
vice-versa at some places

<snip>
When SRC sends INVITE to SRC, SRS might respond with a=inactive
   attribute as part of the SDP in the 200 OK response.  A re-INVITE
   will be sent in order to update the SRC with the updated SDP.

   As SRS only receives RTP streams from SRS, the 200 OK response will
   contain SDP with a=recvonly attribute.
</snip>

Figure 3 and the text in Section 5 needs to be aligned. 

Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman

---

From: Leon Portman <[email-masked]>
Date: Mon, 13 Dec 2010 17:47:21 +0200

Partha, Hi

Thank you very much for the comments

Please see below

Regards

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: Monday, December 13, 2010 4:42 PM
To: Leon Portman; [email-masked]
Subject: RE: [siprec] Initial protocol draft

Leon,

[Leon] Yes, I will. I also want to add conferencing example as well

[Leon] Yes, we have 3 options here: re-INVITE (may be heavy on processing), INFO or Subscribe/Notify. Probably for reporting new CS inside RS, the best option is Re-invite, but for lightweight reporting mid-call events, INFO can be more appropriate. This probably will be covered by Metadata reporting protocol draft.

[Leon] Yes, I will

[Leon] It is for REQ-03 (The mechanism MUST support the ability to record selected
   parts of selected CSs) and REQ-015 (The mechanism MUST support the ability to pause and resume
   the transmission and collection of RS media). It is one of the way how SRS can control when to receive the media. 
   We should also demonstrate it in other direction (SRC->SRS)

Thanks
Partha

-----Original Message-----

Hello, 

Regards

Leon

---

From: Leon Portman <[email-masked]>
Date: Mon, 13 Dec 2010 17:50:32 +0200

Hi, Ram

Please see below

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Monday, December 13, 2010 5:34 PM
To: Leon Portman; [email-masked]
Subject: RE: [siprec] Initial protocol draft

Leon,

[Leon] No, we should present all configuration. I am not sure yet that the protocol flows will be different

[Leon] It should be the same that we will define in Metadata. Probably we also need both CS Group and CS IDs.

[Leon] I completely agree

<snip>

[Leon] Actually I did meant it as it is presented. It is a flow, where SRS can pause recording

Ram

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 14 Dec 2010 10:42:05 +0530

Leon,

Thanks for the clarification. Please read inline comments.

Thanks
Partha 

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Monday, December 13, 2010 9:17 PM
To: Parthasarathi R (partr); [email-masked]
Subject: RE: [siprec] Initial protocol draft

Partha, Hi

Please see below

Regards

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Monday, December 13, 2010 4:42 PM
To: Leon Portman; [email-masked]
Subject: RE: [siprec] Initial protocol draft

Leon,

[Leon] Yes, we have 3 options here: re-INVITE (may be heavy on
processing), INFO or Subscribe/Notify. Probably for reporting new CS
inside RS, the best option is Re-invite, but for lightweight reporting
mid-call events, INFO can be more appropriate. This probably will be
covered by Metadata reporting protocol draft.

<Partha> Ram, Paul and myself will come up metadata format after getting
more consensus for  metadata model in the coming interim meeting this
week. I suppose that it will provide more clarity in the delivery
mechanism which has to be chosen to update metadata in the mid-dialog
scenario. </Partha>

[Leon] Yes, I will

[Leon] It is for REQ-03 (The mechanism MUST support the ability to
record selected
   parts of selected CSs) and REQ-015 (The mechanism MUST support the
ability to pause and resume
   the transmission and collection of RS media). It is one of the way
how SRS can control when to receive the media. 
   We should also demonstrate it in other direction (SRC->SRS)

Thanks
Partha

-----Original Message-----

Hello, 

Regards

Leon

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 13 Dec 2010 22:00:25 -0800

Hello,

I took Leon's document and added more text to explain the overall
operations and extensions. I also tried to address the questions in the
mailing list today.

Regards,
Henry

> Sent: Monday, December 13, 2010 6:17 AM
> To: [email-masked]

-------------------------------------------------------------------------------------------------------------------
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: Peter Musgrave <[email-masked]>
Date: Tue, 14 Dec 2010 09:12:55 -0500

Hi Henry/Leon, 

I like the draft. Most of it makes good sense to me.

Is there a need for a field in a Supported: header to indicate a node is siprec capable?

e.g. in the MCU example how did the UA know it was ok to send a REFER to start a recording?

In this particular case, I think the use of a dialog-creating REFER is worth discussing. This could also presumably be done with an INFO or a NOTIFY mechanism as well. These might be a bit lighter weight - since the implicit REFER subscription results in some extra messages...

Regards,

Peter Musgrave

On 2010-12-14, at 1:00 AM, Henry Lum wrote:

> <draft-portman-siprec-protocol-00-v2.txt>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Dec 2010 09:51:37 -0500

Henry,

I think we are making good progress here.

> operations and extensions. I also tried to address the questions in the

A few thoughts...

Regarding referring a focus to the SRS: that might make sense, but for 
the focus to act as SRC it needs some way to discover that is what it 
should do. Either it needs to be told in the REFER, or it needs to 
figure it out based on the response to the INVITE. It should be possible 
to figure it out based on callee caps in the Contact of the response, 
but by then it is a little late, because the streams offered were not 
set up right for recording. It could reinvite and fix them I guess. It 
might be easier to REFER the SRS to the focus. Then the INVITE would be 
"special" and allow the focus to figure out what is going on. (Probably 
an INVITE without an offer but with caller caps indicating it is an SRS. 
A siprec-aware focus would then offer the right stuff. An unaware one 
would simply treat the SRS as an ordinary caller, which would still 
allow recording with more limited metadata.)

IIUC you have included all the potential mechanisms for passing metadata 
that have been discussed. That is probably reasonable at this point, and 
will be winnowed down later.

Re the subscribe mechanism - it seems awkward that the SRS needs to know 
about the SRC in order to subscribe, while the SRC needs to know about 
the SRS in order to send RS INVITEs. Seems like one side should lead, 
and the other should follow. If the SRS was the leader, then I could see 
it subscribing, and then sending an INVITE/Join or something to that 
effect when it heard via notify of a call it wanted to record. But we 
have been concentrating on the SRC leading, and it that case it makes 
more sense for the metadata to be pushed in the RS.

SDP Handling: a=inactive can be offered or answered by either SRC or 
SRS. While I see nothing technically wrong with Figure 9, it seems an 
unlikely use case. Why would the SRC ever send an offerless INVITE to 
the SRS??? ISTM that the SRC will send a reINVITE with a=inactive if it 
wants to pause recording. SRS will send reINVITE with a=inactive if it 
needs to pause recording (but what is case for that?) SRC will answer 
with a=inactive if it thinks it should be paused when it receives offer 
from SRS. SRS will answer with a=inactive if it thinks it needs to be 
paused when it receives an offer from SRC.

	Thanks,
	Paul

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

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 14 Dec 2010 07:35:23 -0800

Please see inline.

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 9:13 AM
> To: Henry Lum
> Cc: [email-masked]
> Subject: Re: [siprec] Initial protocol draft
> 
> Hi Henry/Leon,
> 

[[hlum]] Currently there isn't any new header we are defining for the
RS, the only thing special about this session is that it is using the
media tag mechanism in the other proposal by Alan Johnston. Since there
isn't any special handling of the headers I hope we don't need to use a
new Supported parameter.

> e.g. in the MCU example how did the UA know it was ok to send a REFER

[[hlum]] Perhaps we would need a URI parameter to qualify that the URI
is for recording (ie. sip:[email-masked];record)? If the MCU
supports recording then it can accept the URI to send the INVITE to the
SRS.

> 
> In this particular case, I think the use of a dialog-creating REFER is
> worth discussing. This could also presumably be done with an INFO or a
> NOTIFY mechanism as well. These might be a bit lighter weight - since
> the implicit REFER subscription results in some extra messages...
> 
[[hlum]] It does add a bit of messages, but then we don't have to add
new extensions to the conference packages to add recording. Using REFER
is a lot of simpler for the UA given that the UA knows the SRS URI which
could be a problem itself.

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 14 Dec 2010 07:49:36 -0800

Please see inline.

> Behalf Of Paul Kyzivat
> Sent: Tuesday, December 14, 2010 9:52 AM
> To: [email-masked]
[[hlum]] I thought having SRS to INVITE SRC is currently out of scope.
That's exactly the set of problems we need to deal with when the SRS
needs to discover what media streams it expects to receive. It would be
much easier for the SRC to offer the recorded streams. 

> allow recording with more limited metadata.)

[[hlum]] I commented on the other response that the focus may have to
told to REFER to a SRS URI by qualifying it with a URI parameter. If the
focus is recording aware then it can act as the SRC and provide all the
necessary SIPREC protocol extensions. If focus is not recording aware
then it's fine as well; the SRS can still accept it even though the SRS
is not going to get proper metadata.

> will be winnowed down later.

[[hlum]] Yes, that's the intention to show all potential mechanism until
we agree on a single one which I prefer.

> more sense for the metadata to be pushed in the RS.
 
[[hlum]] I have a use case where the SRC is pushing only metadata events
and no recorded media, and that's why I think SUBSCRIBE mechanism could
work well. Perhaps the SRC should just PUBLISH and push metadata to the
SRS rather creating the subscription, whereby eliminating this SRS
leading role?

> paused when it receives an offer from SRC.
[[hlum]] I'll let Leon address this since I don't have a use case for
this as well.

> >> Please review the initial attempt to put together some protocol
---------------------------------------------------------------------
> ----------------------------------------------
> > 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: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Dec 2010 12:02:27 -0500

More inline.

	Thanks,
	Paul

> much easier for the SRC to offer the recorded streams.

Yes, we decided having SRS invite SRC was out of scope.
But having SRS accept a REFER and thus send an invite to SRC is a bit 
different, since the SRS isn't making the decision of what to invite. 
That was suggested by Brian, and we put it off.

ISTM that if that is out of scope, then sending a REFER to focus and 
expecting the focus to act as an SRC is perhaps out of scope. If 
possible it would be nice to avoid having to invent a way to tell the 
refer-ee that we want it to act as an SRC, because I think that is 
complex. But I'm ok with the refer being normal and then the focus 
possibly *discovering* that it is talking to an SRS and thus altering 
its behavior.

> work well.

That seems to be something entirely different from what we have been 
discussing to date. Is it in scope?

It might be that there is a distinct mechanism for this distinct purpose.

> Perhaps the SRC should just PUBLISH and push metadata to the

Use of PUBLISH for various purposes is discussed from time to time. But 
it won't fly unless it is associated with a real event package that 
somebody might subscribe to.

---

From: Leon Portman <[email-masked]>
Date: Wed, 15 Dec 2010 06:43:14 +0200

Hello, 

It is indeed very interesting discussion.

I want to provide example when SRS will send SDP with a=inactive. 

First and most basic example is when SRS detects either from agent desktop or from the audio of the call that customer is going to provide credit card information or personal health data. In such case, the current best practice is to pause recording. We had discussion before that for some architectures SRC will know that but usually this is decided by SRS. 

The second use case is where only part of the call should be recorded ad again decision (policy server) is on SRS side.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, December 14, 2010 7:02 PM
To: Henry Lum
Cc: [email-masked]
Subject: Re: [siprec] Initial protocol draft

More inline.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Dec 2010 00:06:33 -0500

> The second use case is where only part of the call should be recorded ad again decision (policy server) is on SRS side.

OK, that is interesting. Its surprising to me that the agent desktop 
would be talking to the SRS, but if it does, then so be it. Technically 
its fine for either end to pause the recording.

Another question that came up:

Is there reason to distinguish in the metadata between a call that isn't 
being recorded because the CS is on hold, and one that isn't being 
recorded because the SRC or SRS paused it? And do we care who did the 
pausing? (Maybe its all the same with an id of the pauser, who could be 
any of the participants or the SRC or SRS.)

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 15 Dec 2010 13:21:40 +0200

Paul, Hi

I don't think that we should distinguish between metadata for  CS with paused RS. Regarding info about the pauser  and times: yes, this information is very important and captured today by the recording systems. So if SRC is the pauser, it should report it via metadata to SRS.

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 7:07 AM
To: Leon Portman
Cc: Henry Lum; [email-masked]
Subject: Re: [siprec] Initial protocol draft

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 15 Dec 2010 13:06:33 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 15 December 2010 05:07
> To: Leon Portman
> Cc: [email-masked]; Henry Lum
> > First and most basic example is when SRS detects either 
> from agent desktop or from the audio of the call that 
> customer is going to provide credit card information or 
> personal health data. In such case, the current best practice 
> is to pause recording. We had discussion before that for some 
> architectures SRC will know that but usually this is decided by SRS.
[JRE] If the SRS knows that recording is to be paused, it can do so locally without necessarily interrupting the flow of media from the SRC to the SRS. In cases such as entering a credit card PIN, the duration is relatively short, so in terms of wasted bandwidth it is probably not significant. In terms of security, if the RS media are protected by SRTP, fine. If not, there is a vulnerability anyway, e.g., if the pause mechanism is slow to respond or the agent doesn't trigger it in time. Finally, if media is paused, how does the SRS know when to resume?

John (as individual)

> >
> > The second use case is where only part of the call should 
> be recorded ad again decision (policy server) is on SRS side.
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> >>>> operations and extensions. I also tried to address the 
> questions in
> >>> the
> >>>> mailing list today.
> >>>
> >>> A few thoughts...
> >>>
> >>> might be easier to REFER the SRS to the focus. Then the 
> INVITE would
> >> be
> >>> an INVITE without an offer but with caller caps 
> indicating it is an
> >>> SRS.
> >>> that have been discussed. That is probably reasonable at 
> this point,
> >>> and
> >>> Re the subscribe mechanism - it seems awkward that the 
> SRS needs to
> >>> know
> >>> and the other should follow. If the SRS was the leader, 
> then I could
> >>> see
> >>> the SRS??? ISTM that the SRC will send a reINVITE with 
> a=inactive if
> >> it
> --------------------------------------------------------------
> -----------------------------------------------------
> >> 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: Leon Portman <[email-masked]>
Date: Wed, 15 Dec 2010 14:26:49 +0200

John, Hi

PCI or privacy regulations require that sensitive information is not shared with any person/system that is not required to use such information.
And SRTP support is optional for RS. So discarding such information on SRS side will be problematic.

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 2:07 PM
To: Paul Kyzivat; Leon Portman
Cc: [email-masked]; Henry Lum
Subject: RE: [siprec] Initial protocol draft

John (as individual)

> [mailto:[email-masked]] On
> >>>>> Behalf Of Leon Portman
> person, use

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 15 Dec 2010 15:57:21 +0100

> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 14 December 2010 15:50
> To: Paul Kyzivat; [email-masked]
[JRE] I am not yet convinced of this REFER use case. First of all, do any requirements or use cases in siprec-req lead to this? Assuming there is a requirement, how does the UA know that the conference focus is one that is appropriate to use as an SRC? For example, If I am in a conference call and want it recorded by my Siemens SRS, it is no good asking an Alcatel-Lucent conference focus to act as SRC - it probably wouldn't be authorised to use the Siemens SRS. So the UA would somehow need to know that the contact URI it obtains for the conference focus is one that is likely to be able to use the SRS of the UA's choosing. Moreover, if the conference focus is to act as SRC, I believe it needs to support the SIPREC protocol, because it needs to supply metadata to the SRS.

Isn't this a more general problem of getting an entity on the call path that is able to act as SRC (whether or not it be a conference focus) to do so? For example, an SBC? I can imagine out-of-band means would be good enough for most purposes, e.g., a check box on a conference server's web page. I am not yet convinced we need to solve this in SIP.

John (as individual)

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 15 Dec 2010 08:07:53 -0800

I thought pause/resume is handled by whichever side (SRC or SRS) by
initiating a=inactive; there is no need to send an offerless INVITE to
the other side which is Paul's question in the first place?

Henry

> Sent: Wednesday, December 15, 2010 7:27 AM
> To: Elwell, John; Paul Kyzivat
> PCI or privacy regulations require that sensitive information is not
> shared with any person/system that is not required to use such
> information.
> [JRE] If the SRS knows that recording is to be paused, it can do so
> locally without necessarily interrupting the flow of media from the
SRC
> to the SRS. In cases such as entering a credit card PIN, the duration
> is relatively short, so in terms of wasted bandwidth it is probably
not
> significant. In terms of security, if the RS media are protected by
> SRTP, fine. If not, there is a vulnerability anyway, e.g., if the
pause
> mechanism is slow to respond or the agent doesn't trigger it in time.
> Finally, if media is paused, how does the SRS know when to resume?
> 
> John (as individual)
> 
> > >
> > >>> with a=inactive if it thinks it should be paused when it
receives
> > >> offer
> > >>>>> Please review the initial attempt to put together some
protocol
> > >>> flows.