Subject: [siprec] Progressing the architecture document

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Mar 2011 17:55:45 +0100

draft-ietf-siprec-architecture has not moved forward much in recent months, waiting for progress on solutions to help confirm the architecture. Now would be an excellent time for people to raise any issues that can perhaps be addressed by the editor before the cut-off (2011-03-14) or discussed in Prague.

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 14 Mar 2011 22:34:32 +0530

SIPREC Architecture-01 draft looks good in the high level. Some of the minor comments are as follows:
 
Sec 4.1.4 Fig 3 indicates about SRS having AS & MS, it may be preferred to indicate that SRC also has AS & MS clubbed together. IMO, this provide more clarity while reading.
 
Sec 4.1.5 Figure shall be added to indicate a scenarion whererin focus acts as SRC.
 
Sec 4.2 Para 2 example does not go inline with REQ-024 of -07 Requirement draft. The example shall change from "client must decrypt" to "client may decrypt".  
 
Sec 4.2.1 Fourth bullet text may be preferred to change as "Indicate support for the recording metadata"
 
Sec 4.2.3 change "sendonly" or "recvonly" to "recvonly" or "sendonly as it is indicated as SRS and SRC in the beginning of the line.
 
Sec 4.3.1 1st bullet shall be changed from "Dialog identifier" to "Communication Session Identifier"
 
Sec 4.3.1 whether 3rd bullet is required? 
 
General comment: it is preferred to change to "should, must" to "SHOULD, MUST" as per RFC 2119 
 
Sec 4.3.2 1st bullet has to be removed as it is not required any more.
 
Sec 4.3.2 3rd bullet has to be changed to indicate XML package instead of Event package
 
Sec 4.3.2 last bullet: is it required to pass metadata using non-sip mechanism?

Thanks
Partha

________________________________

From: [email-masked] on behalf of Elwell, John
Sent: Wed 3/2/2011 10:25 PM
To: [email-masked]
Subject: [siprec] Progressing the architecture document

John

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 14 Mar 2011 23:32:53 +0530

Here are some of my comments on draft-ietf-siprec-architecture. 

Section 2(Definitions)- The definitions of SRS, SRC, RS, CS is different
in Requirement (ver 08) and Architecture drafts. Please update the
Architecture draft to reflect the same as Requirement or better remove
from architecture as we already have reference to Requirement doc here.
Only additional definitions not present in Requirement but used in
Architecture draft can be included here.

Section 2(Definitions)- The definition of Recording aware UA needs to be
edited as it does not seem to meet REQ-16, 17 and 19

Section 2(Definitions)- Requirement draft already has a definition for
Metadata. Do we need this MRM(Media recording Metadata) ?

Section 4.1.5 - If possible please add a figure here showing the
architecture where SRC is Focus.

Section 4.2 - Paragraph 2 needs to be edited to make it sync with REQ-24
of requirement draft

Section 4.2.4 - There is a typo on the 5th line "recoding server".

Section 4.3.1 - Do we need this section with all the points now ? Since
we have separate draft(s), would it be better to just have a few lines
and then reference this draft. Note, I am not sure if its right to
reference a draft (for the reason Leon mentioned on Circular references)

Section 4.4 - First line here may need change as we have concluded on
other means of notifying recording (like visual indications e.t.c)

Regards,
Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Wednesday, March 02, 2011 10:26 PM
> To: [email-masked]
> draft-ietf-siprec-architecture has not moved forward much in recent
> months, waiting for progress on solutions to help confirm the
> architecture. Now would be an excellent time for people to raise any
> issues that can perhaps be addressed by the editor before the cut-off
> (2011-03-14) or discussed in Prague.
> 
> John
>

---

From: Leon Portman <[email-masked]>
Date: Tue, 15 Mar 2011 09:18:00 +0200

Partha Hi

Thank you very much for the comments. I will start working on the revised version

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Monday, March 14, 2011 7:05 PM
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Progressing the architecture document

John

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

---

From: Leon Portman <[email-masked]>
Date: Tue, 15 Mar 2011 09:19:40 +0200

Ram 

Thanks. We will publish update version

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Monday, March 14, 2011 8:03 PM
To: Elwell, John; [email-masked]; Leon Portman; Hutton, Andrew; Ken Rehor (krehor)
Subject: RE: [siprec] Progressing the architecture document

Section 2(Definitions)- The definitions of SRS, SRC, RS, CS is different in Requirement (ver 08) and Architecture drafts. Please update the Architecture draft to reflect the same as Requirement or better remove from architecture as we already have reference to Requirement doc here.
Only additional definitions not present in Requirement but used in Architecture draft can be included here.

Section 2(Definitions)- The definition of Recording aware UA needs to be edited as it does not seem to meet REQ-16, 17 and 19

Section 2(Definitions)- Requirement draft already has a definition for Metadata. Do we need this MRM(Media recording Metadata) ?

Section 4.1.5 - If possible please add a figure here showing the architecture where SRC is Focus.

Section 4.2 - Paragraph 2 needs to be edited to make it sync with REQ-24 of requirement draft

Section 4.3.1 - Do we need this section with all the points now ? Since we have separate draft(s), would it be better to just have a few lines and then reference this draft. Note, I am not sure if its right to reference a draft (for the reason Leon mentioned on Circular references)

Section 4.4 - First line here may need change as we have concluded on other means of notifying recording (like visual indications e.t.c)

Regards,
Ram

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 15 Mar 2011 17:00:25 +0100

Hi Partha,

Thanks for your comments.

See below.

Regards
Andy

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 14 March 2011 17:05
> SIPREC Architecture-01 draft looks good in the high level. 
> Some of the minor comments are as follows:
>  
> Sec 4.1.4 Fig 3 indicates about SRS having AS & MS, it may be 
> preferred to indicate that SRC also has AS & MS clubbed 
> together. IMO, this provide more clarity while reading.

[AndyH] The related text does state that the SRC could also be decomposed in this way and Fig 3. is just one example. I think the figure showing the SRS better illustrates the relation to mediactrl with regard to recording so I prefer the current diagram. Why do you think the showing the SRC in this way would add clarity? I could of course include both but not sure this is really necessary.

> whererin focus acts as SRC.

[AndyH] I will look at creating a diagram.

>  
> Sec 4.2 Para 2 example does not go inline with REQ-024 of -07 
> Requirement draft. The example shall change from "client must 
> decrypt" to "client may decrypt".  

[AndyH] I think I have to remove the whole sentence as the example is no longer valid.

>  
> Sec 4.2.1 Fourth bullet text may be preferred to change as 
> "Indicate support for the recording metadata"

[AndyH] Have we decided whether we have any indication from the SRC that it supports metadata? I did not think so therefore this is an open issue but probably not relevant to the architecture draft. I probably should remove the mechanism related stuff and at some point reference the protocol draft. Do you agree?

>  
> Sec 4.2.3 change "sendonly" or "recvonly" to "recvonly" or 
> "sendonly as it is indicated as SRS and SRC in the beginning 
> of the line.

[AndyH] Done.

>  
> Sec 4.3.1 1st bullet shall be changed from "Dialog 
> identifier" to "Communication Session Identifier"

[AndyH] Note sure about this the current text states "Dialog identifiers for the Communication Session" which seems correct to me. This will probably get removed anyway and replaced to a reference to the metadata model when it is adopted.

> Sec 4.3.1 whether 3rd bullet is required? 

[AndyH]I assume it is as for example I assume it would be necessary to record early-media and update the SRS when the dialog changes to the confirmed or terminated state. Does not seem to be in the metadata draft though. In the end I will either remove these bullets or align with the metadata draft.

> to "SHOULD, MUST" as per RFC 2119 

[AndyH]I think I need to remove all RFC 2119 wording as it is not appropriate to the architecture draft. I will remove all such wording and the reference to RFC 2119. Is that ok ?

