Subject: [siprec] SIPREC metadata example comments

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 11 Mar 2014 06:03:03 +0530

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

---

From: <[email-masked]>
Date: Tue, 11 Mar 2014 08:29:18 +0000

Partha

Are you saying RFC4575 is mandatory package for SIPREC support and would have to be available.

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.

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,

<Solution> Sec 3.3.3 of

Thanks
Partha

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 Mar 2014 11:48:29 +0000

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

>Are you saying RFC4575 is mandatory package for SIPREC support and would

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
>
>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

>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.
>