Subject: Re: [siprec] Review of metadata-03

From: Michael Baj <[email-masked]>
Date: Thu, 21 Jul 2011 15:42:51 +0000

I think there is a problem with the 2 participant minimum for a CS.  If we look at a blind transfer handled from a UA, SIPREC could be faced with this possible scenario:

Assume UA-A is the SRC:
UA-A INVITES UA-B, UA-B REFERS UA-A to UA-C, UA-B sends BYE after 202 Accepted, (one participant in CS now)
UA-A INVITES UA-C, UA-C Responds with 180 RINGING for X seconds, UA-A CANCELS INVITE to UA-C, CS ends.

Questions:
Is UA-C added to the CS prior to 200 OK on INVITE?
If not, then the CS has only one participant after B leaves.  Does the original CS end with B sends BYE?
How is the failed REFER handled in the metadata for recording?

Thanks,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Thursday, July 21, 2011 4:59 AM
To: Elwell, John; Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] Review of metadata-03

John,

Thanks for the closure of minimum 2 participant per CS open item.

Thanks
Partha 

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, July 21, 2011 1:51 PM
> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); [email-masked]
> Subject: RE: [siprec] Review of metadata-03
> 
> Don't re-open is on my account. I failed to recall the past 
> discussion.
> 
> John
> 
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > Sent: 21 July 2011 06:37
> > To: Ram Mohan R (rmohanr); Elwell, John; [email-masked]
> > Subject: RE: [siprec] Review of metadata-03
> > 
> > Ram,
> > 
> > As you mentioned, it was discussed during IETF-80 with different 
> > use-case like studio mode recording, voice mail. Then, we
> agreed to go
> > with minimum 2 participant. I have asked this item to be re-opened 
> > because John is slightly uncomfortable and expects more 
> > opinion/usecase.
> > IMO, it is better to discuss in IETF-81 and close forever.
> > 
> > Thanks
> > Partha
> > 
> > > -----Original Message-----
> > > From: Ram Mohan R (rmohanr)
> > > Sent: Thursday, July 21, 2011 10:57 AM
> > > To: Parthasarathi R (partr); Elwell, John; [email-masked]
> > > Subject: RE: [siprec] Review of metadata-03
> > > 
> > > Hi John / Partha,
> > > 
> > > > > > > 33. Section 6.3.2:
> > > > > > > "CS to have atleast two or more participants"
> > > > > > > Are there any corner cases where there might be fewer
> > > than two?
> > > > > > >
> > > > > > <Partha> We don't know the usecase till now and
> > > concluded for two
> > > > > > participant. In case you know of any usecase, Please
> > > let us know
> > > > > > </Partha>
> > > > > [JRE] I am not aware of a use case - I just feel slightly 
> > > > > uncomfortable. Leave it for now.
> > > > >
> > > > <Partha> Let us track this as an open item for IETF-81 and
> > > explore the
> > > > possibility </Partha>
> > > 
> > > 
> > > A comment on this- In the current model Each CS class has atleast 
> > > two participants.  IOW the current model does not allow a CS with 
> > > less than 2 participants.  Is there a need to track this as open 
> > > item ? As I remember we did agree initially that each CS
> shall have
> > > atleast two participants.
> > > 
> > > Let me know so that I can add this to slide deck as open item if 
> > > need be.
> > > 
> > > Regards,
> > > Ram
> > > 
> > > 
> > 
> 
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jul 2011 12:17:32 -0400

> How is the failed REFER handled in the metadata for recording?

Well, the CS isn't very interesting while it has only one participant.
There aren't any media streams to record. And when there are media 
streams to record there will be at least two participants.

But yes, there is an issue of how to report this transitional state.

I have no problem with allowing a CS to have 1, or even zero, participants.

	Thanks,
	Paul

>>>>> possibility</Partha>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 22 Jul 2011 00:25:00 +0530

I am also ok with having  1 participant minimum for a CS. 
However since there is no media streams(as Paul mentioned), there will
be no recording done. An SRC (could be potentially a persistent RS) may
still report a metadata having just one participant with no <send> or
<recv> streams.

Wonder if there is a scenario where we can have Zero participants for a
CS ?

Regards,
Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, July 21, 2011 12:18 PM
> To: [email-masked]
> > I think there is a problem with the 2 participant minimum for a CS.
> If we look at a blind transfer handled from a UA, SIPREC could be
faced
> with this possible scenario:
> >
> > Assume UA-A is the SRC:
> > UA-A INVITES UA-B, UA-B REFERS UA-A to UA-C, UA-B sends BYE after
202
> Accepted, (one participant in CS now)
> > UA-A INVITES UA-C, UA-C Responds with 180 RINGING for X seconds,
UA-A
> CANCELS INVITE to UA-C, CS ends.
> >
> > Questions:

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 22 Jul 2011 06:51:40 +0530

Hi Mike,

I'm not against having 1 participant per CS but still I'm not fully
convinced for the given scenario. 

Definition of communication session as per SIPREC requirement document
is:

   "Communication Session (CS): A session created between two or more
SIP
   User Agents (UAs) that is the subject of recording."

In the metadata model, CS does not have dialog state and established
state is not prerequisite. Please read inline for further comments about
your scenario.