> Sec 4.3.2 1st bullet has to be removed as it is not required any more.
[AndyH]OK are there really no information in SIP Headers that could be stored as metadata?

> package instead of Event package

[AndyH] Noted. I will need to review this once we have adopted the protocol draft and make sure it is aligned.

> Sec 4.3.2 last bullet: is it required to pass metadata using 
[AndyH] I will remove this statement if that is ok with everyone.

> draft-ietf-siprec-architecture has not moved forward much in 
> recent months, waiting for progress on solutions to help 
> confirm the architecture. Now would be an excellent time for 
> people to raise any issues that can perhaps be addressed by 
> the editor before the cut-off (2011-03-14) or discussed in Prague.
> 
> John
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 16 Mar 2011 05:40:09 +0530

Hi Andy,
 
Please read inline. 
 
Thanks
Partha

From: Hutton, Andrew [mailto:[email-masked]]
Sent: Tue 3/15/2011 9:30 PM
To: Parthasarathi R (partr)
Cc: Elwell, John; [email-masked]
Subject: RE: Progressing the architecture document

Hi Partha,

See below.

Regards
Andy

<Partha> I know of the call center deployment wherein SRC decomposed as AS and MS. So, I thought that it may help others to understand the arhcitecture from that perspective. </Partha> 

<Partha> Agreed </Partha>

[AndyH] Done.

[AndyH]I assume it is as for example I assume it would be necessary to record early-media and update the SRS when the dialog changes to the confirmed or terminated state. Does not seem to be in the metadata draft though. In the end I will either remove these bullets or align with the metadata draft.
<Partha> It is a good point. Dialog state shall be added as one of the optional attribute in CS metadata block with default value as mid-dialog. This helps to differentiate between early dialog (ringback) vs mid-dialog (normal conversation) in recording. In case of no objection for this attribute in metadata model, we will add it. We will work out metadata format once the consensus occurs for metadata model. In case required, we will span separate mail thread to close this issue </Partha>

<Partha> It is fine </Partha>

<partha> AFAIK, there is no metadata information is passed in RS session SIP header, SIP header have information about SRC & SRS only and few information is possible to be retrieved from SDP which is under discussion in another mail thread with John. In case you foresee any specific SIP header to act as metadata, Please let me know. <Partha>  

<Partha> In case you foresee this requirement, Please start separate mail thread as there are lot of implication in metadata format draft. The current metadata format draft is designed for SIP and not for other protocols </Partha>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Mar 2011 16:47:05 +0100

Hi Ram,

See responses below.

Regards
Andy

> Sent: 14 March 2011 18:03
[AndyH] I would find it strange to not have the definitions of the architectural components in the architecture draft. If everyone agrees I will just make sure they are alligned.

> edited as it does not seem to meet REQ-16, 17 and 19

[AndyH] Would the following be ok?

"Recording aware UA: A SIP User Agent that is aware of SIP extensions associated with the Communication Session. Such extensions may be used to notify the SIP UA that a session is being recorded or to all the SIP UA to express preferences as to whether a recording should be started, paused, resumed or stopped."

> Metadata. Do we need this MRM(Media recording Metadata) ?

[AndyH] Personally I would like to keep it and I prefer to call it "Media Recording Metadata" as this is more explicit rather than just calling it "metadata".

> architecture where SRC is Focus.

[AndyH] OK will try to do this in next update.

> Section 4.2 - Paragraph 2 needs to be edited to make it sync 

[AndyH] OK will do.

> Section 4.2.4 - There is a typo on the 5th line "recoding server".

[AndyH] Thanks

