Subject: [siprec] Comment on SIPREC architecture

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

I have encountered the below architecture explanation often to
differentiation the multiple instance of UA in case SRC is co-located
with UA. In SIPREC architecture document, Could you please consider to
show SRC as a separate logical entity as shown below. 

Thanks
Partha

-----Original Message-----
From: Parthasarathi R (partr) 
Sent: Tuesday, July 26, 2011 12:07 AM
To: Charles Eckel (eckelcu); 'Michael Baj'; Ram Mohan R (rmohanr);
[email-masked]'
Subject: RE: [siprec] Review of metadata-03

Charles,

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

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

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

> -----Original Message-----
> From: Charles Eckel (eckelcu)
> Sent: Monday, July 25, 2011 11:41 PM
> To: Michael Baj; Ram Mohan R (rmohanr); Parthasarathi R (partr); 
> [email-masked]
> Subject: RE: [siprec] Review of metadata-03
> 
> 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.
<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>

> 
> 
>           (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. 
<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
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: [siprec] Review of metadata-03
> > 
> > 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,
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: Charles Eckel (eckelcu)
> > > Sent: Sunday, July 24, 2011 2:29 PM
> > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr); 
> [email-masked]; 
> > > Michael Baj
> > > Subject: RE: [siprec] Review of metadata-03
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] 
> [mailto:[email-masked]] On
> > > Behalf Of Parthasarathi R (partr)
> > > > Sent: Thursday, July 21, 2011 6:22 PM
> > > > To: Ram Mohan R (rmohanr); [email-masked]; Michael Baj
> > > > Subject: Re: [siprec] Review of metadata-03
> > > >
> > > > 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
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of Ram Mohan R
> > (rmohanr)
> > > > > Sent: Friday, July 22, 2011 12:25 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: [siprec] Review of metadata-03
> > > > >
> > > > > 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
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] 
> [mailto:[email-masked]]
> > On
> > > > > > Behalf Of Paul Kyzivat
> > > > > > Sent: Thursday, July 21, 2011 12:18 PM
> > > > > > To: [email-masked]
> > > > > > Subject: Re: [siprec] Review of metadata-03
> > > > > >
> > > > > > On 7/21/11 11:42 AM, Michael Baj wrote:
> > > > > > > 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)
> > > > <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>
> > > >
> > > > > UA-A
> > > > > > CANCELS INVITE to UA-C, CS ends.
> > > > > > >
> > > > > > > Questions:
> > > > > > > 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>
> > > >
> > > > > > > If not, then the CS has only one participant 
> after B leaves.
> > > Does
> > > > > > 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>
> > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > > 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
> > > > > > > _______________________________________________
> > > > > > > siprec mailing list
> > > > > > > [email-masked]
> > > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > siprec mailing list
> > > > > > [email-masked]
> > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > > _______________________________________________
> > > > > siprec mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > >
> > > > _______________________________________________
> > > > siprec mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Jul 2011 05:06:34 +0200

Hi Partha,

I am not sure what this adds to the architecture specification it seems to me that it is just an implementation decision whether to split UA in to two logical UA's or not. I expect that in the case of an endpoint acting as an SRC the most common implementation will be that it is a single logical UA but of course it could be split or decomposed in a number of ways.

What does it mean for the UA to be two separate logical entities would this mean that it has two different AOR's for example?

Regards
Andy

> Sent: 25 July 2011 22:14
> Cc: Hutton, Andrew
> Subject: Comment on SIPREC architecture
>

---

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

Hi Andy,

The need for separate logical entities for SRC is as follows:

1) Hope you agree that B2BUA has two instance of UA. In the basic call,
one UA instance acts UAC (incoming callleg) and other instance acts as
UAS (outgoing callleg). There are two dialogs established for basic
call.

In SIPREC solution with UA, SRC + CS UA are two instances of UA wherein
one instance acts as UAC or UAS for CS and another instance acts as UAC
for RS. 

2) CS UA has to create CS dialog as per RFC 3261 & its extensions
whereas SRC has to create RS dialog with SIPREC solution (SIP
enhancement with metadata).

3) The mail thread like below is well explained in case SRC is shown as
separate logical entity which illustrate the difference between CS & RS.