Thanks
Partha

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: Friday, July 22, 2011 12:25 AM
> To: [email-masked]
> However since there is no media streams(as Paul mentioned), 
> there will be no recording done. An SRC (could be potentially 
> a persistent RS) may still report a metadata having just one 
> participant with no <send> or <recv> streams.
> 
> Wonder if there is a scenario where we can have Zero 
> participants for a CS ?
> 
> Regards,
> Ram
> 
<Partha> Here, CS between UA-A & UA-B is terminated and so, no
participant </Partha>

> > > UA-A INVITES UA-C, UA-C Responds with 180 RINGING for X seconds,
<Partha> Here, new CS between UA-A & UA-B has to be created </Partha>

> > > Is UA-C added to the CS prior to 200 OK on INVITE?
<Partha> New CS (CS1) has to be created between UA-A & UA-C. In case you
wish to group both CS & CS1, Communication group (CSG) has to be
created. It is one of the main motive for the creation of CSG. 

Also, there is no 1:1 relation between CS and dialog. So, Another
alternative is that CS shall add UA-C upon REFER because it is consider
as part of CS and remove UA-B upon receiving BYE. In both mechanism, CS
will have minimum two participant at any time.

Please let me know in case I'm missing something in your scenario

FYI: Another interesting scenario brought up earlier related to
persistent RS connection having one participant. Here one of the UA is
always connected with SRS using RS and it will not represented because
there is no active CS. The conclusion is that metadata is not required
to pass this information. ISTM, your scenario is somewhat related to it.
 
</Partha> 

> > the original CS end with B sends BYE?
<Partha> It is the easiest implementation for SRC as I mentioned earlier
</Partha>

> > > How is the failed REFER handled in the metadata for recording?
<Partha> I'm not very sure about scenario. Some of the possibility which
I could think of:

1) REFER returns with 4xx, UA-B will not terminate the session and so,
CS is never terminated and 2 participant in CS.

2) INVITE towards UA-C from UA-A (new CS) fails, there is no standard
means to indicate this failure to terminated dialog between UA-B & UA-A.
Some extra service logic has to be created between UA-A & UA-B to
indicate REFER is failed.

In any scenario, atleast two participant involved </Partha>

> > Behalf Of Parthasarathi R (partr)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 24 Jul 2011 11:28:42 -0700

The use case I have in mind for a CS with a single participant is a
studio mode recording in which someone is recording themselves as the
only participant. One way this could be accomplished by a SIP UA
initiating a communication session with the SRC, or vice versa. I
thought I brought this use case and issue up previously. I can try to
find the thread in the archives if required or helpful.
I suppose another way to deal with this is having the SRC, which is
effectively acting as the other UA in the CS, identify itself as a
participant in the RS. I could see this being useful in some cases, but
I am not sure we would want to mandate that.

Cheers,
Charles

> Sent: Thursday, July 21, 2011 6:22 PM
> To: Ram Mohan R (rmohanr); [email-masked]; Michael Baj
> > > > If not, then the CS has only one participant after B leaves.
Does
> > > the original CS end with B sends BYE?

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 25 Jul 2011 02:35:00 +0530

Charles,

Even though I am ok with having 1 participant, for this use-case you
mentioned we still have two UAs ( "SIP UA" and the "SRC" which is the
second UA). There will be two SIP sessions at the device that acts as
SRC in your use-case( one towards SIP UA which is part of CS and the
other to SRS which is part of RS).

Ram

> From: Charles Eckel (eckelcu)
> Sent: Sunday, July 24, 2011 2:29 PM
> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); [email-masked];
> Michael Baj
> > > > >> From: Elwell, John
[mailto:[email-masked]]

---

From: Michael Baj <[email-masked]>
Date: Mon, 25 Jul 2011 02:48:42 +0000

For the record, I have come around on my initial argument about the need for a CS with a single participant for the blind transfer refer scenario.  I plan on implementing this as a CS originally with 2 participants, then going  to 3 participants, and then terminating the CS when party UA-C never answers or rejects the INVITE, as per Partha's explanation.

Mike

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Sunday, July 24, 2011 5:05 PM
To: Charles Eckel (eckelcu); Parthasarathi R (partr); [email-masked]; Michael Baj
Subject: RE: [siprec] Review of metadata-03

Charles,

Ram

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 09:54:36 -0400

Additional use case is recording in local bank branches, where customer walk-in to the local branch and talk to his account manager. This conversion should be recorded for legal compliance and the best way is to use desktop phone in speaker mode to record it via remote SRS.

Leon

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 25 Jul 2011 23:28:37 +0530

Leon/Charles,

CS has 2 participants in all the mentioned scenario.  Some of the
scenarios has one of the participant as automata participant (media
server). The open question is in case SRC & SRS are co-located whether
SIPREC RS mechanism has to be followed or not. 

In case of voicemail, studio recording, and desktop recording, SRC is
co-located with SRS, SRC is the automata participant in the scenario and
remote UA initiates the recording in CS. IMO, SIPREC RS mechanism and
metadata delivery are not required in case SRC & SRS are co-located but
SIPREC CS infrastructure (recordpref) may be used for initiating
recording but needs more discussion.

It is possible to view voicemail client, studio recording client or
desktop recording client as SRC. Here, there is no CS creation by these
clients but media input from devices are passed across in RS which is
not proper as per SIPREC architecture. In case no CS creation, what is
the need for metadata passing? Please correct me in case I'm missing
something here.