> reference a draft (for the reason Leon mentioned on Circular 

[AndyH] Once the working group had adopted the metadata drafts I will reference those and remove the text.

> other means of notifying recording (like visual indications e.t.c)
[AndyH] I will make some changes to this section I think all we need to do in the arch draft is explain that it is the SRC that is responsible for generating the notifications.

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Mar 2011 17:54:41 +0200

Partha and Andy Hi

I want to address the point regarding indication if SRC supports metadata. I think we need to assume that all SRC supports metadata reporting otherwise SRS will not know what it is actually recording. It is very hard for me to find configuration where SRC will implement SIPREC but not will be able to populate metadata XML.
At least on basic level.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Tuesday, March 15, 2011 6:00 PM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [siprec] Progressing the architecture document

Hi Partha,

See below.

Regards
Andy

> preferred to indicate that SRC also has AS & MS clubbed together. IMO, 
> this provide more clarity while reading.

> Requirement draft. The example shall change from "client must decrypt" 
> to "client may decrypt".

>  
> Sec 4.2.3 change "sendonly" or "recvonly" to "recvonly" or "sendonly 
> as it is indicated as SRS and SRC in the beginning of the line.

[AndyH] Done.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Mar 2011 17:04:42 +0100

Hi Leon,

At the most basic level an SRS may I assume not need any metadata. For example it could be that simply the date and time of the recording is all that is needed for metadata and we don't need XML for that.

The question is whether the SRS needs to be given an explicit indication from the SRC that no metadata will be generated and that probably depends on the mechanism for delivering it.  

Regards
Andy

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 16 March 2011 15:55
> To: Hutton, Andrew; Parthasarathi R (partr)
> Cc: [email-masked]
> I want to address the point regarding indication if SRC 
> supports metadata. I think we need to assume that all SRC 
> supports metadata reporting otherwise SRS will not know what 
> it is actually recording. It is very hard for me to find 
> configuration where SRC will implement SIPREC but not will be 
> able to populate metadata XML.
> At least on basic level.
> 
> Leon
> 
> [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> [AndyH] The related text does state that the SRC could also 
> be decomposed in this way and Fig 3. is just one example. I 
> think the figure showing the SRS better illustrates the 
> relation to mediactrl with regard to recording so I prefer 
> the current diagram. Why do you think the showing the SRC in 
> this way would add clarity? I could of course include both 
> but not sure this is really necessary.
> 
> >  
> > Sec 4.1.5 Figure shall be added to indicate a scenarion 
> whererin focus 
> > acts as SRC.
> 
> [AndyH] Have we decided whether we have any indication from 
> the SRC that it supports metadata? I did not think so 
> therefore this is an open issue but probably not relevant to 
> the architecture draft. I probably should remove the 
> mechanism related stuff and at some point reference the 
> protocol draft. Do you agree?
> 
> >  
> "sendonly 
> [AndyH] Note sure about this the current text states "Dialog 
> identifiers for the Communication Session" which seems 
> correct to me. This will probably get removed anyway and 
> replaced to a reference to the metadata model when it is adopted.
> 
> >  
> [AndyH]I assume it is as for example I assume it would be 
> necessary to record early-media and update the SRS when the 
> dialog changes to the confirmed or terminated state. Does not 
> seem to be in the metadata draft though. In the end I will 
> either remove these bullets or align with the metadata draft.
> 
> 
> [AndyH]I think I need to remove all RFC 2119 wording as it is 
> not appropriate to the architecture draft. I will remove all 
> such wording and the reference to RFC 2119. Is that ok ?
> 
> >  
> > Sec 4.3.2 3rd bullet has to be changed to indicate XML 
> package instead 
> > of Event package
> 
> [AndyH] Noted. I will need to review this once we have 
> adopted the protocol draft and make sure it is aligned.
> 
> >  
> > Sec 4.3.2 last bullet: is it required to pass metadata 
> using non-sip 
> > mechanism?
> >

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Mar 2011 18:08:07 +0200

Andy Hi

Actually participants of the CS are basic info as well and I think that XML is required for it.

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2011 6:05 PM
To: Leon Portman; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Progressing the architecture document

Hi Leon,

Regards
Andy

> I want to address the point regarding indication if SRC supports 
> metadata. I think we need to assume that all SRC supports metadata 
> reporting otherwise SRS will not know what it is actually recording. 
> It is very hard for me to find configuration where SRC will implement 
> SIPREC but not will be able to populate metadata XML.
> At least on basic level.
> 
> Leon
> 
> [AndyH] The related text does state that the SRC could also be 
> decomposed in this way and Fig 3. is just one example. I think the 
> figure showing the SRS better illustrates the relation to mediactrl 
> with regard to recording so I prefer the current diagram. Why do you 
> think the showing the SRC in this way would add clarity? I could of 
> course include both but not sure this is really necessary.
> 
> >  
> [AndyH] Have we decided whether we have any indication from the SRC 
> that it supports metadata? I did not think so therefore this is an 
> open issue but probably not relevant to the architecture draft. I 
> probably should remove the mechanism related stuff and at some point 
> reference the protocol draft. Do you agree?
> 
> >  
> identifiers for the Communication Session" which seems correct to me. 
> This will probably get removed anyway and replaced to a reference to 
> the metadata model when it is adopted.
> 
> >  
> [AndyH]I assume it is as for example I assume it would be necessary to 
> record early-media and update the SRS when the dialog changes to the 
> confirmed or terminated state. Does not seem to be in the metadata 
> draft though. In the end I will either remove these bullets or align 
> with the metadata draft.
> 
> 
> [AndyH]I think I need to remove all RFC 2119 wording as it is not 
> appropriate to the architecture draft. I will remove all such wording 
> and the reference to RFC 2119. Is that ok ?
> 
> >  
> [AndyH] Noted. I will need to review this once we have adopted the 
> protocol draft and make sure it is aligned.
> 
> >

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Mar 2011 17:34:55 +0100

Hi,

In my book that is not so basic.

I don't think we should mandate that the SRC provides metadata within an XML body. I don't see any reason for mandating that even if we think that all SRC's will do so. There is always going to be some implementation for which this is not necessary.

The question then is does it help the SRS to know whether the SRC is capable of sending metadata if for example it asked for a snapshot. I tend to think this would be helpful but it is not a big issue for me.

It might also be helpful if the SRS could tell the SRC that it is not interested in metadata for a given recording session. This might prevent lots of bandwidth being used sending metadata just for the SRS to ignore it.

Just my honest thoughts I look forward to some discussion over a beer in Prague.

Regards
Andy

> Sent: 16 March 2011 16:08
> At the most basic level an SRS may I assume not need any 
> metadata. For example it could be that simply the date and 
> time of the recording is all that is needed for metadata and 
> we don't need XML for that.
> 
> The question is whether the SRS needs to be given an explicit 
> indication from the SRC that no metadata will be generated 
> and that probably depends on the mechanism for delivering it.  
> 
> Regards
> Andy
> 
> 
> 
>  
> 
> > [AndyH] I think I have to remove the whole sentence as the 
> example is 
> > no longer valid.
> > 
> > >  
> correct to me. 
> necessary to 
> > [AndyH]OK are there really no information in SIP Headers 
> that could be 
> > stored as metadata?
> >

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Mar 2011 18:40:08 +0200

+1 for beer

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2011 6:35 PM
To: Leon Portman; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Progressing the architecture document

Hi,

Regards
Andy

> At the most basic level an SRS may I assume not need any metadata. For 
> example it could be that simply the date and time of the recording is 
> all that is needed for metadata and we don't need XML for that.
> 
> indication from the SRC that no metadata will be generated and that 
> probably depends on the mechanism for delivering it.
> 
> Regards
> Andy
> 
> 
> 
>  
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 17 Mar 2011 03:11:05 +0530

Andy/Leon,
 
I'm also interested in Beer discussion at Prague :-) Let us plan for it
 
I understand Andy requirement to pass metadata in the need basis and not mandatory to pass always. IMO, it is reasonable requirement. I guess that option tag like "rs-metadata" between SRC and SRS may serve the purpose. In case rs-metadata is not received from SRS, SRC should not send metadata. Please let me know your opinion here.
 
Thanks
Partha

From: Leon Portman [mailto:[email-masked]]
Sent: Wed 3/16/2011 10:10 PM
To: Hutton, Andrew; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Progressing the architecture document

+1 for beer

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]]
Sent: Wednesday, March 16, 2011 6:35 PM
To: Leon Portman; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Progressing the architecture document

Hi,

Regards
Andy

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 19 Mar 2011 08:22:37 +0530

Hi all,
 
As per current SIPREC architecture document, metadata *MAY* be passed by
non-sip protocol mechanism as well. I'm interested in knowing whether
anybody is interested to pass metadata using non-sip mechanism or
specific requirement for the same.
 
See below mail thread for more details
 
Thanks
Partha

 [snip] 

<Partha> In case you foresee this requirement, Please start separate
mail thread as there are lot of implication in metadata format draft.
The current metadata format draft is designed for SIP and not for other
protocols </Partha>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 19 Mar 2011 17:27:48 -0400

Partha,

AFAIK the point of such a statement is not that we should be specifying 
how to do it, but only not to exclude it from being done via mechanisms 
we have not specified.

	Thanks,
	Paul

On 3/18/2011 10:52 PM, Parthasarathi R (partr) wrote:
> ------------------------------------------------------------------------
> *From:* Hutton, Andrew [mailto:[email-masked]]
> *Sent:* Tue 3/15/2011 9:30 PM
> *To:* Parthasarathi R (partr)
> *Cc:* Elwell, John; [email-masked]
> *Subject:* RE: Progressing the architecture document
> [snip]
>
>  >

---

From: Leon Portman <[email-masked]>
Date: Sun, 20 Mar 2011 23:35:07 +0200

Yes, I think it is important to support out of band metadata reporting (via non SIP such as webservice). If I remember correctly, it was also Henry's opinion.
Of course there should be some correlation identifier such as callId

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, March 19, 2011 11:28 PM
To: [email-masked]
Subject: Re: [siprec] Is it required to pass metadata using non-sip mechanism [was RE: Progressing the architecture document]

Partha,

AFAIK the point of such a statement is not that we should be specifying how to do it, but only not to exclude it from being done via mechanisms we have not specified.

	Thanks,
	Paul

On 3/18/2011 10:52 PM, Parthasarathi R (partr) wrote:
> Hi all,
> As per current SIPREC architecture document, metadata *MAY* be passed 
> by non-sip protocol mechanism as well. I'm interested in knowing 
> whether anybody is interested to pass metadata using non-sip mechanism 
> or specific requirement for the same.
> See below mail thread for more details Thanks Partha
> *Subject:* RE: Progressing the architecture document [snip]
>
>  >
>  > Sec 4.3.2 last bullet: is it required to pass metadata using  > 
> non-sip mechanism?
>  >
> The current metadata format draft is designed for SIP and not for 
> other protocols </Partha>
>
>
>  > Thanks
>  > Partha
>
>
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 21 Mar 2011 07:06:18 +0530

Leon,

I'll split recording metadata into two: SIPREC metadata (attributes
mentioned in draft-ram-siprec-metadata) & Non-SIPREC metadata.
Non-SIPREC metadata may use non-SIP mechanism (like webservice) for
passing metadata and Non-SIPREC metadata handling is outside the scope
of SIPREC.

I'm interested in knowing whether SIPREC metadata has to be passed using
non-SIP mechanism as it is within the scope of SIPREC.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Monday, March 21, 2011 3:05 AM
To: Paul Kyzivat (pkyzivat); [email-masked]
Cc: Henry Lum
Subject: Re: [siprec] Is it required to pass metadata using non-sip
mechanism [was RE: Progressing the architecture document]

Yes, I think it is important to support out of band metadata reporting
(via non SIP such as webservice). If I remember correctly, it was also
Henry's opinion.
Of course there should be some correlation identifier such as callId

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Saturday, March 19, 2011 11:28 PM
To: [email-masked]
Subject: Re: [siprec] Is it required to pass metadata using non-sip
mechanism [was RE: Progressing the architecture document]