4) It will architectural change for UA to support SIPREC solution with
RS dialog creation as 
     a) Dialog aggregation required (CS & RS)
     b) Enhancement required in RTP architecture. Simple RTP endpoint
will not work in all the scenario.

The architecture changes are due to the introduction of separate new SRC
logical entity enhancement in UA.

5) AOR for CS is different from SRS AOR in RS. But normally SIP gateways
(SIP UA) supports multiple AOR. So, it is not of the bigger difference.

Thanks
Partha

> From: Hutton, Andrew [mailto:[email-masked]] 
> Sent: Tuesday, July 26, 2011 8:37 AM
> To: Parthasarathi R (partr); [email-masked]
> Subject: RE: Comment on SIPREC architecture
> 
> Hi Partha,
> 
> I am not sure what this adds to the architecture 
> specification it seems to me that it is just an 
> implementation decision whether to split UA in to two logical 
> UA's or not. I expect that in the case of an endpoint acting 
> as an SRC the most common implementation will be that it is a 
> single logical UA but of course it could be split or 
> decomposed in a number of ways.
> 
> What does it mean for the UA to be two separate logical 
> entities would this mean that it has two different AOR's for example?
> 
> Regards
> Andy
> 
> 
> 
> 
> > 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 
> > 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
> >
> > <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>
> >
> > >
> > >
> > > 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.
> 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 
> > > > 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
> > > 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
> > > > > initiating a communication session with the SRC, or 
> vice versa. 
> > > > > I thought I brought this use case and issue up previously.
> > > I can try
> > > > > >    "Communication Session (CS): A session created 
> between two
> > or
> > > > more
> > > > > > SIP
> > > > > > <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
> [mailto:[email-masked]]
> > > > > > > > >>> because John is slightly uncomfortable and expects 
> > > > > > > > >>> more opinion/usecase.

---

From: Michael Baj <[email-masked]>
Date: Tue, 26 Jul 2011 12:59:42 +0000

Partha,

I want to make sure I am understanding you correctly.  Are you saying that it is a requirement that when a B2BUA is acting as a SRC, it MUST create a RS with 2 CS, where one of the CS is between UA-A and the UAS-side of the B2B and the 2nd CS is between the UAC-side of the B2B and UA-B? This would result in 4 MS for each RS.

If that is a requirement, then I suggest that we loosen the restrictions.

Please clarify.

Thanks,
Mike

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Jul 2011 15:45:19 +0200

See some responses below.

My personal opinion is that there is no need for stating that SRC is two different logical UA's and actually it could be incorrect to do so. By stating they are separate entities we may give the impression that they should have different AOR's and therefore need separate registrations etc. which is not the case.

Anybody else have a view on this?

Regards
Andy

> Sent: 26 July 2011 02:24
> To: Hutton, Andrew; [email-masked]
[AndyH] - I agree although each instance is both UAC and UAS.

> one instance acts as UAC or UAS for CS and another instance acts as UAC
[AndyH] - Not really the UAC/UAS term refer only to the UA's role in a single transaction but I think I know what you are getting at.

> enhancement with metadata).

[AndyH] - The RS dialog is RFC 3261 with SIPREC extensions. A single UA uses many different SIP extensions on a per dialog basis for example consider a basic call against will a conference call we would not say that the UA that uses a conference event package is logically a different UA to that used when in a non conference call.

> logical entity enhancement in UA.

[AndyH] - How much of an architectural change it is to add SIPREC interface to an existing UA is I think implementation dependant and not something I think we should be concerned about.

> (SIP UA) supports multiple AOR. So, it is not of the bigger difference.
[AndyH] - Not sure I understand this but looks like you think AOR's are not the issue.

> > > > > > > > > There aren't any media streams to record. And when
> there
> > > are
> > > > > > media

---

From: Michael Baj <[email-masked]>
Date: Tue, 26 Jul 2011 13:55:58 +0000

Andy,

I am in agreement with your view.

Mike

---

From: Leon Portman <[email-masked]>
Date: Tue, 26 Jul 2011 17:03:26 +0300

+1

Leon

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2011 10:32:06 -0400

+1

