Subject: Re: [siprec] Dialog state in the CS block of metadatamodel[wasRE:Progressing the architecture document]

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 09:35:33 +0200

So you are saying we might want to distinguish between media generated automatically and media generated by a human? I guess the only SIP mechanism for determining this is that "Automata" media feature tag in RFC 3840, but I don't know how widely implemented it is.

John

> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 29 March 2011 09:50
> To: Elwell, John; Leon Portman; Charles Eckel (eckelcu);
> Hutton, Andrew; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Subject: RE: [siprec] Dialog state in the CS block of
> metadatamodel[wasRE:Progressing the architecture document]
>
> John,
>
> I agree with you in case of media server participant sends "ringback"
> media stream during the early dialog and later stage, the callee
> participant sends actual stream of the session using another
> offer/answer exchange. It is also possible that callee sends
> "ringback"
> media stream  wherein there is no difference between early or regular
> media in terms of metadata information.
>
> Having said that, it "may" or "may not" be matter whether the
> devices of
> the participant automatically creates the media stream or participant
> actually creates media stream.
>
> Thanks
> Partha
>
> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, March 29, 2011 10:39 AM
> To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);
> Hutton, Andrew; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Subject: RE: [siprec] Dialog state in the CS block of
> metadatamodel[wasRE:Progressing the architecture document]
>
> Partha,
>
> I think the real distinction you wish to make is between media coming
> from a particular participant (associated with the UAS) and
> media coming
> from some other entity (e.g., media server). In my view the
> latter case,
> if we choose to record it, comes from a different
> "participant". It has
> nothing to do with whether it is deemed early or regular from a SIP
> dialog perspective.
>
> John (as individual)
>
>
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > Sent: 28 March 2011 17:53
> > To: Leon Portman; Charles Eckel (eckelcu); Hutton, Andrew; Elwell,
> > John; Ram Mohan R (rmohanr)
> > Cc: [email-masked]
> > Subject: RE: [siprec] Dialog state in the CS block of
> > metadatamodel[wasRE:Progressing the architecture document]
> >
> >
> > The question of "session" state is raised in my mind mainly to
> > distinguish between early media (Media before session
> establishment)
> > from normal media. Without the information in SIPREC metadata, the
> > early media will be associated with UAS participant's media stream.
> > I'm interested in knowing whether SIPREC solution has to
> differentiate
>
> > between early media from normal media.
> >
> > As per John below mail, there is no need to differentiate
> as per the
> > current requirement. If most of the folks feel so, I'm fine
> with not
> > including "session state" in metadata.
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: Leon Portman [mailto:[email-masked]]
> > Sent: Monday, March 28, 2011 7:16 PM
> > To: Charles Eckel (eckelcu); Hutton, Andrew; Elwell, John;
> > Parthasarathi R (partr); Ram Mohan R (rmohanr)
> > Cc: [email-masked]
> > Subject: RE: [siprec] Dialog state in the CS block of
> > metadatamodel[wasRE:Progressing the architecture document]
> >
> > Charles Hi
> >
> > Just to make clear, I don't think SRS should receive dialog level
> > state events about all  CS dialogs. I think that we should
> to support
> > reporting high level session events.
> > I understand the complexity of that and Ok to keep it open or next
> > phase extensions
> >
> > Leon
> >
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> > Sent: Monday, March 28, 2011 3:35 PM
> > To: Hutton, Andrew; Elwell, John; Leon Portman; Parthasarathi R
> > (partr); Ram Mohan R (rmohanr)
> > Cc: [email-masked]
> > Subject: RE: [siprec] Dialog state in the CS block of
> > metadatamodel[wasRE:Progressing the architecture document]
> >
> > I agree with this approach. Hopefully Leon and others that saw the
> > need for this state information can confirm if it works for them.
> >
> > Cheers,
> > Charles
> >
> > > -----Original Message-----
> > > From: Hutton, Andrew [mailto:[email-masked]]
> > > Sent: Monday, March 28, 2011 9:13 AM
> > > To: Elwell, John; Leon Portman; Charles Eckel (eckelcu);
> > Parthasarathi
> > R (partr); Ram Mohan R
> > > (rmohanr)
> > > Cc: [email-masked]
> > > Subject: RE: [siprec] Dialog state in the CS block of
> > metadatamodel[wasRE:Progressing the architecture
> > > document]
> > >
> > > Hi,
> > >
> > > The draft-ietf-siprec-architecture has from the very
> > beginning listed
> > dialog state as an example of
> > > what would be included in metadata which is why I raised
> > the question.
> > >
> > > However it is true to say this was put in the
> architecture document
> > before we had firmed up the
> > > requirements or starting any indepth work on metadata so I could
> > accept that the architecture draft
> > > simply got this wrong from the start and it maybe should
> be removed.
> > We could of course take the view
> > > that if dialog events are important then the SRS could
> subscribe to
> > the dialog event package at the
> > > SRC and SIPREC does not need to touch this.
> > >
> > > I don't think we can allow SIPREC metadata to extend as far as
> > reporting everything that happens to
> > > the CS including how it is linked to other CS's and what
> > services are
> > used on the CS (E.g. types of
> > > transfer etc.). This would quickly get very difficult to
> > define and we
> > would probably fail.
> > >
> > > I would prefer to not report this state information in
> metadata than
> > open up the possibility of adding
> > > lots of complexity.
> > >
> > > Regards
> > > Andy
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Elwell, John
> > > > Sent: 27 March 2011 14:50
> > > > To: Leon Portman; Charles Eckel (eckelcu); Parthasarathi
> > R (partr);
> > > > Ram Mohan R (rmohanr); Hutton, Andrew
> > > > Cc: [email-masked]
> > > > Subject: RE: [siprec] Dialog state in the CS block of
> > > > metadatamodel[wasRE:Progressing the architecture document]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Leon Portman [mailto:[email-masked]]
> > > > > Sent: 27 March 2011 11:48
> > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi R
> > > > > (partr); Ram Mohan R (rmohanr); Hutton, Andrew
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [siprec] Dialog state in the CS block of
> > > > > metadatamodel[wasRE:Progressing the architecture document]
> > > > >
> > > > > Charles Hi
> > > > >
> > > > > Yes, it will be good to discuss it face to face.
> > > > >
> > > > > Just little background for such requirements. Today,
> especially
> > > > > for contact centers, it is important for SRS to capture the
> > > > > information how long customer was waiting for agent to
> > answer the
> > > > > call, which party hang up, how long was the hold time,
> > if it was
> > > > > blind transfer or consultation transfer. This information
> > > > > important both from quality management point of view
> > and customer
> > > > > experience point of view.
> > > > [JRE] (as chair) I think the group needs to consider
> > whether this is
> >
> > > > within scope. Looking at the requirements, we have:
> > > > "REQ-012 The mechanism MUST provide the SRS with metadata
> > describing
> > > >    CSs that are being recorded, including the media
> being used and
> > the
> > > >    identities of parties involved."
> > > > If we are not recording the session while the caller is
> > waiting to
> > > > be answered, it seems we perhaps don't have a requirement for
> > > > metadata about that. This seems to be more about call detail
> > > > recording (CDR) rather than session recording. We can by
> > all means
> > > > have this discussion, but I am concerned about scope creep.
> > > >
> > > > > It is important also from compliance point of view to
> detect if
> > > > > somebody actually received the media stream or still was in
> > > > > pending state or media stream was disconnected.
> > > > [JRE] (as individual) I agree we should show a participant as
> > > > receiving media only if the SRC believes media is
> actually being
> > > > sent to that participant (even then, there can be no
> > guarantee it is
> >
> > > > received, e.g., because NAT or firewall traversal isn't
> > functioning
> > > > properly, severe packet loss, speaker volume is muted,
> > etc..). But I
> >
> > > > have doubts whether it is necessarily to try to account
> > for periods
> > > > when the SRC knows a participant is not receiving media
> > by saying it
> >
> > > > is because of alerting, hold or whatever.
> > > >
> > > > John
> > > >
> > > >
> > > > >
> > > > > Leon
> > > > >
> > > > > -----Original Message-----
> > > > > From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> > > > > Sent: Sunday, March 27, 2011 11:35 AM
> > > > > To: Leon Portman; Elwell, John; Parthasarathi R
> > (partr); Ram Mohan
> >
> > > > > R (rmohanr); Hutton, Andrew
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [siprec] Dialog state in the CS block of
> > > > > metadatamodel[wasRE:Progressing the architecture document]
> > > > >
> > > > > Hi Leon,
> > > > >
> > > > > Thank you for your patience in trying to explain this to me;
> > > > > however, I still am not able to understand why the SRS
> > might need
> > > > > to know this information, or what it would do with it.
> > > > > Is it that you need to know when a given participant
> > was receiving
> >
> > > > > the recorded media and when it was not? If so, I do not think
> > > > > dialog state is sufficient. Is there some other
> requirement or
> > > > > functionality addressed by the SRS having such information?
> > > > > Perhaps it is easier to discuss in person at the
> > breakfast meeting
> >
> > > > > Wednesday or during the working group session.
> > > > >
> > > > > Cheers,
> > > > > Charles
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Leon Portman [mailto:[email-masked]]
> > > > > > Sent: Saturday, March 26, 2011 8:15 PM
> > > > > > To: Charles Eckel (eckelcu); Elwell, John; Parthasarathi
> > > > R (partr);
> > > > > Ram Mohan R (rmohanr); Hutton,
> > > > > > Andrew
> > > > > > Cc: [email-masked]
> > > > > > Subject: RE: [siprec] Dialog state in the CS block of
> > > > > metadatamodel[wasRE:Progressing the architecture
> > > > > > document]
> > > > > >
> > > > > > Charles Hi
> > > > > >
> > > > > > Without participant session state, SRS will know only when
> > > > > participant
> > > > > is part of the session and will
> > > > > > not know about intermediate states like ringing,
> retrying etc.
> > > > > > I know that we have media stream information per
> > > > participant but not
> > > > > sure that it is enough.
> > > > > >
> > > > > > Leon
> > > > > > -----Original Message-----
> > > > > > From: Charles Eckel (eckelcu) [mailto:[email-masked]]
> > > > > > Sent: Saturday, March 26, 2011 9:07 PM
> > > > > > To: Leon Portman; Elwell, John; Parthasarathi R (partr);
> > > > Ram Mohan R
> > > > > (rmohanr); Hutton, Andrew
> > > > > > Cc: [email-masked]
> > > > > > Subject: RE: [siprec] Dialog state in the CS block of
> > > > metadatamodel
> > > > > [wasRE:Progressing the
> > > > > > architecture document]
> > > > > >
> > > > > > Hi Leon,
> > > > > >
> > > > > > I am still having a hard time understanding why we need
> > > > the session
> > > > > state information per CS
> > > > > > participant? Why is this required, who uses it, and how?
> > > > > >
> > > > > > Thanks,
> > > > > > Charles
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > [mailto:[email-masked]] On
> > > > > > Behalf Of Leon Portman
> > > > > > > Sent: Saturday, March 26, 2011 10:31 AM
> > > > > > > To: Elwell, John; Parthasarathi R (partr); Ram Mohan R
> > > > (rmohanr);
> > > > > > Hutton, Andrew
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: Re: [siprec] Dialog state in the CS block of
> > > > > metadatamodel
> > > > > > [wasRE:Progressing the
> > > > > > > architecture document]
> > > > > > >
> > > > > > > John Hello
> > > > > > >
> > > > > > > I agree that SRS (and its application clients) interested
> > > > > in SESSION
> > > > > > level events and not underlying
> > > > > > > DIALOG events. However we do need to support reporting
> > > > > session state
> > > > > > information per CS  participant
> > > > > > > that sometimes equals to dialog level and sometimes not.
> > > > > > >
> > > > > > > We could have define more application level state
> > events like
> > > > > instead
> > > > > > of TRYING - > RINGING etc.
> > > > > > > However they could be domain specific.
> > > > > > >
> > > > > > > Leon
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Elwell, John
> > [mailto:[email-masked]]
> > > > > > > Sent: Thursday, March 24, 2011 6:34 PM
> > > > > > > To: Parthasarathi R (partr); Ram Mohan R (rmohanr);
> > > > Leon Portman;
> > > > > > Hutton, Andrew
> > > > > > > Cc: [email-masked]
> > > > > > > Subject: RE: [siprec] Dialog state in the CS block of
> > > > > metadata model
> > > > > > [wasRE:Progressing the
> > > > > > > architecture document]
> > > > > > >
> > > > > > > This discussion gives me some concerns, echoing to some
> > > > > extent what
> > > > > > Ram is saying.
> > > > > > >
> > > > > > > SIPREC is about session recording, where a session is the
> > > > > information
> > > > > > exchanged between participants
> > > > > > > in a CS (the media streams) plus metadata. The
> > metadata should
> > > > > provide
> > > > > > additional information about
> > > > > > > the CS. This means information about the communication
> > > > > SESSION, not
> > > > > > about the SIP dialog that is used
> > > > > > > to control that session. With this in mind, consider
> > > > the following
> > > > > > points, some of which have already
> > > > > > > been raised:
> > > > > > >
> > > > > > > 1. There may be more than one SIP dialog involved if the
> > > > > SRC is at a
> > > > > > B2BUA or conference focus.
> > > > > > >
> > > > > > > 2. Does the CS necessarily need to be controlled
> by SIP? For
> > > > > example,
> > > > > > it could be a PSTN call, an RTC-
> > > > > > > Web call or a Jingle call. None of these preclude using
> > > > > SIP for the
> > > > > RS
> > > > > > (that is what the charter of
> > > > > > > SIPREC is all about - a SIP-based RS).
> > > > > > >
> > > > > > > 3. Somebody retrieving and playing back a recorded
> > CS will be
> > > > > > interested in session-related events
> > > > > > > like participants leaving and joining (including the first
> > > > > > participants joining at the start of the CS
> > > > > > > and the last participants leaving a the end of the
> > CS), media
> > > > > streams
> > > > > > starting and ending and
> > > > > > > participants starting or stopping receipt of a
> media stream.
> > In
> > > > > other
> > > > > > words, changes of SESSION state,
> > > > > > > not dialog state.
> > > > > > >
> > > > > > > 4. Some of the SIP dialog states just don't seem
> > relevant. The
> > > > > > distinction between early dialog and
> > > > > > > full dialog in SIP does not necessarily
> corresponding to any
> > > > > > meaningful state change of the session.
> > > > > > > For example, A makes a call to B and B answers and
> > > > starts sending
> > > > > > media. A receives and renders media
> > > > > > > (perhaps it has already received SDP answer, allowing
> > > > it to verify
> > > > > the
> > > > > > source of the media). Then A
> > > > > > > receives the 200 OK (transitioning from an early dialog
> > > > to a full
> > > > > > dialog) and continues to receive
> > > > > > > media. So although there is a dialog state
> change, there is
> > not
> > > > > really
> > > > > > a session state change.
> > > > > > >
> > > > > > > The bit about dialog state in the architecture
> > draft is, in my
> > > > > > opinion, a legacy from some earlier
> > > > > > > discussions, before we started having the metadata
> > > > discussions. I
> > > > > > think the metadata discussions have
> > > > > > > taken us in the right direction.
> > > > > > >
> > > > > > > John (as individual)
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [email-masked]
> > > > > > > > [mailto:[email-masked]] On Behalf Of
> > Parthasarathi
> > R
> > > > > > (partr)
> > > > > > > > Sent: 24 March 2011 02:36
> > > > > > > > To: Ram Mohan R (rmohanr); Leon Portman; Hutton, Andrew
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of
> > metadata
> > > > > model
> > > > > > > > [wasRE:Progressing the architecture document]
> > > > > > > >
> > > > > > > > Ram,
> > > > > > > >
> > > > > > > > Please read inline.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Partha
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > >
> > > > > > > > From: Ram Mohan R (rmohanr)
> > > > > > > > Sent: Wed 3/23/2011 7:59 PM
> > > > > > > > To: Parthasarathi R (partr); Leon Portman;
> Hutton, Andrew
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: RE: [siprec] Dialog state in the CS block of
> > metadata
> > > > > model
> > > > > > > > [wasRE:Progressing the architecture document]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I am still trying to understand what is the
> > > > significance of this
> > > > > > > > attribute w.r.t CS. Are we saying the attribute
> represents
> > the
> > > > > state
> > > > > > > > of CS ?
> > > > > > > >
> > > > > > > > Note that CS need not be one dialog.
> > > > > > > >
> > > > > > > > <Partha>  The attribute is to show the state of CS
> > > > > only. As it is
> > > > > > not
> > > > > > > > single dialog, I have mentioned as session
> state attribute
> > > > > </Partha>
> > > > > > > >
> > > > > > > > For cases like Conference where there may be different
> > > > > participants,
> > > > > > > > if SRC happens to be Focus how do you derive/what is
> > "session
> > > > > state"
> > > > > > ?
> > > > > > > >
> > > > > > > > <Partha> I really don't know whether it is generic. My
> > thought
> > > > > > > > processing of session state for conference is
> as follows:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1) First participant of conference early media (ivr
> > > > play) may be
> > > > > > > > considered as "early" state of session.
> > > > > > > >
> > > > > > > > 2) The session state is chaged to confirmed in case any
> > > > > one of the
> > > > > > > > participant joined in the conference.
> > > > > > > >
> > > > > > > > 3) The session state is move to terminated when the last
> > > > > participant
> > > > > > > > moved out of the conference.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Please let me know in case other way to represent the
> > session
> > > > > state
> > > > > > of
> > > > > > > > conference </partha>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > For cases where B2BUA acts as SRC what is
> > "session state" ?
> > > > > > > >
> > > > > > > > <partha> It looks straight forward for me. In
> B2BUA case ,
> > > > > > > >
> > > > > > > > 1) The stage where in two party is not connected, it is
> > > > > considered
> > > > > > as
> > > > > > > > early state.
> > > > > > > >
> > > > > > > > 2) when both are connected, it is confirmed state
> > > > > > > >
> > > > > > > > 3) In case of BYE received from any one of the party,
> > > > then CS is
> > > > > > > > considered as terminated state
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Please note that this is applicable for 3PCC as well.
> > > > > </partha>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Ram
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: [email-masked]
> > > > > > > > [mailto:[email-masked]] On Behalf Of
> > Parthasarathi
> > R
> > > > > > (partr)
> > > > > > > > Sent: Wednesday, March 23, 2011 6:13 AM
> > > > > > > > To: Leon Portman; Hutton, Andrew
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: Re: [siprec] Dialog state in the CS block of
> > metadata
> > > > > model
> > > > > > > > [wasRE:Progressing the architecture document]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Leon,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Shall we have optional "event" attribute to indicate the
> > state
> > > > > > change
> > > > > > > > which is similar to "event" attribute in RFC 4235.
> > > > The "event"
> > > > > will
> > > > > > > > include the following:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 1) cancelled
> > > > > > > >
> > > > > > > > 2) rejected
> > > > > > > >
> > > > > > > > 3) replaced
> > > > > > > >
> > > > > > > > 4) bye
> > > > > > > >
> > > > > > > > 5) error
> > > > > > > >
> > > > > > > > 6) timeout
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Partha
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > >
> > > > > > > > From: Leon Portman [mailto:[email-masked]]
> > > > > > > > Sent: Tue 3/22/2011 9:37 PM
> > > > > > > > To: Hutton, Andrew; Parthasarathi R (partr)
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: RE: Dialog state in the CS block of metadata
> > > > model [was
> > > > > > > > RE:Progressing the architecture document]
> > > > > > > >
> > > > > > > > It can be either application level error or dialog
> > > > > level errors -
> > > > > > like
> > > > > > > > timeout or failures.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Leon
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: Hutton, Andrew
> > > > > [mailto:[email-masked]]
> > > > > > > > Sent: Tuesday, March 22, 2011 6:02 PM
> > > > > > > > To: Leon Portman; Parthasarathi R (partr)
> > > > > > > > Cc: [email-masked]
> > > > > > > > Subject: RE: Dialog state in the CS block of metadata
> > > > model [was
> > > > > RE:
> > > > > > > > Progressing the architecture document]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > What would it be used for?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Andy
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > >
> > > > > > > >   From: Leon Portman [mailto:[email-masked]]
> > > > > > > >   Sent: 22 March 2011 14:11
> > > > > > > >   To: Parthasarathi R (partr); Hutton, Andrew
> > > > > > > >   Cc: [email-masked]
> > > > > > > >   Subject: RE: Dialog state in the CS block of metadata
> > > > > model [was
> > > > > > RE:
> > > > > > > > Progressing the architecture document]
> > > > > > > >
> > > > > > > >   Should we have error state as well?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >   Leon
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >   From: [email-masked]
> > > > > > > > [mailto:[email-masked]] On Behalf Of
> > Parthasarathi
> > R
> > > > > > (partr)
> > > > > > > >   Sent: Tuesday, March 22, 2011 3:33 PM
> > > > > > > >   To: Parthasarathi R (partr); Hutton, Andrew
> > > > > > > >   Cc: [email-masked]
> > > > > > > >   Subject: [siprec] Dialog state in the CS block of
> > > > > metadata model
> > > > > > [was
> > > > > > > > RE: Progressing the architecture document]
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >   The architecture document proposes to have
> > > > > dialog/session state
> > > > > > in
> > > > > > > > Metadata model. To achieve this, "session state"
> > > > > attribute has to
> > > > > be
> > > > > > > > added in the CS block of Metadata model. The possible
> > > > values for
> > > > > > > > session state are
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >   1) Trying
> > > > > > > >
> > > > > > > >   2) Proceeding
> > > > > > > >
> > > > > > > >   3) Early
> > > > > > > >
> > > > > > > >   4) Confirmed
> > > > > > > >
> > > > > > > >   5) Terminated
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >   Please let me know in case any objection to add
> > > > this attribute
> > > > > > in
> > > > > > > > Metadata model.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >   Thanks
> > > > > > > >
> > > > > > > >   Partha
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ________________________________
> > > > > > > >
> > > > > > > >   From: Parthasarathi R (partr)
> > > > > > > >   Sent: Wednesday, March 16, 2011 5:40 AM
> > > > > > > >   To: Hutton, Andrew
> > > > > > > >   Cc: Elwell, John; [email-masked]
> > > > > > > >   Subject: RE: Progressing the architecture document
> > > > > > > >
> > > > > > > >   > -----Original Message-----
> > > > > > > >   > From: [email-masked]
> > > > > > > >   > [mailto:[email-masked]] On Behalf Of
> > > > > Parthasarathi R
> > > > > > > > (partr)
> > > > > > > >   > Sent: 14 March 2011 17:05
> > > > > > > >   > To: Elwell, John; [email-masked]
> > > > > > > >   > Subject: Re: [siprec] Progressing the
> > > > architecture document
> > > > > > > >
> > > > > > > >   >
> > > > > > > >   > Sec 4.3.1 whether 3rd bullet is required?
> > > > > > > >   >
> > > > > > > >
> > > > > > > >   [AndyH]I assume it is as for example I assume
> > it would be
> > > > > > necessary
> > > > > > > > to record early-media and update the SRS when the
> > > > dialog changes
> > > > > to
> > > > > > > > the confirmed or terminated state. Does not
> seem to be in
> > the
> > > > > > metadata
> > > > > > > > draft though. In the end I will either remove
> > these bullets
> > or
> > > > > align
> > > > > > > > with the metadata draft.
> > > > > > > >   <Partha> It is a good point. Dialog state shall be
> > > > > added as one
> > > > > > of
> > > > > > > > the optional attribute in CS metadata block with
> > > > > default value as
> > > > > > > > mid-dialog. This helps to differentiate between
> > early dialog
> > > > > > > > (ringback) vs mid-dialog (normal
> > > > > > > > conversation) in recording. In case of no
> > objection for this
> > > > > > attribute
> > > > > > > > in metadata model, we will add it. We will work
> > out metadata
> > > > > format
> > > > > > > > once the consensus occurs for metadata model.
> > > > > > > > In case required, we will span separate mail thread to
> > > > > close this
> > > > > > > > issue </Partha>
> > > > > > > >
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > siprec mailing list
> > > > > > > [email-masked]
> > > > > > > https://www.ietf.org/mailman/listinfo/siprec
> > > > >
> > > >
> >
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 6 Apr 2011 14:31:31 +0530