Partha,

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 22 Mar 2011 19:03:08 +0530

The architecture document proposes to have dialog/session state in
Metadata model. To achieve this, "session state" attribute has to be
added in the CS block of Metadata model. The possible values for session
state are
 
1) Trying
2) Proceeding
3) Early
4) Confirmed
5) Terminated 
 
Please let me know in case any objection to add this attribute in
Metadata model.
 
Thanks
Partha 

From: Parthasarathi R (partr) 
Sent: Wednesday, March 16, 2011 5:40 AM
To: Hutton, Andrew
Cc: Elwell, John; [email-masked]
Subject: RE: Progressing the architecture document

[AndyH]I assume it is as for example I assume it would be necessary to
record early-media and update the SRS when the dialog changes to the
confirmed or terminated state. Does not seem to be in the metadata draft
though. In the end I will either remove these bullets or align with the
metadata draft.
<Partha> It is a good point. Dialog state shall be added as one of the
optional attribute in CS metadata block with default value as
mid-dialog. This helps to differentiate between early dialog (ringback)
vs mid-dialog (normal conversation) in recording. In case of no
objection for this attribute in metadata model, we will add it. We will
work out metadata format once the consensus occurs for metadata model.
In case required, we will span separate mail thread to close this issue
</Partha>

---

From: Leon Portman <[email-masked]>
Date: Tue, 22 Mar 2011 16:10:49 +0200

Should we have error state as well?

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Tuesday, March 22, 2011 3:33 PM
To: Parthasarathi R (partr); Hutton, Andrew
Cc: [email-masked]
Subject: [siprec] Dialog state in the CS block of metadata model [was RE: Progressing the architecture document]

The architecture document proposes to have dialog/session state in Metadata model. To achieve this, "session state" attribute has to be added in the CS block of Metadata model. The possible values for session state are

1) Trying
2) Proceeding
3) Early
4) Confirmed
5) Terminated

Please let me know in case any objection to add this attribute in Metadata model.

Thanks
Partha

> From: [email-masked]<mailto:[email-masked]>
> To: Elwell, John; [email-masked]<mailto:[email-masked]>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 22 Mar 2011 17:02:00 +0100

What would it be used for?

Regards
Andy

________________________________
From: Leon Portman [mailto:[email-masked]]
Sent: 22 March 2011 14:11
To: Parthasarathi R (partr); Hutton, Andrew
Cc: [email-masked]
Subject: RE: Dialog state in the CS block of metadata model [was RE: Progressing the architecture document]

Leon

1) Trying
2) Proceeding
3) Early
4) Confirmed
5) Terminated

Thanks
Partha

---

From: Leon Portman <[email-masked]>
Date: Tue, 22 Mar 2011 18:07:28 +0200

It can be either application level error or dialog level errors - like timeout or failures.

Leon

From: Hutton, Andrew [mailto:[email-masked]]
Sent: Tuesday, March 22, 2011 6:02 PM
To: Leon Portman; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Dialog state in the CS block of metadata model [was RE: Progressing the architecture document]

Regards
Andy

Leon

1) Trying
2) Proceeding
3) Early
4) Confirmed
5) Terminated

Thanks
Partha

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 22 Mar 2011 18:42:52 +0100

What would dialog state be used for?

John 

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 22 March 2011 13:33
> Subject: Dialog state in the CS block of metadata model [was 
> RE: Progressing the architecture document]
> 
> The architecture document proposes to have dialog/session 
> state in Metadata model. To achieve this, "session state" 
> attribute has to be added in the CS block of Metadata model. 
> The possible values for session state are
>  
> 1) Trying
> 2) Proceeding
> 3) Early
> 4) Confirmed
> 5) Terminated 
>  
> <Partha> It is a good point. Dialog state shall be added as 
> one of the optional attribute in CS metadata block with 
> default value as mid-dialog. This helps to differentiate 
> between early dialog (ringback) vs mid-dialog (normal 
> conversation) in recording. In case of no objection for this 
> attribute in metadata model, we will add it. We will work out 
> metadata format once the consensus occurs for metadata model. 
> In case required, we will span separate mail thread to close 
> this issue </Partha>
> 
> 
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 23 Mar 2011 05:56:37 +0530

John,
 
As Andy mentioned in the below mail thread, One of the usecase for session state attribute is to understand whether CS is in early media or not. The other possible usecase is to indicate explicitly about CS termination within persistent recording.
 
Thanks
Partha 

From: Elwell, John [mailto:[email-masked]]
Sent: Tue 3/22/2011 11:12 PM
To: Parthasarathi R (partr); Hutton, Andrew
Cc: [email-masked]
Subject: RE: Dialog state in the CS block of metadata model [was RE: Progressing the architecture document]

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 23 Mar 2011 06:12:41 +0530

Leon,
 
Shall we have optional "event" attribute to indicate the state change which is similar to "event" attribute in RFC 4235.  The "event" will include the following:
 
1) cancelled
2) rejected
3) replaced
4) bye
5) error
6) timeout
 
Thanks
Partha

From: Leon Portman [mailto:[email-masked]]
Sent: Tue 3/22/2011 9:37 PM
To: Hutton, Andrew; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Dialog state in the CS block of metadata model [was RE:Progressing the architecture document]

Leon

Regards

Andy

	Leon

	1) Trying

	2) Proceeding

	3) Early

	4) Confirmed

	5) Terminated 

	Thanks

	Partha

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 23 Mar 2011 19:59:45 +0530

I am still trying to understand what is the significance of this
attribute w.r.t CS. Are we saying the attribute represents the state of
CS ?

Note that CS need not be one dialog. 

For cases like Conference where there may be different participants, if
SRC happens to be Focus how do you derive/what is "session state" ?

For cases where B2BUA acts as SRC what is "session state" ?

Ram

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Parthasarathi R (partr)
Sent: Wednesday, March 23, 2011 6:13 AM
To: Leon Portman; Hutton, Andrew
Cc: [email-masked]
Subject: Re: [siprec] Dialog state in the CS block of metadata model
[wasRE:Progressing the architecture document]

Leon,

Shall we have optional "event" attribute to indicate the state change
which is similar to "event" attribute in RFC 4235.  The "event" will
include the following:

1) cancelled

2) rejected

3) replaced

4) bye

5) error

6) timeout

Thanks

Partha

From: Leon Portman [mailto:[email-masked]]
Sent: Tue 3/22/2011 9:37 PM
To: Hutton, Andrew; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Dialog state in the CS block of metadata model [was
RE:Progressing the architecture document]

It can be either application level error or dialog level errors - like
timeout or failures. 

Leon

From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2011 6:02 PM
To: Leon Portman; Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: Dialog state in the CS block of metadata model [was RE:
Progressing the architecture document]

Regards

Andy

	Subject: RE: Dialog state in the CS block of metadata model [was

	Leon

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Parthasarathi R (partr)
	Sent: Tuesday, March 22, 2011 3:33 PM
	To: Parthasarathi R (partr); Hutton, Andrew
	Cc: [email-masked]
	Subject: [siprec] Dialog state in the CS block of metadata model
[was RE: Progressing the architecture document]

	The architecture document proposes to have dialog/session state
in Metadata model. To achieve this, "session state" attribute has to be
added in the CS block of Metadata model. The possible values for session
state are

	1) Trying

	2) Proceeding

	3) Early

	4) Confirmed

	5) Terminated 

	Please let me know in case any objection to add this attribute
in Metadata model.

	Thanks

	Partha 

	
	[AndyH]I assume it is as for example I assume it would be