On 7/26/11 9:55 AM, Michael Baj wrote:
>>> 2) CS UA has to create CS dialog as per RFC 3261&  its extensions
>>> separate logical entity which illustrate the difference between CS&
>>> RS.
>>>
>>>      a) Dialog aggregation required (CS&  RS)
>>>>> to it. In the above architecture, SRC&  UA-A are co-located
>>>> but they
>>>>> the information that professor&  students (UA-A) are
>>>> involved in the
>>>>> session. IIUC, professor (UA-B)&  student (UA-A) are
>>>> co-located in the
>>>>> scoped within SIPREC RS&  metadata.
>>>>>
>>>>> Please read inline.
>>>>>
>>>>> Thanks
>>>>> Partha
>>>>>
>>>>> <partha>  Agreed</partha>
>>>>> <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>
>>>>>
>>>>>>
>>>>>>
>>>>>>>>>> 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
>>>> UA-A&  UA-C.
>>>>>>>>> wish to group both CS&  CS1, Communication group (CSG)
>>>>>> has to be
>>>>>> between UA-B&
>>>>>>>>> In any scenario, atleast two participant involved</Partha>
>>>>>>>>>
>>>>>>>>>>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 26 Jul 2011 20:39:07 +0530

+1

Even I am in agreement with Andy's view here and there is NO need for
stating that SRC is two different logical UA's

Regards,
Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Baj
> Sent: Tuesday, July 26, 2011 9:56 AM
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] Comment on SIPREC architecture
> 
> Andy,
> 
> > My personal opinion is that there is no need for stating that SRC is
> two different logical UA's and actually it could be incorrect to do
so.
> By stating they are separate entities we may give the impression that
> they should have different AOR's and therefore need separate
> registrations etc. which is not the case.
> >
> > [AndyH] - Not really the UAC/UAS term refer only to the UA's role in
> a single transaction but I think I know what you are getting at.
> >
> >
> > [AndyH] - The RS dialog is RFC 3261 with SIPREC extensions. A single
> UA uses many different SIP extensions on a per dialog basis for
example
> consider a basic call against will a conference call we would not say
> that the UA that uses a conference event package is logically a
> different UA to that used when in a non conference call.
> >
> >>
> >> 3) The mail thread like below is well explained in case SRC is
shown
> as
> >> The architecture changes are due to the introduction of separate
new
> >> SRC
> > [AndyH] - How much of an architectural change it is to add SIPREC
> interface to an existing UA is I think implementation dependant and
not
> something I think we should be concerned about.
> >
> >>
> >>>> are two different UA instance with different behavior. UA-A to
UA-
> B
the

---

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

+1

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ram Mohan R (rmohanr)
> Sent: Tuesday, July 26, 2011 11:09 AM
> To: Michael Baj; Hutton, Andrew
> Cc: [email-masked]
> > >> one UA instance acts UAC (incoming callleg) and other instance
acts
> > >> one instance acts as UAC or UAS for CS and another instance acts
as
> > UAC
> > >> separate logical entity which illustrate the difference between
CS
> &
> > > [AndyH] - Not sure I understand this but looks like you think
AOR's
> > are not the issue.
> > >>> From: Hutton, Andrew
[mailto:[email-masked]]
> > >>>> but recording has to happen. I'm not very sure whether it has
to
or
the

---

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

Mike,

My point is that "B2BUA is not equal to B2BUA + SRC". Please look below:

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

As per communication session, it is not single dialog. Basic call in
B2BUA with two callleg (dialogs) helps create CS. There is need of third
callleg (dialog) for the creation of RS which I want to differentiate in
the architecture document. In case three dialogs involved in the basic
call, let the entity be spelt out explicitly as it involves different
RTP & SIP properties.

Thanks
Partha