Thanks
Partha

> From: Leon Portman [mailto:[email-masked]] 
> Sent: Monday, July 25, 2011 7:25 PM
> To: Michael Baj
> Cc: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); 
> Parthasarathi R (partr); [email-masked]
> Additional use case is recording in local bank branches, 
> where customer walk-in to the local branch and talk to his 
> account manager. This conversion should be recorded for legal 
> compliance and the best way is to use desktop phone in 
> speaker mode to record it via remote SRS.
> 
> Leon
> 
> > For the record, I have come around on my initial argument 
> about the need for a CS with a single participant for the 
> blind transfer refer scenario.  I plan on implementing this 
> as a CS originally with 2 participants, then going  to 3 
> participants, and then terminating the CS when party UA-C 
> never answers or rejects the INVITE, as per Partha's explanation.
> > 
> > Mike
> > 
> > To: Charles Eckel (eckelcu); Parthasarathi R (partr); 
> [email-masked]; 
> > Michael Baj
> >>>> However since there is no media streams(as Paul 
> mentioned), there 
> >>>> will be no recording done. An SRC (could be potentially a 
> >>>> persistent RS) may still report a metadata having just one 
> participants 
> >>>> for a CS ?
> >>> <Partha> New CS (CS1) has to be created between UA-A & 
> UA-C. In case
> >> you
> >>> as part of CS and remove UA-B upon receiving BYE. In both 
> mechanism,
> >> CS
> >>> persistent RS connection having one participant. Here one 
> of the UA
> >> is
> >>> to pass this information. ISTM, your scenario is somewhat 
> related to
> >> it.
> >>> 
> >>> </Partha>
> >>>

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 21:03:43 +0300

Partha Hi

For My example below, metadata can include account manager and customer identities as participants, and time information.

Leon

Sent from my iPad

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Jul 2011 11:11:19 -0700

Let me try to demonstrate using the diagrams in the architecture draft/

                                             +-----------+
                          (Recording Session) |  Session  |
                             +----SIP-------->| Recording |
                             |                |  Server   |
                             |   +----RTP---->|  (SRS)    |
                             |   |            +-----------+
                             V   |                   ^
                        +-------------+              |
                        |             |              |
                        |             |--- MetaData -+
                        |             |
                        |    B2BUA    |
                        |             |
                        |   Session   |
     +--------+         |  Recording  |         +---------+
     |        |<- SIP ->|   Client    |<- SIP ->|         |
     |  UA-A  |         |   (SRC)     |         |  UA-B   |
     |        |<- RTP ->|             |<- RTP ->|         |
     +--------+         |             |         +---------+
                        +-------------+
      (Communication Session)        (Communication Session)

          Figure 1: B2BUA Acts as the Session Recording Client.

In this case, I was thinking we would have one CS with two participants,
UA-A and UA-B. 
Alternatively, you could have two CSs, one with UA-A and B2BUA, and
another with UA-B and B2BUA. 

          (Recording Session) +-----------+
         +----------SIP------>|           |
         |  +-------RTP------>|  Session  |
         |  |                 | Recording |
         |  |                 +  Server   |
         |  | +-- Metadata -->|   (SRS)   |
         |  | |               |           |
         |  | |               +-----------+
         |  | |
         |  | |
         |  | |
         |  | |
         V  | |  (Communication Session)
      +--+------+                     +---------+
      |         |<-------SIP--------->|         |
      |  UA-A   |                     |  UA-B   |
      |  (SRC)  |<-------RTP--------->|         |
      +---------+                     +---------+