necessary to record early-media and update the SRS when the dialog
changes to the confirmed or terminated state. Does not seem to be in the
metadata draft though. In the end I will either remove these bullets or
align with the metadata draft.
	<Partha> It is a good point. Dialog state shall be added as one
of the optional attribute in CS metadata block with default value as
mid-dialog. This helps to differentiate between early dialog (ringback)
vs mid-dialog (normal conversation) in recording. In case of no
objection for this attribute in metadata model, we will add it. We will
work out metadata format once the consensus occurs for metadata model.
In case required, we will span separate mail thread to close this issue
</Partha>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 24 Mar 2011 08:05:48 +0530

Ram,
 
Please read inline.
 
Thanks
Partha

From: Ram Mohan R (rmohanr)
Sent: Wed 3/23/2011 7:59 PM
To: Parthasarathi R (partr); Leon Portman; Hutton, Andrew
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of metadata model [wasRE:Progressing the architecture document]

I am still trying to understand what is the significance of this attribute w.r.t CS. Are we saying the attribute represents the state of CS ?

<Partha>  The attribute is to show the state of CS only. As it is not single dialog, I have mentioned as session state attribute </Partha>

For cases like Conference where there may be different participants, if SRC happens to be Focus how do you derive/what is "session state" ?

<Partha> I really don't know whether it is generic. My thought processing of session state for conference is as follows:

1) First participant of conference early media (ivr play) may be considered as "early" state of session.

2) The session state is chaged to confirmed in case any one of the participant joined in the conference. 

3) The session state is move to terminated when the last participant moved out of the conference. 

Please let me know in case other way to represent the session state of conference </partha>

<partha> It looks straight forward for me. In B2BUA case , 

1) The stage where in two party is not connected, it is considered as early state.

2) when both are connected, it is confirmed state

3) In case of BYE received from any one of the party, then CS is considered as terminated state

Please note that this is applicable for 3PCC as well.   </partha>

Ram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Wednesday, March 23, 2011 6:13 AM
To: Leon Portman; Hutton, Andrew
Cc: [email-masked]
Subject: Re: [siprec] Dialog state in the CS block of metadata model [wasRE:Progressing the architecture document]

Leon,

1) cancelled

2) rejected

3) replaced

4) bye

5) error

6) timeout

Thanks

Partha

Leon

Regards

Andy

	Leon

	1) Trying

	2) Proceeding

	3) Early

	4) Confirmed

	5) Terminated 

	Thanks

	Partha

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Mar 2011 17:33:37 +0100

This discussion gives me some concerns, echoing to some extent what Ram is saying.

SIPREC is about session recording, where a session is the information exchanged between participants in a CS (the media streams) plus metadata. The metadata should provide additional information about the CS. This means information about the communication SESSION, not about the SIP dialog that is used to control that session. With this in mind, consider the following points, some of which have already been raised:

1. There may be more than one SIP dialog involved if the SRC is at a B2BUA or conference focus.

2. Does the CS necessarily need to be controlled by SIP? For example, it could be a PSTN call, an RTC-Web call or a Jingle call. None of these preclude using SIP for the RS (that is what the charter of SIPREC is all about - a SIP-based RS).

3. Somebody retrieving and playing back a recorded CS will be interested in session-related events like participants leaving and joining (including the first participants joining at the start of the CS and the last participants leaving a the end of the CS), media streams starting and ending and participants starting or stopping receipt of a media stream. In other words, changes of SESSION state, not dialog state.

4. Some of the SIP dialog states just don't seem relevant. The distinction between early dialog and full dialog in SIP does not necessarily corresponding to any meaningful state change of the session. For example, A makes a call to B and B answers and starts sending media. A receives and renders media (perhaps it has already received SDP answer, allowing it to verify the source of the media). Then A receives the 200 OK (transitioning from an early dialog to a full dialog) and continues to receive media. So although there is a dialog state change, there is not really a session state change.

The bit about dialog state in the architecture draft is, in my opinion, a legacy from some earlier discussions, before we started having the metadata discussions. I think the metadata discussions have taken us in the right direction.

John (as individual)

> Sent: 24 March 2011 02:36
> To: Ram Mohan R (rmohanr); Leon Portman; Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] Dialog state in the CS block of 
> metadata model [wasRE:Progressing the architecture document]
> 
> Ram,
>  
> Please read inline.
>  
> Thanks
> Partha
> 
> Subject: RE: [siprec] Dialog state in the CS block of 
> metadata model [wasRE:Progressing the architecture document]
> 
> 
> 
> I am still trying to understand what is the significance of 
> this attribute w.r.t CS. Are we saying the attribute 
> represents the state of CS ?
> 
> <Partha>  The attribute is to show the state of CS only. As 
> it is not single dialog, I have mentioned as session state 
> attribute </Partha>
> 
> For cases like Conference where there may be different 
> participants, if SRC happens to be Focus how do you 
> derive/what is "session state" ?
> 
> <Partha> I really don't know whether it is generic. My 
> thought processing of session state for conference is as follows:
> 
>  
> 
> 1) First participant of conference early media (ivr play) may 
> be considered as "early" state of session.
> 
> 2) The session state is chaged to confirmed in case any one 
> of the participant joined in the conference. 
> 
> Subject: Re: [siprec] Dialog state in the CS block of 
> metadata model [wasRE:Progressing the architecture document]
> 
>  
> 
> Leon,
> 
>  
> 
> Shall we have optional "event" attribute to indicate the 
> state change which is similar to "event" attribute in RFC 
> 4235.  The "event" will include the following:
> 
>  
> 
> 1) cancelled
> 
> 2) rejected
> 
> 3) replaced
> 
> 4) bye
> 
> 5) error
> 
> 6) timeout
> 
>  
> 
> Thanks
> 
> Partha
> 
>  
> 
> Subject: RE: Dialog state in the CS block of metadata model 
> [was RE:Progressing the architecture document]
> 
> Subject: RE: Dialog state in the CS block of metadata model 
> 	Subject: RE: Dialog state in the CS block of metadata 
> model [was RE: Progressing the architecture document]
> 
> 	Subject: [siprec] Dialog state in the CS block of 
> metadata model [was RE: Progressing the architecture document]
> 
> 	 
> 
> 	The architecture document proposes to have 
> dialog/session state in Metadata model. To achieve this, 
> "session state" attribute has to be added in the CS block of 
> Metadata model. The possible values for session state are
> 
> 	 
> 
> 	1) Trying
> 
> 	2) Proceeding
> 
> 	3) Early
> 
> 	4) Confirmed
> 
> 	5) Terminated 
> 
> 	 
> 
> 	[AndyH]I assume it is as for example I assume it would 
> be necessary to record early-media and update the SRS when 
> the dialog changes to the confirmed or terminated state. Does 
> not seem to be in the metadata draft though. In the end I 
> will either remove these bullets or align with the metadata draft.
> 	<Partha> It is a good point. Dialog state shall be 
> added as one of the optional attribute in CS metadata block 
> with default value as mid-dialog. This helps to differentiate

---

From: Leon Portman <[email-masked]>
Date: Sat, 26 Mar 2011 11:30:53 +0200

John Hello

I agree that SRS (and its application clients) interested in SESSION level events and not underlying DIALOG events. However we do need to support reporting session state information per CS  participant that sometimes equals to dialog level and sometimes not.

We could have define more application level state events like instead of TRYING - > RINGING etc. However they could be domain specific.

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, March 24, 2011 6:34 PM
To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Leon Portman; Hutton, Andrew
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of metadata model [wasRE:Progressing the architecture document]

John (as individual)