> Sent: Tuesday, July 26, 2011 6:30 PM
> To: Parthasarathi R (partr)
> Cc: Hutton, Andrew; <[email-masked]>
> I want to make sure I am understanding you correctly.  Are 
> you saying that it is a requirement that when a B2BUA is 
> acting as a SRC, it MUST create a RS with 2 CS, where one of 
> the CS is between UA-A and the UAS-side of the B2B and the 
> 2nd CS is between the UAC-side of the B2B and UA-B? This 
> would result in 4 MS for each RS.
> 
> > 1) Hope you agree that B2BUA has two instance of UA. In the basic 
> > call, one UA instance acts UAC (incoming callleg) and other 
> instance 
> > acts as UAS (outgoing callleg). There are two dialogs 
> established for 
> > basic call.
> > 
> > In SIPREC solution with UA, SRC + CS UA are two instances of UA 
> > wherein one instance acts as UAC or UAS for CS and another instance 
> > acts as UAC for RS.
> > 
> > 3) The mail thread like below is well explained in case SRC 
> is shown 
> > as separate logical entity which illustrate the difference 
> between CS & RS.
> > 
> > The architecture changes are due to the introduction of 
> separate new 
> > SRC logical entity enhancement in UA.
> > 
> > 5) AOR for CS is different from SRS AOR in RS. But normally SIP 
> > gateways (SIP UA) supports multiple AOR. So, it is not of 
> the bigger difference.
> > 
> > Thanks
> > Partha
> > 
> > 
> > 
> >> I am not sure what this adds to the architecture specification it 
> >> seems to me that it is just an implementation decision whether to 
> >> split UA in to two logical UA's or not. I expect that in 
> the case of 
> >> an endpoint acting as an SRC the most common 
> implementation will be 
> >> that it is a single logical UA but of course it could be split or 
> >> What does it mean for the UA to be two separate logical entities 
> >> would this mean that it has two different AOR's for example?
> >> 
> >> Regards
> >> Andy
> >> 
> >> 
> >> 
> >>

---

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

Andy,

My understanding is inline with Sec 5 of
draft-portman-siprec-protocol-05 solution document and the related text
is "The From header must contain the identity of the SRC. Participants
information is not recorded in the From or To header; they are included
in the metadata information.". 

Infact it is possible to have two different AOR based on the deployment.
I'll explain with B2BUA + SRC deployment. CS shall have AOR like
"sip:[email-masked]" but SRC establishes RS with SRS using
"sip:[email-masked]". Here, CS always carries dialed number whereas SRC
AOR helps to identify the exact SRC. So if required for multiple
registration, we will go for it. Please let me know your issue in this
approach.

My concern is mainly towards RTP model (endpoint, translator, mixer)
selection between RS & CS. The separate entities helps to visualize the
selection of correct model. Also, it helps to differentiate CS-less
scenarios.

Thanks
Partha

> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: Tuesday, July 26, 2011 8:39 PM
> Even I am in agreement with Andy's view here and there is NO 
> need for stating that SRC is two different logical UA's
> 
> Regards,
> Ram
> 
> > call,
> > >> one UA instance acts UAC (incoming callleg) and other 
> instance acts
> > as
> > wherein
> > >> one instance acts as UAC or UAS for CS and another 
> instance acts as
> > UAC
> > >> for RS.
> > >>
> > >> separate logical entity which illustrate the difference 
> between CS
> &
> > >> RS.
> > >>
> > >> gateways (SIP UA) supports multiple AOR. So, it is not of the 
> > >> bigger
> > difference.
> > >>
> > > [AndyH] - Not sure I understand this but looks like you 
> think AOR's
> > are not the issue.
> > >
> > >
> > >> Thanks
> > >> Partha
> > >>
> > >>
> > >>
> specification it 
> > >>> split UA in to two logical UA's or not. I expect that 
> in the case 
> > >>> of an endpoint acting as an SRC the most common implementation 
> > >>> will be that it is a single logical UA but of course it 
> could be 
> > >>> split or decomposed in a number of ways.
> > >>>
> entities 
> > >>>> but recording has to happen. I'm not very sure whether 
> it has to
> > be

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2011 15:50:13 -0400

> My point is that "B2BUA is not equal to B2BUA + SRC". Please look below:

IMO it is up to the SRC how much of this configuration it wants to 
report to the SRS. Its also up to the implementer of this equipment how 
it wants to connect the pieces.

So, if it wants to implement this as two, or three, UAs and report them 
all as participants, it can do that. If it only wants to report A and B 
as participants, that is ok too.

	Thanks,
	Paul

> RTP&  SIP properties.
>> Cc: Hutton, Andrew;<[email-masked]>
>> between CS&  RS.

