Subject: [siprec] Metadata for termination of CS

From: <[email-masked]>
Date: Thu, 1 Sep 2011 12:50:05 +0100

Hi,
  as a newcomer to this list, I hope my first post isn't too dumb:

Suppose we have a persistent RS session, and a single CS for a simple 2 party call.

When a CS ends, how is that signalled to the SRS ?
I  see two options,

   a) if the SRC doesnt want to tell the SRS the stop time of the CS, or a termination reason,
      then the SRC sends meta data containing just the RS, without the terminated CS and its particiants and streams.

   b) if the SRC wants to tell the SRS  the stop time of the CS, or a termination reason,
      then the SRC sends meta data containing the RS and CS with its participants (because CS must have 2 participants), but without the streams.
      In the CS will be a Termination Reason and/or a Stop Time.
      Then next time meta data is sent the SRC will no longer include the terminated CS and its particiants and streams.

But what if the SRC does not want to provide CS stop time or termination reason, but wants to provide Stop times for participants,
as far as I can see it cant do this, as it cant remove the CS but still include the participants.
If SRC includes CS with no stop time/terminate reason, but its participants do have stop times, then will SRS treat CS as terminated ?
The feeling I'm getting is that a SRC should iether not include any start/stop times (leaving timestamping to SRS) , or include start/stop times for everything.
Even then, wanting to include CS terminate reason but not start/stop times seems to cause a difficulty.

Rgds
John Stafford | Solution Architect 1 | BT Global Services

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 5 Sep 2011 20:15:58 +0530

Hi John,

Please see inline for my thoughts on this

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, September 01, 2011 5:20 PM
To: [email-masked]
Subject: [siprec] Metadata for termination of CS

 Hi,

Suppose we have a persistent RS session, and a single CS for a simple 2
party call.

   a) if the SRC doesnt want to tell the SRS the stop time of the CS, or
a termination reason,
      then the SRC sends meta data containing just the RS, without the
terminated CS and its particiants and streams. 

 <Ram>Yes SRC can send a complete snapshot of metadata which does not
have CS element in xml to indicate termination of CS. Alternatively in
case of persistent CS an SRC may choose to send complete snapshot having
an XML body with a different CS element to indicate that another CS is
being recorded now

   b) if the SRC wants to tell the SRS  the stop time of the CS, or a
termination reason,
      then the SRC sends meta data containing the RS and CS with its
participants (because CS must have 2 participants), but without the
streams.
      In the CS will be a Termination Reason and/or a Stop Time.

      Then next time meta data is sent the SRC will no longer include
the terminated CS and its particiants and streams. 

 <Ram>Right. SRC may send a partial snapshot of metadata having session
element with stop time. It may optionally having participant/stream
element and indicate the disassociate-times. 

But what if the SRC does not want to provide CS stop time or termination
reason, but wants to provide Stop times for participants,
as far as I can see it cant do this, as it cant remove the CS but still
include the participants.

<Ram> SRC may indicate disassociate time for participant element in the
metadata without indicating CS stop time. This means the participant is
disassociated from this session. Note a participant may join(associate)
again with the same session later.

If SRC includes CS with no stop time/terminate reason, but its
participants do have stop times, then will SRS treat CS as terminated ?

<Ram> I don't think an SRC may make assumptions that when a participant
disassociates from a session, the session is assumed to be terminated.
It is possible in some call flows (like transfer) where in a participant
may move in to another session for some time and then come back to the
first session.

The feeling I'm getting is that a SRC should iether not include any
start/stop times (leaving timestamping to SRS) , or include start/stop
times for everything. 

Even then, wanting to include CS terminate reason but not start/stop
times seems to cause a difficulty.

 <Ram> we really don't have start/stop for every element. For most of
the elements we have associate/disassociate times which really does not
equals to start/stop for all cases.  Please look at ver-04 of metadata
published last week to get more clarity. Also start/stop is an optional
element in the XML schema. So some SRC may not even send these.

Regards,

Ram

Rgds