> Subject: RE: [siprec] Dialog state in the CS block of metadata model 
> attribute w.r.t CS. Are we saying the attribute represents the state 
> of CS ?
> 
> <Partha>  The attribute is to show the state of CS only. As it is not 
> single dialog, I have mentioned as session state attribute </Partha>
> 
> For cases like Conference where there may be different participants, 
> if SRC happens to be Focus how do you derive/what is "session state" ?
> 
> <Partha> I really don't know whether it is generic. My thought 
> processing of session state for conference is as follows:
> 
>  
> 
> 	Subject: [siprec] Dialog state in the CS block of metadata model [was 
> added in the CS block of Metadata model. The possible values for 
> session state are
> 
> 	 
> 
> 	1) Trying
> 
> 	2) Proceeding
> 
> 	3) Early
> 
> 	4) Confirmed
> 
> 	5) Terminated
> 
> 	 
> 
> 	[AndyH]I assume it is as for example I assume it would be necessary 
> to record early-media and update the SRS when the dialog changes to 
> the confirmed or terminated state. Does not seem to be in the metadata 
> 	<Partha> It is a good point. Dialog state shall be added as one of 
> the optional attribute in CS metadata block with default value as 
> mid-dialog. This helps to differentiate between early dialog 
> (ringback) vs mid-dialog (normal
> conversation) in recording. In case of no objection for this attribute 
> in metadata model, we will add it. We will work out metadata format 
> once the consensus occurs for metadata model.
> In case required, we will span separate mail thread to close this 
> issue </Partha>
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 26 Mar 2011 12:06:33 -0700

Hi Leon,

I am still having a hard time understanding why we need the session
state information per CS participant? Why is this required, who uses it,
and how?

Thanks,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Leon Portman
> Sent: Saturday, March 26, 2011 10:31 AM
> To: Elwell, John; Parthasarathi R (partr); Ram Mohan R (rmohanr);
Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] Dialog state in the CS block of metadatamodel
[wasRE:Progressing the
> architecture document]
> 
> John Hello
> 
> I agree that SRS (and its application clients) interested in SESSION
level events and not underlying
> DIALOG events. However we do need to support reporting session state
information per CS  participant
> that sometimes equals to dialog level and sometimes not.
> 
> We could have define more application level state events like instead
of TRYING - > RINGING etc.
> However they could be domain specific.
> 
> Leon
> 
[wasRE:Progressing the
> architecture document]
> SIPREC is about session recording, where a session is the information
exchanged between participants
> in a CS (the media streams) plus metadata. The metadata should provide
additional information about
> the CS. This means information about the communication SESSION, not
about the SIP dialog that is used
> to control that session. With this in mind, consider the following
points, some of which have already
> been raised:
> 2. Does the CS necessarily need to be controlled by SIP? For example,
it could be a PSTN call, an RTC-
> Web call or a Jingle call. None of these preclude using SIP for the RS
(that is what the charter of
> SIPREC is all about - a SIP-based RS).
> 
> 3. Somebody retrieving and playing back a recorded CS will be
interested in session-related events
> like participants leaving and joining (including the first
participants joining at the start of the CS
> and the last participants leaving a the end of the CS), media streams
starting and ending and
> participants starting or stopping receipt of a media stream. In other
words, changes of SESSION state,
> not dialog state.
> 
> 4. Some of the SIP dialog states just don't seem relevant. The
distinction between early dialog and
> full dialog in SIP does not necessarily corresponding to any
meaningful state change of the session.
> For example, A makes a call to B and B answers and starts sending
media. A receives and renders media
> (perhaps it has already received SDP answer, allowing it to verify the
source of the media). Then A
> receives the 200 OK (transitioning from an early dialog to a full
dialog) and continues to receive
> media. So although there is a dialog state change, there is not really
a session state change.
> 
> The bit about dialog state in the architecture draft is, in my
opinion, a legacy from some earlier
> discussions, before we started having the metadata discussions. I
think the metadata discussions have
> taken us in the right direction.
> 
> John (as individual)
> 
> 
> > Please let me know in case other way to represent the session state
of
> > conference </partha>
> > 1) The stage where in two party is not connected, it is considered
as
> > early state.
> > 	Subject: [siprec] Dialog state in the CS block of metadata model
[was
> > 	The architecture document proposes to have dialog/session state
in
> > 	Please let me know in case any objection to add this attribute
in
> > 	Partha
necessary
> > 	<Partha> It is a good point. Dialog state shall be added as one
of
> > conversation) in recording. In case of no objection for this
attribute

---

From: Leon Portman <[email-masked]>
Date: Sat, 26 Mar 2011 21:14:48 +0200

Charles Hi

Without participant session state, SRS will know only when participant is part of the session and will not know about intermediate states like ringing, retrying etc.
I know that we have media stream information per participant but not sure that it is enough.

Leon
-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: Saturday, March 26, 2011 9:07 PM
To: Leon Portman; Elwell, John; Parthasarathi R (partr); Ram Mohan R (rmohanr); Hutton, Andrew
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of metadatamodel [wasRE:Progressing the architecture document]

Hi Leon,

I am still having a hard time understanding why we need the session state information per CS participant? Why is this required, who uses it, and how?

Thanks,
Charles