John,

As we agreed upon on IETF-80 SIPREC meeting, session state attribute
will not be included as part of the metadata model & format. In case any
requires this attribute, Let them speak for it.

I really don't very sure whether it is required to pass feature tag in
SIPREC Metadata. 

Thanks
Partha 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 1:06 PM
To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);

So you are saying we might want to distinguish between media generated
automatically and media generated by a human? I guess the only SIP
mechanism for determining this is that "Automata" media feature tag in
RFC 3840, but I don't know how widely implemented it is.

John

> To: Elwell, John; Leon Portman; Charles Eckel (eckelcu); Hutton, 
> Andrew; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Having said that, it "may" or "may not" be matter whether the devices 
> of the participant automatically creates the media stream or 
> participant actually creates media stream.
>
> Thanks
> Partha
>
> from a particular participant (associated with the UAS) and media 
> coming from some other entity (e.g., media server). In my view the 
> latter case, if we choose to record it, comes from a different 
> "participant". It has nothing to do with whether it is deemed early or

> regular from a SIP dialog perspective.
>
> John (as individual)
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Apr 2011 14:49:41 +0200

Partha,

I don't see the connection between the discussion on session state and the discussion on early versus regular media. It seems to me that if we want to tag media as coming from an automaton, this would be an attribute of the participant object, not the session object.

However, I am not arguing in favour of adding this attribute - just pointing out what it would mean.

John (as individual)

> Sent: 06 April 2011 10:02

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 8 Apr 2011 19:34:48 +0530

John,

I guess that we are talking in the same line. I mentioned about session
state as this attribute was originally added to distinguish between
early versus regular media. 

I completely agree with you that this attribute has to be in participant
object or stream object even if somebody wants to have this.

Thanks
Partha
-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2011 6:20 PM
To: Parthasarathi R (partr); Leon Portman; Charles Eckel (eckelcu);

Partha,

I don't see the connection between the discussion on session state and
the discussion on early versus regular media. It seems to me that if we
want to tag media as coming from an automaton, this would be an
attribute of the participant object, not the session object.

However, I am not arguing in favour of adding this attribute - just
pointing out what it would mean.

John (as individual)