In this case, I was thinking we would have one CS with two participants,
UA-A and UA-B. 
Next, I was thinking of the case in which UA-B is trying to record
itself (i.e. a professor recording a presentation to make available for
students for watch at a later time.
In this case, UA-A is not contributing anything to the recording. I was
thinking we would have one CS with one participant, UA-B. 
Alternatively you could have two participants, UA-A and UA-B, or UA-B
and SRC where SRC is some special type of participant that is recognized
by the SRS are facilitating the recording. 
I prefer having a single participant in this case. Otherwise, the SRS
will not be able to distinguish between a silent participant and a
SRC-participant that is an artifact of the metadata model.

Cheers,
Charles

> From: Michael Baj [mailto:[email-masked]]
> Sent: Sunday, July 24, 2011 10:49 PM
> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Parthasarathi R
(partr); [email-masked]
> For the record, I have come around on my initial argument about the
need for a CS with a single
> participant for the blind transfer refer scenario.  I plan on
implementing this as a CS originally
> with 2 participants, then going  to 3 participants, and then
terminating the CS when party UA-C never
> answers or rejects the INVITE, as per Partha's explanation.
> 
> Mike
> 
> > > <Partha> New CS (CS1) has to be created between UA-A & UA-C. In
case
mechanism,
> > > persistent RS connection having one participant. Here one of the
UA
> > > to pass this information. ISTM, your scenario is somewhat related
to
> > > > > > From: [email-masked]
[mailto:[email-masked]]
> > On

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 26 Jul 2011 00:06:40 +0530

Charles,

Please look into the below architecture for detailed explanation of my
understanding:

      |SRC      |                     |         |
      +---------+                     |         |
      |  UA-A   |<-------SIP--------->|  UA-B   |

I have raised the issue with architecture during first interim after
IETF-80 but haven't followed up because there is no open issue related
to it. In the above architecture, SRC & UA-A are co-located but they are
two different UA instance with different behavior. UA-A to UA-B creates
CS whereas SRC to SRS creates RS and passes metadata. The point is that
SRC is a logical entity which shall be co-located or located somewhere
in the path of the session (Ex: Your B2BUA architecture). 

In case UA-B (professor) initiates recording, SRC shall record with the
information that professor & students (UA-A) are involved in the
session. IIUC, professor (UA-B) & student (UA-A) are co-located in the
single device in the mentioned scenario and there is no CS creation but
recording has to happen. I'm not very sure whether it has to be scoped
within SIPREC RS & metadata.

Please read inline.

Thanks
Partha

> Sent: Monday, July 25, 2011 11:41 PM
> To: Michael Baj; Ram Mohan R (rmohanr); Parthasarathi R 
> (partr); [email-masked]
> In this case, I was thinking we would have one CS with two 
> participants, UA-A and UA-B. 
<partha> Agreed </partha>

> Alternatively, you could have two CSs, one with UA-A and 
> B2BUA, and another with UA-B and B2BUA. 
<partha> Here, both two CS will record twice (UA-A & B2BUA-A callleg as
one recording and UA-B & B2BUA-B callleg as another recording). Hope, it
is not your intent. </partha>

> In this case, I was thinking we would have one CS with two 
> participants, UA-A and UA-B. 
> Next, I was thinking of the case in which UA-B is trying to 
> record itself (i.e. a professor recording a presentation to 
> make available for students for watch at a later time.
> In this case, UA-A is not contributing anything to the 
> recording. I was thinking we would have one CS with one 
> participant, UA-B. 
<partha> The metadata is designed from the signaling perspective. Your
question is whether the participant is slient throughout the session or
not. It will be evident in case SDP indicates as "sendonly" from UA-B
which will be passed across in SRC to SRS on behalf of UA-B. </partha> 

> Alternatively you could have two participants, UA-A and UA-B, 
> or UA-B and SRC where SRC is some special type of participant 
> that is recognized by the SRS are facilitating the recording. 
> I prefer having a single participant in this case. Otherwise, 
> the SRS will not be able to distinguish between a silent 
> participant and a SRC-participant that is an artifact of the 
> metadata model.
> 
> Cheers,
> Charles
> 
> > need for a CS with a single participant for the blind 
> transfer refer 
> > scenario.  I plan on implementing this as a CS originally with 2 
> > participants, then going  to 3 participants, and then 
> terminating the CS when party UA-C never answers or rejects 
> the INVITE, as per Partha's explanation.
> > 
> > Mike
> > 
> > > studio mode recording in which someone is recording themselves as 
> > > the only participant. One way this could be accomplished 
> by a SIP UA 
> > > thought I brought this use case and issue up previously. 
> I can try 
> > > to find the thread in the archives if required or helpful.
> > > participant in the RS. I could see this being useful in 
> some cases,
> > but
> [mailto:[email-masked]] On
> > > > I'm not against having 1 participant per CS but still I'm not 
> > > > fully convinced for the given scenario.
> > > >
> > > > In the metadata model, CS does not have dialog state and 
> > > > established state is not prerequisite. Please read inline for 
> > > > further comments
> > > about
> > > > your scenario.
> > > >
> > > > Thanks
> > > > Partha
> > > >
> > > > > there will be no recording done. An SRC (could be 
> potentially a 
> > > > > > If we look at a blind transfer handled from a UA, 
> SIPREC could
> > be
> > > > > faced
> > > > > > > UA-A INVITES UA-B, UA-B REFERS UA-A to UA-C, UA-B 
> sends BYE
> > > after
> > > > > 202
> > > > <Partha> I'm not very sure about scenario. Some of the 
> possibility
> > > which
> > > > I could think of:
> > > >
> > > > 1) REFER returns with 4xx, UA-B will not terminate the 
> session and
> > > so,
> > > > means to indicate this failure to terminated dialog 
> between UA-B &
> > > UA-A.
> > > > > > But yes, there is an issue of how to report this 
> transitional
> > > state.
> > > > > >
> > > > > > I have no problem with allowing a CS to have 1, or 
> even zero, 
> > > > > > participants.
> > > > > >
> > > > > > 	Thanks,
> > > > > > 	Paul
> > > > > >
> > > > > > > Thanks,
> > > > > > > Mike
> > > > > > >
> > > > > > > Thanks for the closure of minimum 2 participant 
> per CS open
> > > item.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Partha
> > > > > > >
> > > > > > >>>>>> [JRE] I am not aware of a use case - I just feel 
> > > > > > >>>>>> slightly uncomfortable. Leave it for now.
> > > > > > >>>>>>
> > > > > > >>>>> <Partha>  Let us track this as an open item 
> for IETF-81
> > and
> > > > > > >>>> explore the
> > > > > > >>>>> possibility</Partha>
> > > > > > >>>>
> > > > > > >>>>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 26 Jul 2011 00:07:20 +0530

Hi Leon,

Please let me know the CS for the mentioned scenario.

Thanks
Partha 

> Sent: Monday, July 25, 2011 11:34 PM
> To: Parthasarathi R (partr)
> Cc: Michael Baj; Ram Mohan R (rmohanr); Charles Eckel 
> (eckelcu); <[email-masked]>
> For My example below, metadata can include account manager 
> and customer identities as participants, and time information.
> 
> Leon
> 
> Sent from my iPad
> 
> > co-located with SRS, SRC is the automata participant in the 
> scenario 
> > and remote UA initiates the recording in CS. IMO, SIPREC RS 
> mechanism 
> > and metadata delivery are not required in case SRC & SRS are 
> > co-located but SIPREC CS infrastructure (recordpref) may be 
> used for 
> > initiating recording but needs more discussion.
> > 
> > desktop recording client as SRC. Here, there is no CS creation by 
> > these clients but media input from devices are passed across in RS 
> > which is not proper as per SIPREC architecture. In case no CS 
> > creation, what is the need for metadata passing? Please 
> correct me in 
> > case I'm missing something here.
> > 
> > Thanks
> > Partha
> > 
> >> Additional use case is recording in local bank branches, where 
> >> customer walk-in to the local branch and talk to his 
> account manager. 
> >> This conversion should be recorded for legal compliance 
> and the best 
> >> way is to use desktop phone in speaker mode to record it 
> via remote 
> >> SRS.
> >> 
> >> Leon
> >> 
> >> about the need for a CS with a single participant for the blind 
> >> transfer refer scenario.  I plan on implementing this as a CS 
> >> originally with 2 participants, then going  to 3 participants, and 
> >> then terminating the CS when party UA-C never answers or 
> rejects the 
> >> INVITE, as per Partha's explanation.
> >>> 
> >>> Mike
> >>> 
> >> established
> >>>>> state is not prerequisite. Please read inline for 
> further comments
> >>>> about
> >>>>> your scenario.
> >>>>> 
> >>>>> Thanks
> >>>>> Partha
> >>>>>

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 14:42:54 -0400

It is non SIP CS between customer and account manager. It is face to face recording

Sent from my iPhone

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 26 Jul 2011 00:17:42 +0530

Leon,

Non-SIP CS is outside the scope of SIPREC as per the requirement & architecture document.

Definition of CS is as follows:
Communication Session (CS):  A SIP session created between two or
   more UA's for the purpose of communication which may be recorded.

I have raised some scenario related to non-SIP CS earlier, I have got back the same answer :-)

Thanks
Partha 

> Sent: Tuesday, July 26, 2011 12:13 AM
> >> Cc: Michael Baj; Ram Mohan R (rmohanr); Charles Eckel (eckelcu); 
> >> <[email-masked]>
> >> For My example below, metadata can include account manager and 
> >> customer identities as participants, and time information.
> >> 
> >> Leon
> >> 
> >> Sent from my iPad
> >> 
> >>>>>>> <Partha> It is the easiest implementation for SRC as 
> I mentioned
> >>>>>> earlier
> >>>>>>> </Partha>
> >>>>>>>

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 14:53:42 -0400

Right, however today such use case is supported by creating dummy SIP call to an ivr that does not do anything. So it is a SIP CS

Sent from my iPhone

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 26 Jul 2011 00:26:27 +0530

Ivr is dummy (automata) participant :-)