Behalf Of Leon Portman
Hutton, Andrew
[wasRE:Progressing the
[wasRE:Progressing the
starting and ending and
a session state change.
of
as
[was
in
in
necessary
of
attribute

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 27 Mar 2011 02:35:29 -0700

Hi Leon,

Thank you for your patience in trying to explain this to me; however, I
still am not able to understand why the SRS might need to know this
information, or what it would do with it. Is it that you need to know
when a given participant was receiving the recorded media and when it
was not? If so, I do not think dialog state is sufficient. Is there some
other requirement or functionality addressed by the SRS having such
information?
Perhaps it is easier to discuss in person at the breakfast meeting
Wednesday or during the working group session.

Cheers,
Charles

> Sent: Saturday, March 26, 2011 8:15 PM
> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R (partr);
Ram Mohan R (rmohanr); Hutton,
> Andrew
metadatamodel[wasRE:Progressing the architecture
> document]
> 
> Charles Hi
> 
> Without participant session state, SRS will know only when participant
is part of the session and will
> not know about intermediate states like ringing, retrying etc.
> Subject: RE: [siprec] Dialog state in the CS block of metadatamodel
[wasRE:Progressing the
> I am still having a hard time understanding why we need the session
state information per CS
> participant? Why is this required, who uses it, and how?
> 
> Thanks,
> Charles
> 
participants,
> > > if SRC happens to be Focus how do you derive/what is "session
state"
> ?
> > > 3) The session state is move to terminated when the last
participant
> > > moved out of the conference.
> > >
> > >
> > >

---

From: Leon Portman <[email-masked]>
Date: Sun, 27 Mar 2011 12:48:05 +0200

Charles Hi

Yes, it will be good to discuss it face to face.

Just little background for such requirements. Today, especially for contact centers, it is important for SRS to capture the information how long customer was waiting for agent to answer the call, which party hang up, how long was the hold time, if it was blind transfer or consultation transfer. This information important both from quality management point of view and customer experience point of view.  It is important also from compliance point of view to detect if somebody actually received the media stream or still was in pending state or media stream was disconnected.

Leon

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Sunday, March 27, 2011 11:35 AM
To: Leon Portman; Elwell, John; Parthasarathi R (partr); Ram Mohan R (rmohanr); Hutton, Andrew
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document]

Hi Leon,

Thank you for your patience in trying to explain this to me; however, I still am not able to understand why the SRS might need to know this information, or what it would do with it. Is it that you need to know when a given participant was receiving the recorded media and when it was not? If so, I do not think dialog state is sufficient. Is there some other requirement or functionality addressed by the SRS having such information?
Perhaps it is easier to discuss in person at the breakfast meeting Wednesday or during the working group session.

Cheers,
Charles

[wasRE:Progressing the
state information per CS
participants,
state"
participant

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 27 Mar 2011 06:58:12 -0400

Leon,

Is it still the case that some contact centers manage to keep the 
customer in an early dialog for an extended period of time, while 
treating with IVR, until a live agent is assigned?

	Thanks,
	Paul

>> of TRYING ->  RINGING etc.
>>>> conference</partha>
>>>> Please note that this is applicable for 3PCC as well.</partha>
>>>>
>>>>
>>>>
>>>> Ram
>>>>
>>>>
>>>>
>>>> issue</Partha>

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 27 Mar 2011 15:49:52 +0200

> Sent: 27 March 2011 11:48
> To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R
> (partr); Ram Mohan R (rmohanr); Hutton, Andrew
> Cc: [email-masked]
> metadatamodel[wasRE:Progressing the architecture document]
>
> Charles Hi
>
> Just little background for such requirements. Today,
> especially for contact centers, it is important for SRS to
> capture the information how long customer was waiting for
> agent to answer the call, which party hang up, how long was
> the hold time, if it was blind transfer or consultation
> transfer. This information important both from quality
> management point of view and customer experience point of
> view.
[JRE] (as chair) I think the group needs to consider whether this is within scope. Looking at the requirements, we have:
"REQ-012 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."
If we are not recording the session while the caller is waiting to be answered, it seems we perhaps don't have a requirement for metadata about that. This seems to be more about call detail recording (CDR) rather than session recording. We can by all means have this discussion, but I am concerned about scope creep.

> It is important also from compliance point of view to
> detect if somebody actually received the media stream or
> still was in pending state or media stream was disconnected.
[JRE] (as individual) I agree we should show a participant as receiving media only if the SRC believes media is actually being sent to that participant (even then, there can be no guarantee it is received, e.g., because NAT or firewall traversal isn't functioning properly, severe packet loss, speaker volume is muted, etc..). But I have doubts whether it is necessarily to try to account for periods when the SRC knows a participant is not receiving media by saying it is because of alerting, hold or whatever.

John

> metadatamodel[wasRE:Progressing the architecture document]
>
> Hi Leon,
>
> Thank you for your patience in trying to explain this to me;
> however, I still am not able to understand why the SRS might
> need to know this information, or what it would do with it.
> Is it that you need to know when a given participant was
> receiving the recorded media and when it was not? If so, I do
> not think dialog state is sufficient. Is there some other
> requirement or functionality addressed by the SRS having such
> information?
> Perhaps it is easier to discuss in person at the breakfast
> meeting Wednesday or during the working group session.
>
> Cheers,
> Charles
>
> metadatamodel
> metadata model
> > > This discussion gives me some concerns, echoing to some
> extent what
> > Ram is saying.
> > >
> > > 1. There may be more than one SIP dialog involved if the
> SRC is at a
> > B2BUA or conference focus.
> > >
> > > Web call or a Jingle call. None of these preclude using
> SIP for the
> RS
> > > > <Partha>  The attribute is to show the state of CS
> only. As it is
> > not
> > > > 2) The session state is chaged to confirmed in case any
> one of the
> > > > participant joined in the conference.
> > > >
> > > > It can be either application level error or dialog
> level errors -
> > like
> > > > timeout or failures.
> > > >
> > > >
> > > >
> > > > Leon
> > > >
> > > >
> > > >
> > > > From: Hutton, Andrew
> [mailto:[email-masked]]
> model [was
> metadata model
> dialog/session state
> > > > Metadata model. To achieve this, "session state"
> attribute has to
> be
> > > >   > [mailto:[email-masked]] On Behalf Of
> Parthasarathi R
> > > > (partr)
> added as one

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 28 Mar 2011 09:13:27 +0200

Hi,

The draft-ietf-siprec-architecture has from the very beginning listed dialog state as an example of what would be included in metadata which is why I raised the question.

However it is true to say this was put in the architecture document before we had firmed up the requirements or starting any indepth work on metadata so I could accept that the architecture draft simply got this wrong from the start and it maybe should be removed. We could of course take the view that if dialog events are important then the SRS could subscribe to the dialog event package at the SRC and SIPREC does not need to touch this.

I don't think we can allow SIPREC metadata to extend as far as reporting everything that happens to the CS including how it is linked to other CS's and what services are used on the CS (E.g. types of transfer etc.). This would quickly get very difficult to define and we would probably fail.

I would prefer to not report this state information in metadata than open up the possibility of adding lots of complexity.

Regards
Andy

> From: Elwell, John
> Sent: 27 March 2011 14:50
> To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi R
> [JRE] (as chair) I think the group needs to consider whether
> this is within scope. Looking at the requirements, we have:
> If we are not recording the session while the caller is
> waiting to be answered, it seems we perhaps don't have a
> requirement for metadata about that. This seems to be more
> about call detail recording (CDR) rather than session
> recording. We can by all means have this discussion, but I am
> concerned about scope creep.
>
> [JRE] (as individual) I agree we should show a participant as
> receiving media only if the SRC believes media is actually
> being sent to that participant (even then, there can be no
> guarantee it is received, e.g., because NAT or firewall
> traversal isn't functioning properly, severe packet loss,
> speaker volume is muted, etc..). But I have doubts whether it
> is necessarily to try to account for periods when the SRC
> knows a participant is not receiving media by saying it is
> because of alerting, hold or whatever.
>
> John
>
>
> >
> > Leon
> >
> > > I know that we have media stream information per
> participant but not
> > sure that it is enough.
> > >
> > > Leon
> > > To: Leon Portman; Elwell, John; Parthasarathi R (partr);
> Ram Mohan R
> > (rmohanr); Hutton, Andrew
> > > Cc: [email-masked]
> [mailto:[email-masked]] On
> > > Behalf Of Leon Portman
> > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr);
> Leon Portman;
> > > Hutton, Andrew
> > > > Cc: [email-masked]
> > > > (perhaps it has already received SDP answer, allowing
> it to verify
> > the
> > > > > 1) First participant of conference early media (ivr
> play) may be
> > > > > considered as "early" state of session.
> > > > >
> > > > > 3) In case of BYE received from any one of the party,
> then CS is
> > > > > considered as terminated state
> > > > >
> > > > >
> > > > >
> > > > > which is similar to "event" attribute in RFC 4235.
> The "event"
> > will
> > > > > include the following:
> > > > >
> > > > >
> > > > >
> > > > > 1) cancelled
> > > > >
> > > > > 2) rejected
> > > > >
> > > > > 3) replaced
> > > > >
> > > > > 4) bye
> > > > >
> > > > > 5) error
> > > > >
> > > > > 6) timeout
> > > > >
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > Partha
> > > > >
> > > > >
> > > > >
> > > > > to record early-media and update the SRS when the
> dialog changes
> > to

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 28 Mar 2011 06:35:16 -0700

I agree with this approach. Hopefully Leon and others that saw the need
for this state information can confirm if it works for them.

Cheers,
Charles

> Sent: Monday, March 28, 2011 9:13 AM
> To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); Parthasarathi
R (partr); Ram Mohan R
> (rmohanr)
> document]
> 
> Hi,
> 
> The draft-ietf-siprec-architecture has from the very beginning listed
dialog state as an example of
> what would be included in metadata which is why I raised the question.
> 
> However it is true to say this was put in the architecture document
before we had firmed up the
> requirements or starting any indepth work on metadata so I could
accept that the architecture draft
> simply got this wrong from the start and it maybe should be removed.
We could of course take the view
> that if dialog events are important then the SRS could subscribe to
the dialog event package at the
> SRC and SIPREC does not need to touch this.
> 
> I don't think we can allow SIPREC metadata to extend as far as
reporting everything that happens to
> the CS including how it is linked to other CS's and what services are
used on the CS (E.g. types of
> transfer etc.). This would quickly get very difficult to define and we
would probably fail.
> 
> I would prefer to not report this state information in metadata than
open up the possibility of adding
> lots of complexity.
> > > > > participants starting or stopping receipt of a media stream.
In
> > > other
> > > > > media. So although there is a dialog state change, there is
not
> > > really
> > > > > > [mailto:[email-masked]] On Behalf Of Parthasarathi
R
> > > > > > Subject: Re: [siprec] Dialog state in the CS block of
metadata
> > > model
metadata
> > > model
> > > > > > attribute w.r.t CS. Are we saying the attribute represents
the
> > > state
thought
> > > > > > Please let me know in case other way to represent the
session
> > > state
> > > > > > [mailto:[email-masked]] On Behalf Of Parthasarathi
R
> > > > > > Subject: Re: [siprec] Dialog state in the CS block of
metadata
> > > model
state
> > > > change
> > > > > > [mailto:[email-masked]] On Behalf Of Parthasarathi
R
> > > > > > the confirmed or terminated state. Does not seem to be in
the
> > > > metadata
> > > > > > draft though. In the end I will either remove these bullets
or