---

From: Michael Baj <[email-masked]>
Date: Tue, 26 Jul 2011 20:04:01 +0000

+1

On Jul 26, 2011, at 3:50 PM, Paul Kyzivat wrote:

> IMO it is up to the SRC how much of this configuration it wants to report to the SRS. Its also up to the implementer of this equipment how it wants to connect the pieces.
> 
> So, if it wants to implement this as two, or three, UAs and report them all as participants, it can do that. If it only wants to report A and B as participants, that is ok too.
> 
> 	Thanks,
> 	Paul
> 
>> 
>>                                               +-----------+

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 26 Jul 2011 23:47:16 +0200

See below.

> Sent: 26 July 2011 14:19
> To: Ram Mohan R (rmohanr); Michael Baj; Hutton, Andrew
> Cc: [email-masked]; Paul Kyzivat
> Subject: RE: [siprec] Comment on SIPREC architecture
>
> Andy,
>
[AndyH] This to me just means that the metadata fully describes the participants in the communication session. In the case when a SIP endpoint is acting as a SRC then it certainly could be that the From header identifies the same participant as is described in metadata but it is also ok if it does not.

> registration, we will go for it. Please let me know your issue in this

[AndyH] I have no issue with this approach it is an implementation decision but I don't think we need to explicitly describe it in the architecture document.

> selection of correct model. Also, it helps to differentiate CS-less

[AndyH] This will be discussed in the SIPREC meeting this week we still need to decide how to handle this.
> > > >> 4) It will architectural change for UA to support SIPREC
> solution
> > > with
> > > >> RS dialog creation as
> > > >>>> point is that SRC is a logical entity which shall be co-
> located
> > or

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 27 Jul 2011 09:08:23 +0530

Andy,

I agree with you for the first two points. 

<snip>

> selection between RS & CS. The separate entities helps to visualize 
> the selection of correct model. Also, it helps to differentiate 
> CS-less scenarios.

[AndyH] This will be discussed in the SIPREC meeting this week we still
need to decide how to handle this.
</snip>

I'm fine with the current approach as long as everyone feels
comfortable.

Thanks
Partha 

> Sent: Wednesday, July 27, 2011 3:17 AM
> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Michael Baj
> > draft-portman-siprec-protocol-05 solution document and the related 
> > text is "The From header must contain the identity of the SRC. 
> > Participants information is not recorded in the From or To header; 
> > they are included in the metadata information.".
> >
> [AndyH] This to me just means that the metadata fully 
> describes the participants in the communication session. In 
> the case when a SIP endpoint is acting as a SRC then it 
> certainly could be that the From header identifies the same 
> participant as is described in metadata but it is also ok if 
> it does not.
> 
> [AndyH] I have no issue with this approach it is an 
> implementation decision but I don't think we need to 
> explicitly describe it in the architecture document.
> 
> > selection between RS & CS. The separate entities helps to visualize 
> > the selection of correct model. Also, it helps to differentiate 
> > CS-less scenarios.
> 
> [AndyH] This will be discussed in the SIPREC meeting this 
> week we still need to decide how to handle this.
> >
> > Thanks
> > Partha
> >
> > > Even I am in agreement with Andy's view here and there is NO need 
> > > for stating that SRC is two different logical UA's
> > >
> > > Regards,
> > > Ram
> > >
> > > > two different logical UA's and actually it could be 
> incorrect to 
> > > > do
> > > so.
> > > > >> separate
> > > > >>>> I have encountered the below architecture 
> explanation often 
> > > > >>>> to differentiation the multiple instance of UA in 
> case SRC is
> > > > >>> co-located
> > > > >>>> are two different UA instance with different 
> behavior. UA-A 
> > > > >>>> to
> > > UA-
> > > > B
> > > > >>>> In case UA-B (professor) initiates recording, SRC shall 
> > > > >>>> record
> > > > with
> > > > >>>> or not. It will be evident in case SDP indicates 
> as "sendonly"
> > > > from
> > > > >>>>>>>>> [mailto:[email-masked]] On Behalf Of 
> Ram Mohan 
> > > > >>>>>>>>> R
> > > > >>>>>> (rmohanr)
> > > > >>>>>>>> 2) INVITE towards UA-C from UA-A (new CS) 
> fails, there is
> > > > >> no
> > > > >>>>>> standard

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 20:49:31 +0200

> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 26 July 2011 19:03
> To: Michael Baj
> Cc: [email-masked]
[JRE] I think the figure above would represent an improvement to figure 1 in the architecture document (i.e. showing SRC being attached to the B2BUA, rather than being another name for the B2BUA). One further improvement, however. A single CS extends from UA-A to UA-B. These are not two separate CSs - the B2BUA would treat them as a single CS for recording purposes.

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.

> > solution with
> > record with

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 20:50:05 +0200

> Sent: 26 July 2011 19:19
[JRE] I suspect it depends on where the SRC is located. If the SRC is collocated with the UA, it could reasonably have the same identifier as that of the UA itself, i.e., they could both share the first of the two AORs above. If the SRC is collocated with a B2BUA, I suspect it would have a different identifier, as Partha describes above. I would be quite happy to see in our figures the SRC sitting alongside whatever entity it is collocated with (UA or B2BUA) (I have separately commented on the B2BUA figure, figure 1). However, I don't think we need to state whether the SRC is a separate UA or not.

John (as individual)

John Elwell

> incorrect to do
> > > >> 4) It will architectural change for UA to support
> SIPREC solution
> > > with
> > > >> RS dialog creation as
> explanation often to
> behavior. UA-A to
> > > >>>> point is that SRC is a logical entity which shall be
> co-located
> > or
> > > >>>> In case UA-B (professor) initiates recording, SRC
> shall record
> > > with
> > > >>>> or not. It will be evident in case SDP indicates as
> "sendonly"
> > > from
> Ram Mohan R

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 27 Jul 2011 14:45:38 -0700

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Wednesday, July 27, 2011 2:50 PM
> To: Parthasarathi R (partr); Michael Baj
> Cc: [email-masked]
> Subject: [siprec] Change to architecture figure 1
> 
> 
> 
> [JRE] I think the figure above would represent an improvement to
figure 1 in the architecture document
> (i.e. showing SRC being attached to the B2BUA, rather than being
another name for the B2BUA). One
> further improvement, however. A single CS extends from UA-A to UA-B.
These are not two separate CSs -
> the B2BUA would treat them as a single CS for recording purposes.

It could, but it could also treat them as two CSs, as I mentioned
previously within this thread. I am not saying I prefer that model,
rather, I am saying that it is up to the B2BUA/SRC.

Cheers,
Charles
 
entities
> > > co-located or
> > > "sendonly" from

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jul 2011 00:20:09 +0200

> From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> Sent: 27 July 2011 22:46
> To: Elwell, John; Parthasarathi R (partr); Michael Baj
> Cc: [email-masked]
> Subject: RE: [siprec] Change to architecture figure 1
>
[JRE] Yes, I saw your earlier posting about treating them as two CSs, but I had hoped I had interpreted it wrongly. It seems not. I don't understand why the SRC would want to do that. It is only recording one set of media streams, i.e., media that flows from UA1 to UA2 and vice versa.

John (as individual)

> > Registered office: Brickhill Street, Willen Lake, Milton
> Keynes, MK15
> 0DJ.
> > > > >>>>>>>>> There aren't any media streams to record. And
> when there
> > > > >>> are
> > > > >>>>>> media

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 27 Jul 2011 20:45:42 -0700

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2011 6:20 PM
> To: Charles Eckel (eckelcu); Parthasarathi R (partr); Michael Baj
> Cc: [email-masked]
> [JRE] Yes, I saw your earlier posting about treating them as two CSs,
but I had hoped I had
> interpreted it wrongly. It seems not. I don't understand why the SRC
would want to do that. It is only
> recording one set of media streams, i.e., media that flows from UA1 to
UA2 and vice versa.

I agree. That is how I would prefer to model that case as well. However,
it would be okay to model as two CSs, one from UA1 to the B2BUA and
another from UA2 to the B2BUA. I cannot think of a good reason to model
it that way, but I do not think there is anything to prevent it.

Cheers,
Charles
 