> Sent: Tuesday, July 26, 2011 12:24 AM
> Right, however today such use case is supported by creating 
> dummy SIP call to an ivr that does not do anything. So it is a SIP CS
> 
> Sent from my iPhone
> 
> > I have raised some scenario related to non-SIP CS earlier, 
> I have got 
> > back the same answer :-)
> > 
> > Thanks
> > Partha
> > 
> >> It is non SIP CS between customer and account manager. It 
> is face to 
> >> face recording
> >> 
> >> Sent from my iPhone
> >> 
> >>>>>>>>> Definition of communication session as per SIPREC 
> requirement
> >>>>>>>> document
> >>>>>>>>> is:
> >>>>>>>>> 
> >>>>>>>>> "Communication Session (CS): A session created 
> between two or
> >>>>>>> more
> >>>>>>>>> SIP
> >>>>>>>>>>>> UA-A INVITES UA-B, UA-B REFERS UA-A to UA-C, 
> UA-B sends BYE
> >>>>>>>> after
> >>>>>>>>>> 202
> >>>>>>>>> alternative is that CS shall add UA-C upon REFER 
> because it is
> >>>>>>>> consider
> >>>>>>>>> always connected with SRS using RS and it will not 
> represented
> >>>>>>>> because
> >>>>>>>>> there is no active CS. The conclusion is that 
> metadata is not
> >>>>>>>> required
> >>>>>>>>>>> There aren't any media streams to record. And 
> when there are
> >>>>>>>> media

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Jul 2011 15:19:49 -0700

> From: Parthasarathi R (partr)
> Sent: Monday, July 25, 2011 2:37 PM
> To: Charles Eckel (eckelcu); 'Michael Baj'; Ram Mohan R (rmohanr);
[email-masked]'
>          |  | +-- Metadata -->|   (SRS)   |
IETF-80 but haven't followed up
> because there is no open issue related to it. In the above
architecture, SRC & UA-A are co-located but
> they are two different UA instance with different behavior. UA-A to
UA-B creates CS whereas SRC to SRS
> creates RS and passes metadata. The point is that SRC is a logical
entity which shall be co-located or
> located somewhere in the path of the session (Ex: Your B2BUA
architecture).