---

From: Leon Portman <[email-masked]>
Date: Mon, 28 Mar 2011 15:45:36 +0200

Charles Hi

Just to make clear, I don't think SRS should receive dialog level state events about all  CS dialogs. I think that we should to support reporting high level session events.
I understand the complexity of that and Ok to keep it open or next phase extensions

Leon

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Monday, March 28, 2011 3:35 PM
To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R (partr); Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document]

I agree with this approach. Hopefully Leon and others that saw the need for this state information can confirm if it works for them.

Cheers,
Charles

R (partr); Ram Mohan R
would probably fail.
> > To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi R (partr);
> > Ram Mohan R (rmohanr); Hutton, Andrew
> > Cc: [email-masked]
> > > Just little background for such requirements. Today, especially
> > > for contact centers, it is important for SRS to capture the
> > > information how long customer was waiting for agent to answer the
> > > call, which party hang up, how long was the hold time, if it was
> > > blind transfer or consultation transfer. This information
> > > important both from quality management point of view and customer
> > > experience point of view.
> > [JRE] (as chair) I think the group needs to consider whether this is
> > within scope. Looking at the requirements, we have:
> > If we are not recording the session while the caller is waiting to
> > be answered, it seems we perhaps don't have a requirement for
> > metadata about that. This seems to be more about call detail
> > recording (CDR) rather than session recording. We can by all means
> > have this discussion, but I am concerned about scope creep.
> >
> > > It is important also from compliance point of view to detect if
> > > somebody actually received the media stream or still was in
> > > pending state or media stream was disconnected.
> > receiving media only if the SRC believes media is actually being
> > sent to that participant (even then, there can be no guarantee it is
> > received, e.g., because NAT or firewall traversal isn't functioning
> > properly, severe packet loss, speaker volume is muted, etc..). But I
> > have doubts whether it is necessarily to try to account for periods
> > when the SRC knows a participant is not receiving media by saying it
> > is because of alerting, hold or whatever.
> >
> > John
> >
> >
> > >
> > > Leon
> > >
> > > however, I still am not able to understand why the SRS might need
> > > to know this information, or what it would do with it.
> > > Is it that you need to know when a given participant was receiving
> > > the recorded media and when it was not? If so, I do not think
> > > dialog state is sufficient. Is there some other requirement or
> > > functionality addressed by the SRS having such information?
In
not
R
metadata
metadata
the
thought
session
R
metadata
state
R
the
or

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 28 Mar 2011 22:23:15 +0530

The question of "session" state is raised in my mind mainly to
distinguish between early media (Media before session establishment)
from normal media. Without the information in SIPREC metadata, the early
media will be associated with UAS participant's media stream. I'm
interested in knowing whether SIPREC solution has to differentiate
between early media from normal media.

As per John below mail, there is no need to differentiate as per the
current requirement. If most of the folks feel so, I'm fine with not
including "session state" in metadata.

Thanks
Partha 

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: Monday, March 28, 2011 7:16 PM
To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John; Parthasarathi
R (partr); Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of
metadatamodel[wasRE:Progressing the architecture document]

Charles Hi

Just to make clear, I don't think SRS should receive dialog level state
events about all  CS dialogs. I think that we should to support
reporting high level session events.
I understand the complexity of that and Ok to keep it open or next phase
extensions

Leon

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Monday, March 28, 2011 3:35 PM
To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R (partr);
Ram Mohan R (rmohanr)
Cc: [email-masked]

Cheers,
Charles

R (partr); Ram Mohan R
would probably fail.

> > > To: Leon Portman; Elwell, John; Parthasarathi R (partr); Ram Mohan

> > > R (rmohanr); Hutton, Andrew
> > > Cc: [email-masked]

In
not
R
metadata
metadata
the
thought
session
R
metadata
state
R
the
or

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Mar 2011 07:08:47 +0200

Partha,

I think the real distinction you wish to make is between media coming from a particular participant (associated with the UAS) and media coming from some other entity (e.g., media server). In my view the latter case, if we choose to record it, comes from a different "participant". It has nothing to do with whether it is deemed early or regular from a SIP dialog perspective.

John (as individual)

> Sent: 28 March 2011 17:53
> To: Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew;
> Elwell, John; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> waiting to
> > > > > > We could have define more application level state
> events like
> > > > instead
> [mailto:[email-masked]]
> > > > > > in a CS (the media streams) plus metadata. The
> metadata should
> > > > provide
> > > > > > and the last participants leaving a the end of the
> CS), media
> > > > streams
> > > > > starting and ending and
> Parthasarathi
> Parthasarathi
> Parthasarathi
> > > > > > > in metadata model, we will add it. We will work
> out metadata
> > > > format

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 29 Mar 2011 14:20:03 +0530

John,

I agree with you in case of media server participant sends "ringback"
media stream during the early dialog and later stage, the callee
participant sends actual stream of the session using another
offer/answer exchange. It is also possible that callee sends "ringback"
media stream  wherein there is no difference between early or regular
media in terms of metadata information.

Having said that, it "may" or "may not" be matter whether the devices of
the participant automatically creates the media stream or participant
actually creates media stream.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2011 10:39 AM
To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);
Hutton, Andrew; Ram Mohan R (rmohanr)
Cc: [email-masked]
Subject: RE: [siprec] Dialog state in the CS block of
metadatamodel[wasRE:Progressing the architecture document]

Partha,

I think the real distinction you wish to make is between media coming
from a particular participant (associated with the UAS) and media coming
from some other entity (e.g., media server). In my view the latter case,
if we choose to record it, comes from a different "participant". It has
nothing to do with whether it is deemed early or regular from a SIP
dialog perspective.

John (as individual)

> To: Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew; Elwell, 
> John; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> from normal media. Without the information in SIPREC metadata, the 
> early media will be associated with UAS participant's media stream. 
> I'm interested in knowing whether SIPREC solution has to differentiate

> To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John; 
> Parthasarathi R (partr); Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Just to make clear, I don't think SRS should receive dialog level 
> state events about all  CS dialogs. I think that we should to support 
> I agree with this approach. Hopefully Leon and others that saw the 
> need for this state information can confirm if it works for them.
>
> Cheers,
> Charles
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 29 Mar 2011 23:47:05 +0200

> Sent: 29 March 2011 09:50
> To: Elwell, John; Leon Portman; Charles Eckel (eckelcu);
[JRE] The SRC, depending on where it is located on the path of the CS, might be unable to determine whether media comes from a user or from the user's device. Only an SRC collocated with the user's device can determine this. A B2BUA would be unable to determine it, for example. So is it really worth trying to send information about this if, in many situations, the information will not be available?

John (as individual)

> especially
> > > >    CSs that are being recorded, including the media
> being used and
> > the
> detect if
> > > > > > > 2. Does the CS necessarily need to be controlled
> by SIP? For
> > > > > example,
> > > > > > > > single dialog, I have mentioned as session
> state attribute
> > > > > </Partha>
> > > > > > > >