> > > Siemens Enterprise Communications Limited is a Trademark Licensee
of
> > Siemens AG.
> > > > > >>>>                             |                |  Server
|
> > > > > >>>>                             |   +----RTP---->|  (SRS)
|
+-----------+

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jul 2011 00:13:15 -0400

> it that way, but I do not think there is anything to prevent it.

I think we can not tell from the topology whether the box in the middle 
that has the SRC plays a significant role that should be reflected to 
the SRS, or not.

So I think we just leave it to the SRC to decide this.
Else we need to make a bunch of normative architectural distinctions in 
order to be able to specify when the box with the SRC is visible, and 
when it is not.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:03:23 +0530

John,

I wish that the improvement (B2BUA + SRC) in figure-1 is incorporated in
the architecture document.

Hi all,

Apart for the figure stuff, I'm thinking on the same line of John
wherein single CS is reported for basic call in B2BUA by grouping two
callleg of basic call. I agree with Charles & Paul that there is nothing
preventing to have two CS for the basic call in B2BUA and it is not
possible to have normative statement to avoid it.

My question here is whether it is possible for the architecture document
to provide the guidelines as it is informational stuff. This helps to
avoid the misinterpretation of communication session definition
mentioned in SIPREC by implementers and also allows in case somebody
wants to purposefully implement innovative two CS for single session in
B2BUA + SRC. 

This grouping applies for conference as well because single conference
call shall be considered as single conference session or group of
sessions between focus & set of endpoints.

Thanks
Partha

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, July 28, 2011 9:43 AM
> To: [email-masked]
> Subject: Re: [siprec] Change to architecture figure 1
> 
> >> recording one set of media streams, i.e., media that flows 
> from UA1 
> >> to
> > UA2 and vice versa.
> >
> > I agree. That is how I would prefer to model that case as well. 
> > However, it would be okay to model as two CSs, one from UA1 to the 
> > B2BUA and another from UA2 to the B2BUA. I cannot think of a good 
> > reason to model it that way, but I do not think there is 
> anything to prevent it.
> 
> I think we can not tell from the topology whether the box in 
> the middle that has the SRC plays a significant role that 
> should be reflected to the SRS, or not.
> 
> Else we need to make a bunch of normative architectural 
> distinctions in order to be able to specify when the box with 
> the SRC is visible, and when it is not.
> 
> 	Thanks,
> 	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jul 2011 12:58:00 +0200

I think we are converging on agreement that treating it as a single CS is the "most likely" case. I would prefer to show that in figure 1.

I think if the SRC treats each leg as a separate CS, effectively the SRC is collocated with the UA for each CS, and that is covered by the other scenario figure. 

John (as individual)

> Sent: 28 July 2011 08:33
> To: Paul Kyzivat; [email-masked]
> Cc: Elwell, John; Charles Eckel (eckelcu)

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 28 Jul 2011 07:33:23 -0700

Fine with me. I think by virtue of the fact we label something as a
B2BUA, we indicate that, like it or not, it can and will be deployed in
ways resulting in solution doing anything and everything imaginable.
This includes, but is not limited to, representing the communication
between the two UAs as a single CS or multiple CSs.

Cheers,
Charles

> Sent: Thursday, July 28, 2011 6:58 AM
> To: Parthasarathi R (partr); Paul Kyzivat; [email-masked]
> Cc: Charles Eckel (eckelcu)
> I think we are converging on agreement that treating it as a single CS
is the "most likely" case. I
> would prefer to show that in figure 1.
> 
> I think if the SRC treats each leg as a separate CS, effectively the
SRC is collocated with the UA for
> each CS, and that is covered by the other scenario figure.
> 
> John (as individual)
> 
> > > >>>> further improvement, however. A single CS extends from UA-A
to
> > > > UA-B.

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 22:08:44 +0530

In case it is restricted not to name as B2BUA, it will be named as SBC
;-)

Cheers
Partha 