UA-A and SRC being independent, co-located UAs or a single UA is an
implementation decision and I think you will see implementations of each
approach.
 
> In case UA-B (professor) initiates recording, SRC shall record with
the information that professor &
> students (UA-A) are involved in the session. IIUC, professor (UA-B) &
student (UA-A) are co-located in
> the single device in the mentioned scenario and there is no CS
creation but recording has to happen.

That is not my use case. My use case is a professor with zero students.
There is just the professor and the collated UA/SRC you mentioned
previously.

Cheers,
Charles

> I'm not very sure whether it has to be scoped within SIPREC RS &
metadata.
> <partha> Here, both two CS will record twice (UA-A & B2BUA-A callleg
as one recording and UA-B &
> B2BUA-B callleg as another recording). Hope, it is not your intent.
</partha>
> <partha> The metadata is designed from the signaling perspective. Your
question is whether the
> participant is slient throughout the session or not. It will be
evident in case SDP indicates as
> "sendonly" from UA-B which will be passed across in SRC to SRS on
behalf of UA-B. </partha>
> > > > >    "Communication Session (CS): A session created between two
or
> > > > > > > > I think there is a problem with the 2 participant
minimum
> > > > > > for a CS.
> > > > > <Partha> It is the easiest implementation for SRC as I
mentioned
> > > > > > > There aren't any media streams to record. And when there
are

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 26 Jul 2011 07:31:56 +0530

Charles,

<snip>
> the information that professor & students (UA-A) are involved in the 
recording has to happen.

</snip>

Your mentioned scenario is discussed with Leon in another mail thread
(http://www.ietf.org/mail-archive/web/siprec/current/msg02371.html).
IMO, it is outside the scope of SIPREC as it is non-SIP CS. Please let
me know your opinion on the same.

Thanks
Partha

> Sent: Tuesday, July 26, 2011 3:50 AM
> To: Parthasarathi R (partr); 'Michael Baj'; Ram Mohan R 
> (rmohanr); [email-masked]'
> > To: Charles Eckel (eckelcu); 'Michael Baj'; Ram Mohan R 
> (rmohanr); [email-masked]'
> > Please look into the below architecture for detailed 
> explanation of my understanding:
> > 
> > to it. In the above architecture, SRC & UA-A are co-located 
> but they 
> > are two different UA instance with different behavior. UA-A to UA-B 
> > creates CS whereas SRC to SRS creates RS and passes 
> metadata. The point is that SRC is a logical entity which 
> shall be co-located or located somewhere in the path of the 
> session (Ex: Your B2BUA architecture).
> 
> UA-A and SRC being independent, co-located UAs or a single UA 
> is an implementation decision and I think you will see 
> implementations of each approach.
>  
> > the information that professor & students (UA-A) are 
> involved in the 
> > session. IIUC, professor (UA-B) & student (UA-A) are 
> co-located in the single device in the mentioned scenario and 
> there is no CS creation but recording has to happen.
> 
> That is not my use case. My use case is a professor with zero 
> students. There is just the professor and the collated UA/SRC 
> you mentioned previously.
> 
> Cheers,
> Charles
> 
> > I'm not very sure whether it has to be scoped within SIPREC 
> RS & metadata.
> > 
> > Please read inline.
> > 
> > Thanks
> > Partha
> > 
> > > To: Michael Baj; Ram Mohan R (rmohanr); Parthasarathi R (partr); 
> > > [email-masked]
> > as one recording and UA-B & B2BUA-B callleg as another recording). 
> > Hope, it is not your intent. </partha>
> > 
> > >
> > >
> > > itself (i.e. a professor recording a presentation to make 
> available 
> > > for students for watch at a later time.
> recording. I 
> > > was thinking we would have one CS with one participant, UA-B.
> > question is whether the participant is slient throughout 
> the session 
> > or not. It will be evident in case SDP indicates as "sendonly" from 
> > UA-B which will be passed across in SRC to SRS on behalf of UA-B. 
> > </partha>
> > 
> > > Alternatively you could have two participants, UA-A and UA-B, or 
> > > UA-B and SRC where SRC is some special type of 
> participant that is 
> > > recognized by the SRS are facilitating the recording.
> > > I prefer having a single participant in this case. Otherwise, the 
> > > SRS will not be able to distinguish between a silent 
> participant and 
> > > a SRC-participant that is an artifact of the metadata model.
> > >
> > > Cheers,
> > > Charles
> > >
> > > > To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); 
> Parthasarathi 
> > > > For the record, I have come around on my initial argument about 
> > > > the need for a CS with a single participant for the blind
> > > transfer refer
> > > terminating the CS when party UA-C never answers or rejects the 
> > > > > studio mode recording in which someone is recording 
> themselves 
> > > > > as the only participant. One way this could be accomplished
> > > by a SIP UA
> > > > > initiating a communication session with the SRC, or 
> vice versa. 
> > > > > I thought I brought this use case and issue up previously.
> > > I can try
> between two 
> mentioned), 
> > > > > > > > > UA-A INVITES UA-C, UA-C Responds with 180 
> RINGING for X
> > > > > seconds,
> > > > > > <Partha> New CS (CS1) has to be created between 
> UA-A & UA-C. 
> > > > > > In case
> > > > > you
> > > > > > FYI: Another interesting scenario brought up 
> earlier related 
> > > > > > to persistent RS connection having one participant. Here
> > > one of the
> > > > > > UA
> > > > > is
> > > > > > > > Well, the CS isn't very interesting while it 
> has only one
> > > > > > > participant.
> when there 
> [mailto:[email-masked]]
> > > > > > > > >>> As you mentioned, it was discussed during 
> IETF-80 with
> > > > > > > different
> > > > > > > > >>> with minimum 2 participant. I have asked 
> this item to
> > > > > > > be re-opened
> > > > > > > > >>> because John is slightly uncomfortable and expects 
> > > > > > > > >>> more opinion/usecase.
> > > > > > > > >>>> A comment on this- In the current model 
> Each CS class
> > > > > > > has atleast

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 22:32:52 -0400

