Subject: Re: [siprec] SIPREC metadata example comments

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 1 Apr 2014 23:53:05 +0530

Hi Finlay/Gerben,

Hope the below reply addresses your concern. 

Also, I'm interested in knowing whether you have any other issues related to
SIPREC metadata which has to be discussed before WGLC of the draft.

Thanks
Partha

> -----Original Message-----
> From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2014 5:18 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] SIPREC metadata example comments
> 
> Please see inline for some comments
> 
> -----Original Message-----
> From: "[email-masked]" <[email-masked]>
> Date: Tuesday, 11 March 2014 1:59 pm
> To: "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [siprec] SIPREC metadata example comments
> 
> >Partha
> >
> >Are you saying RFC4575 is mandatory package for SIPREC support and
> would
> >have to be available.
> 
> No. SIPREC does not mandate you to have RFC4575. It is up to the SRC
> (participant in the conference in this example) to learn the details of
> the other participant in the conference session before it sends
> snapshot
> of metadata to SRS. It may use RFC4575 method by subscribing to a
> conference focus or use some other means to get the details. We are not
> mandating to use RFC4575 only.
> 
> SIPREC only talks about how a SRC sends(the protocol semantics)
> metadata
> to SRS and semantics of metadata(XML schema). How SRC gets the
> information
> that fills up metadata is purely a application logic and IMO need not
> be
> defined in the on-wire protocol.
> 
> >
> >If not and there is no RFC4575 feed available how does the participant
> >know about all the other parties and their state if they are not sent
> in
> >the Metadata UPDATE
> >
> >Or have I missed the meaning of the paragraph
> >
> >On the use of groups in trading
> >
> >We have a use case where two communication sessions that are
> established
> >with one or more parties merge together to form a single call. We need
> a
> >way to tag all legs of the call to indicate this. To do this we
> propose
> >to use Group so the two CS will stay the same but both will now share
> a
> >group tag.
> 
> Yes. CS-group is specifically is meant for this purpose. If a
> application
> wants to link two CS¹s it can use this CS-group and tag them together.
> Your understanding is correct here.
> 
> Regards,
> Ram
> 
> >
> >Note it is also possible for merge calls to be merged. When this
> happens
> >a new group tag will be added.
> >In this way a VR can find original CS and be aware that it was merged
> and
> >from the merge tags it can locate all other parties in the call.
> >
> >If there is a better way to deal with this pleases let me know.
> >
> >
> >Finlay Fraser
> >Annandale House
> >1 Hanworth Road
> >Sunbury on Thames
> >TW16 5DJ
> >BT IP Tel: +44 (0)1932773310 | Mob: +44(0)7711860228 | E:
> >[email-masked]
> >________________________________________
> >From: siprec [[email-masked]] On Behalf Of Parthasarathi R
> >[[email-masked]]
> >Sent: 11 March 2014 00:33
> >To: [email-masked]
> >Cc: [email-masked]
> >Subject: [siprec] SIPREC metadata example comments
> >
> >Hi Gerben,
> >
> >In IETF-89 SIPREC meeting, you have mentioned about two issues related
> to
> >SIRPEC metadata
> >
> >1) Trading scenario wherein the participant added/removed very quickly
> as
> >it
> >is conference. Here the concern is that all participant are required
> to be
> >forwarded SRC to SRS whenever there is a change in participants.
> >
> ><Solution> Sec 3.3.3 of
> >http://tools.ietf.org/html/draft-ietf-siprec-callflows-02#page-24
> explains
> >how to add/remove participant without sending every participant.
> Please
> >let
> >me know in case you have any difficulties in using this solution.
> ></solution>
> >
> >2) Group is interpreted differently in trading scenario.
> >
> >Please look into Sec 3.5 of
> >http://tools.ietf.org/html/draft-ietf-siprec-callflows-02#page-28 as
> it
> >is a
> >trading scenario to understand the one of the possible usage with
> group.
> >Having said that, I'm not very clear about your problem statement.
> Please
> >clarify in case I didn't understand your concern.
> >
> >Thanks
> >Partha
> >
> >_______________________________________________
> >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: <[email-masked]>
Date: Wed, 2 Apr 2014 10:10:02 +0100

Thanks for getting back to us 

On the groups we are happy that this is a correct use.

On the conference you are saying this is an application level problem 

Just as a bit of background we have decided to only report first party connections and disconnections to CS's in an RS. So only connections by entities recorded in this RS. This has allowed us to reduced the exponential increase in traffic caused by reporting all connection changes for all users in a large conference to every RS involved.

Finlay Fraser
Annandale House
1 Hanworth Road
Sunbury on Thames
TW16 5DJ
BT IP Tel: +44 (0)1932773310 | Mob: +44(0)7711860228 | E: [email-masked]
________________________________________
From: Parthasarathi R [[email-masked]]
Sent: 01 April 2014 19:23
To: 'Ram Mohan R (rmohanr)'; Fraser,FJ,Finlay,JRM13 R; [email-masked]
Cc: [email-masked]
Subject: RE: [siprec] SIPREC metadata example comments

Hi Finlay/Gerben,

Thanks
Partha

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 8 Apr 2014 04:46:16 +0000

Inline for some comments

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, 2 April 2014 2:40 pm
To: "[email-masked]" <[email-masked]>, Ram Mohan
Ravindranath <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [siprec] SIPREC metadata example comments

>On the conference you are saying this is an application level problem

Yes. An implementation of SRC can get the details in different ways. If
the SRC is also a Conference Focus it would already have most of the
details about participant and can send the same as a snapshot in XML to
SRS. In case a SRC is a participant in the conference it MAY use RFC4575
to subscribe to a Focus and get the details of all the participants before
it sends XML (SIPREC metadata) snapshot to SRS.

> 
>
>Just as a bit of background we have decided to only report first party
>connections and disconnections to CS's in an RS. So only connections by
>entities recorded in this RS. This has allowed us to reduced the
>exponential increase in traffic caused by reporting all connection
>changes for all users in a large conference to every RS involved.

Sure. It is up to a SRC implementation on how often/ when he wants to
advertise the metadata. In general it is recommended to indicate the
changes in a CS as soon as possible to a SRS as SIPREC is all about real
time recording.

Do you have any other comments on the metadata draft -
https://datatracker.ietf.org/doc/draft-ietf-siprec-metadata. If yes please
let us know.

Regards,
Ram