> Sent: Thursday, July 28, 2011 8:03 PM
> To: Elwell, John; Parthasarathi R (partr); Paul Kyzivat; 
> [email-masked]
> Fine with me. I think by virtue of the fact we label 
> something as a B2BUA, we indicate that, like it or not, it 
> can and will be deployed in ways resulting in solution doing 
> anything and everything imaginable. This includes, but is not 
> limited to, representing the communication between the two 
> UAs as a single CS or multiple CSs.
> 
> Cheers,
> Charles
> 
> > is the "most likely" case. I would prefer to show that in figure 1.
> > 
> > SRC is collocated with the UA for each CS, and that is 
> covered by the other scenario figure.
> > 
> > John (as individual)
> > 
> > > I wish that the improvement (B2BUA + SRC) in figure-1 is 
> > > incorporated in the architecture document.
> > >
> > > Hi all,
> > >
> > > wherein single CS is reported for basic call in B2BUA by grouping 
> > > two callleg of basic call. I agree with Charles & Paul 
> that there is 
> > > nothing preventing to have two CS for the basic call in 
> B2BUA and it 
> > > is not possible to have normative statement to avoid it.
> > >
> > > My question here is whether it is possible for the architecture 
> > > document to provide the guidelines as it is informational stuff. 
> > > This helps to avoid the misinterpretation of 
> communication session 
> > > definition mentioned in SIPREC by implementers and also allows in 
> > > case somebody wants to purposefully implement innovative 
> two CS for 
> > > single session in B2BUA + SRC.
> > >
> > > This grouping applies for conference as well because single 
> > > conference call shall be considered as single conference 
> session or 
> > > group of sessions between focus & set of endpoints.
> > >
> > > Thanks
> > > Partha
> > >
> > > > > B2BUA and another from UA2 to the B2BUA. I cannot think of a 
> > > > > good reason to model it that way, but I do not think there is
> > > > anything to prevent it.
> > > >
> > > > I think we can not tell from the topology whether the 
> box in the 
> > > > middle that has the SRC plays a significant role that should be 
> > > > reflected to the SRS, or not.
> > > >
> > > > distinctions in order to be able to specify when the 
> box with the 
> > > > SRC is visible, and when it is not.
> > > >
> > > > 	Thanks,
> > > > 	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Jul 2011 20:02:12 +0200

Don't understand. What is wrong with B2BUA? SBC is too specific.

John 

> Sent: 28 July 2011 17:39
> To: Charles Eckel (eckelcu); Elwell, John; Paul Kyzivat; 
> [email-masked]

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 29 Jul 2011 14:36:56 -0700

I certainly did not mean to imply that, and not sure if that is what
Partha meant. I think B2BUA is more appropriate than SBC.

Cheers,
Charles

> Sent: Friday, July 29, 2011 2:02 PM
> To: Parthasarathi R (partr); Charles Eckel (eckelcu); Paul Kyzivat;
[email-masked]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sun, 31 Jul 2011 23:04:07 +0530

I wish to mention as B2BUA only. I think that we are in agreement here.

Thanks
Partha

> Sent: Saturday, July 30, 2011 3:07 AM
> I certainly did not mean to imply that, and not sure if that 
> is what Partha meant. I think B2BUA is more appropriate than SBC.
> 
> Cheers,
> Charles
> 
> > > In case it is restricted not to name as B2BUA, it will be 
> named as 
> > > SBC
> > > ;-)
> > >
> > > Cheers
> > > Partha
> > >
> something as 
> > > > a B2BUA, we indicate that, like it or not, it can and will be 
> > > > deployed in ways resulting in solution doing anything and 
> > > > everything imaginable. This includes, but is not limited to, 
> > > > representing the communication between the two UAs as a 
> single CS 
> > > > or multiple CSs.
> > > >
> > > > Cheers,
> > > > Charles
> > > >
> > > > > > My question here is whether it is possible for the 
> > > > > > architecture document to provide the guidelines as it is
> > > informational stuff.
> > > > > > > >>> It could, but it could also treat them as two 
> CSs, as I
> > > > > > mentioned
> > > > > > > >>> previously within this thread. I am not 
> saying I prefer
> > > > > > > that model,
> > > > > > > >> [JRE] Yes, I saw your earlier posting about 
> treating them
> > > > > > > as two CSs,
> > > > > > > > but I had hoped I had
> > > > > > > >> interpreted it wrongly. It seems not. I don't 
> understand
> > > > > > > why the SRC