Charles - comments inline

> Let me try to demonstrate using the diagrams in the architecture draft/

Yes, this is probably the way most would like to see this represented.

> another with UA-B and B2BUA.

You could. But then I think you have the SRC as participant in each. And 
that seems a bit weird since the SRC is adding nothing to the conversation.

It might not make any difference. That will ultimately depend on the 
retrieval interface to the SRS, and how it presents all of this stuff.

>           |  | +-- Metadata -->|   (SRS)   |

Yes, that is what I would expect.

> students for watch at a later time.

Well, when I see that picture the thing that came to my mind is two 
"regular" UAs, one of which wants the call recorded and so decides to 
act as an SRC to accomplish that.

For your case, how would it be established? I guess it must be the 
professor calling from UA-B to UA-A which happens to act as a recorder. 
I don't know how it would know to do that. Perhaps an AOR dedicated to 
that function? Or more likely its an IVR that presents some options, 
much as a VM server does. (It could actually be an enhanced VM server.) 
In that case UA-A does provide media, though probably media that it 
doesn't choose to record.

> thinking we would have one CS with one participant, UA-B.

Or you could have a CS with two participants, but a media stream with 
only a sender and no receiver.

> by the SRS are facilitating the recording.

I would *hope* that the SRS doesn't have to know such stuff - that it 
can function with what it is *told* by the SRC.

> SRC-participant that is an artifact of the metadata model.

Does it matter?

In the case you cite, the recording is probably just raw material for 
preparing a presentation for students. It will need subsequent editing 
to make it ready. That can strip out any artifacts of the silent 
participant. (If there are any.)

	Thanks,
	Paul

> the
>>>>> participant with no<send>  or<recv>  streams.
>>>>>
>>>> <Partha>  Here, CS between UA-A&  UA-B is terminated and so, no
>>>> participant</Partha>
>>>>
>>>> <Partha>  Here, new CS between UA-A&  UA-B has to be created
>> </Partha>
>>>>
>>>>> UA-A
>>>> <Partha>  New CS (CS1) has to be created between UA-A&  UA-C. In
> case
>>> you
>>>> wish to group both CS&  CS1, Communication group (CSG) has to be
>>>> means to indicate this failure to terminated dialog between UA-B&
>>> UA-A.
>>>> Some extra service logic has to be created between UA-A&  UA-B to
>>>> In any scenario, atleast two participant involved</Partha>
>>>>
>>>>>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 08:35:14 -0700

> Sent: Monday, July 25, 2011 10:02 PM
[email-masked]'
> > session. IIUC, professor (UA-B) & student (UA-A) are co-located in
the single device in the
> mentioned scenario and there is no CS creation but recording has to
happen.
> That is not my use case. My use case is a professor with zero
students. There is just the professor
> and the collated UA/SRC you mentioned previously.
> </snip>
> 
(http://www.ietf.org/mail-
> archive/web/siprec/current/msg02371.html). IMO, it is outside the
scope of SIPREC as it is non-SIP CS.
> Please let me know your opinion on the same.

Hi Partha, I do not agree. I my use case, it is definitely a SIP CS. The
CS is between the professor and the UA/SRC. I will to clarify in
response to Paul's response.

Thanks,
Charles
 
> Parth

a
the
about
> > > > > > > > [mailto:[email-masked]] On Behalf Of Ram Mohan
R
> > > > > (rmohanr)
> > > > > > > <Partha> Here, new CS between UA-A & UA-B has to be
created
> > > > > > > 2) INVITE towards UA-C from UA-A (new CS) fails, there is
no
> > > > > standard
> > > > > > > > > >>>> less than 2 participants.  Is there a need to
track
> > > > > > > > this as open
> > > > > > > > > >>>> Let me know so that I can add this to slide deck
as
> > > > > > > > open item if

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 08:52:15 -0700

Paul, please see in-line.

Behalf Of Paul Kyzivat
> Sent: Monday, July 25, 2011 10:33 PM
> To: [email-masked]
participants,
> Yes, this is probably the way most would like to see this represented.

Great, me too.

> that seems a bit weird since the SRC is adding nothing to the
conversation.

Agreed, and that leads to my point later in this thread.
 
> >           |  | +-- Metadata -->|   (SRS)   |
participants,
> Yes, that is what I would expect.

Great. Me too.

> act as an SRC to accomplish that.

Yes, that is the general case. But not the studio mode recording case. I
think it may be worthwhile to distinguish between the two.
 
> doesn't choose to record.

Exactly. A specific URL, perhaps [email-masked] and
[email-masked] is given out to each person. If I dial
[email-masked], the SRC registered for
[email-masked] receives the SIP INVITE and a SIP dialog
(CS) is created between myself and the SRC. The SRC knows it is supposed
to record this on my behalf, so it creates an RS for the CS. I think it
makes more sense for the CS to have a single participant, me. The SRC
could include itself in the CS, but that seems a bit strange and would
be confused with the more general case in which the SRC is collocated
with a UA that is actively participating in the CS and that is also
acting as the SRC.

I believe you and Partha are both recommending this studio recording
case is handled as a CS with two participant where one just happens to
be an automaton this is silent rather than one that is a real person or
a actively participating automaton.
Also consider the case of a conference bridge acting as an SRC. When the
first person dialing into the conference bridge, is there a CS with two
participants, the first caller and the conference bridge? What about
before the first caller joins, is that a CS with two participants, the
conference bridge and the conference bridge. Or is there no CS at that
point?
In general, I do not see why we would want to restrict a CS to having
any specific number of participants.

> only a sender and no receiver.

Yes, you could, but what is the benefit of forcing the representation?
 
> > Alternatively you could have two participants, UA-A and UA-B, or
UA-B
> can function with what it is *told* by the SRC.

Me too. Let the SRC decide how to represent it.

> > I prefer having a single participant in this case. Otherwise, the
SRS
> participant. (If there are any.)

I hope that post processing is not required. I want the SRS to be able
to output something that is usable in real-time.

Cheers,
Charles
 
[email-masked];
> >>> participant in the RS. I could see this being useful in some
cases,
> >>>> state is not prerequisite. Please read inline for further
comments
possibility
> >>> which
> >>>> I could think of:
> >>>>
> >>>> 1) REFER returns with 4xx, UA-B will not terminate the session
and

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 12:20:33 -0400

> a actively participating automaton.

Yup, that's the only logical construct, IMO.  A "user" in the SIP sense does not mean a human being.  It's just a UA (or arguably an AoR instance in that UA).  If there is a UAC and a UAS, then there are two UA's - two "users", even if one of them is "sip:[email-masked]".

The real question I guess then is what you guys mean when you use the word "participant".  It's not defined anywhere, afaict, other than indirectly through the metadata draft by describing its entry in the xml.  I assume it does not mean human being, since SIP and RTP have no way to detect when a human being is present on the other end. ;)

> participants, the first caller and the conference bridge?

Yes.

> What about

There is a CS, because there is a SIP session between the caller and the bridge.  The caller is the UAC, the bridge is the UAS.

-hadriel

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 21:09:37 -0700

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 12:21 PM
> To: Charles Eckel (eckelcu)
> Cc: Paul Kyzivat; [email-masked]
> Yup, that's the only logical construct, IMO.  A "user" in the SIP
sense does not mean a human being.
> It's just a UA (or arguably an AoR instance in that UA).  If there is
a UAC and a UAS, then there are
> two UA's - two "users", even if one of them is
"sip:[email-masked]".
> 
> The real question I guess then is what you guys mean when you use the
word "participant".  It's not
> defined anywhere, afaict, other than indirectly through the metadata
draft by describing its entry in
> the xml.  I assume it does not mean human being, since SIP and RTP
have no way to detect when a human
> being is present on the other end. ;)

I think others share your opinion. I still think it could be valuable to
not force the SRC to indicate itself as a participant.
 
> There is a CS, because there is a SIP session between the caller and
the bridge.  The caller is the
> UAC, the bridge is the UAS.

But what about when this is not a caller (i.e. the first caller has not
joined, or no callers are left.)
Defining what constitutes a participant, as you suggested, might help.

Cheers,
Charles

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 21:54:38 +0200

In addition to what Hadriel and Charles say, another consideration is what if you have, in XML, a Session element with fewer than two Participant elements pointing at it? Do we really need to treat this as an error case, or just accept that it is a valid case (be liberal in what you accept)?

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 26 July 2011 17:21
> Cc: [email-masked]
> Yup, that's the only logical construct, IMO.  A "user" in the 
> SIP sense does not mean a human being.  It's just a UA (or 
> arguably an AoR instance in that UA).  If there is a UAC and 
> a UAS, then there are two UA's - two "users", even if one of 
> them is "sip:[email-masked]".
> 
> The real question I guess then is what you guys mean when you 
> use the word "participant".  It's not defined anywhere, 
> afaict, other than indirectly through the metadata draft by 
> describing its entry in the xml.  I assume it does not mean 
> human being, since SIP and RTP have no way to detect when a 
> human being is present on the other end. ;)
> 
> 
> There is a CS, because there is a SIP session between the 
> caller and the bridge.  The caller is the UAC, the bridge is the UAS.
> 
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jul 2011 17:04:16 -0400

> In addition to what Hadriel and Charles say, another consideration is what if you have, in XML, a Session element with fewer than two Participant elements pointing at it? Do we really need to treat…

I've been harping on this for some time.
Giving up is not a useful strategy for a recorder - better to get as 
much as you can, if if things don't seem quite right.

(There may be exceptions - I gather there are some cases where it better 
to hang up on the caller if you can't record the call. We might need to 
investigate if we should report something from SRS to SRC that will 
allow that to happen.)

	Thanks,
	Paul