Subject: [siprec] Protocol Document (draft-portman-siprec-protocol)

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jul 2011 13:43:04 -0400

After reading through the document, I have a number of comments and 
questions.

The first aspect of the specification that jumped out at me is the 
ability to exchange metadata over an unspecified HTTP interface. 
However, no indication about how one might signal this is indicated, so 
interoperability is pretty much impossible. It also seems to be in 
competition with the SIP-body based approach for sending metadata (which 
seems perfectly adequate). I think we need to either put more language 
around how this kind of behavior would be implemented in an 
interoperable fashion, or remove it from the document. I would suggest 
removing it.

On a different topic: there is text at the top of page 9 that specifies 
that the "From" header field is populated with the identity of the SRC. 
This seems very counter-intuitive in a system that allows the SRS to 
initiate the recording session. I suspect you didn't mean to say "SRC" 
as much as something like "SRS or SRC, depending on which entity 
initiated the recording session."

The definition of the values that SRS-Session can take on basically 
defines it as a human-readable UTF-8 string, with no semantic 
information that can be extracted by the application. This raises two 
issues. First: if this is intended exclusively for human consumption, 
you must take internationalization into account. The simplest solution 
would include the ability to add multiple SRS-Session values, each with 
its own (mandatory) language tag. Second: it seems unlikely that no 
implementation would ever want to take action based on the SRS-Status 
(especially when it can indicate something as profound as "SRS failure", 
as the document example shows). I would be surprised if we don't really 
want a semantic registry of values here.

Finally, the requirements document has a provision that any solution 
must prevent an RS from being routed to a non-SRS. This seems 
reasonable.  However, the proposed solution has nothing that prevents 
this situation. It seems this would be trivially solved by adding a new 
option tag that must be included in a Require header field in an RS 
INVITE. Is there some reason the protocol document doesn't do this?

/a

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 26 Jul 2011 13:25:56 -0700

Please see inline.

>interoperable fashion, or remove it from the document. I would suggest

Yes, Ram also brought this up and questioned the wording of the paragraph.
I agreed to remove it from this document since this is out of the charter.
The original intention of this paragraph is to address REQ-014 where we
require the metadata format to be transport agnostic; I think this is
better addressed in the metadata draft.

>initiated the recording session."

You are right about the wording that it should be either SRC or SRS for
the From header. However, a related note on this is that this draft does
not intend to address SRS-initiated recording. We had previous discussions
and the agreement is that we will only address SRC-initiated recording in
this draft.

>want a semantic registry of values here.

I think the general agreement is that we want a simple mechanism for the
SRS to send a snapshot request to the SRC. The content provided by the SRS
is meant to be additional information for the SRC to log for a person to
read, therefore, it would be optional for the SRC to process the content.
I am okay with defining multiple fields to address the multiple languages;
how would you name the header names?

>INVITE. Is there some reason the protocol document doesn't do this?

Even though using Request would prevent a UAS from answering the call,
this does not guarantee that routing elements would be able to route an
INVITE request with an options tag to an actual SRS instance. That's why
we opted not to use options tag for this since an SRS can register with
the feature tag to let the registrar know where a SRS is registered.

>/a

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jul 2011 18:07:57 -0400

On 7/26/11 4:25 PM, Henry Lum wrote:
> Please see inline.
>
> On 11-07-26 1:43 PM, "Adam Roach"<[email-masked]>  wrote:
>

Ah, okay. My confusion comes from the fact that I read the architecture 
document right before the protocol document, and 3.2.2 calls out 
SRS-initiated calls as a use case. Forgive the fact that I'm coming a 
bit late to this party, but it does raise the question: is the working 
group planning on addressing the use case described in 3.2.2 of the 
architecture document at all?

> how would you name the header names?

The header name can be considered a protocol element. What I'm 
envisioning is something like:

SRS-Session: "SRS Failure";language=en
SRS-Session: "SRSの失敗";language=jp

> the feature tag to let the registrar know where a SRS is registered.

Oh, I think the feature tag is a good idea. The problem is that those 
are advisory. Require is in the base spec, and is guaranteed to prevent 
things from going wrong. I think you need both.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 00:58:01 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 26 July 2011 21:26
> To: Adam Roach; SIPREC (SIP Recording) WG; 
> [email-masked]
> Subject: Re: [siprec] Protocol Document 
> (draft-portman-siprec-protocol)
> 
> Please see inline.
> 
[JRE] The past agreement that it was the SRC that would decide whether a particular CS, or part of a CS, should be recorded. I don't recall any discussion about the direction of the INVITE request to establish the RS. Don't forget, the RS can be established on a semi-permanent basis (persistent recording), so it might be feasible for the SRS to establish the RS and then the SRC can decide when to use that RS for recording CSs.

John (as individual)

> --------------------------------------------------------------
> -----------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> 					
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 26 Jul 2011 19:25:30 -0700

On 11-07-26 6:58 PM, "Elwell, John" <[email-masked]>
wrote:

>[JRE] The past agreement that it was the SRC that would decide whether a
>particular CS, or part of a CS, should be recorded. I don't recall any
>discussion about the direction of the INVITE request to establish the RS.
>Don't forget, the RS can be established on a semi-permanent basis
>(persistent recording), so it might be feasible for the SRS to establish
>the RS and then the SRC can decide when to use that RS for recording CSs.

You are right, we agree that SRC would always be the element that decides
a particular CS to be recorded and it would be up to the SRS to accept the
recording or not based on local policy. This is independent of how the RS
is established, although I can see that having SRS-initiated RS should
normally apply to persistent recordings since an SRS cannot decide which
call to record in the initial INVITE. We can add a note to clarify this
use case.

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 26 Jul 2011 19:42:07 -0700

>architecture document at all?

John brought up a good point; I will add some text to clarify the specific
usage for SRS-initiated RS.

>SRS-Session: "SRSの失敗";language=jp

I am fine with this format, but why do we have to make it mandatory as you
suggested?

>things from going wrong. I think you need both.

I can see that if an SRC notices the request has been routed to a non-SRS
and the SRS tries to accept it, the SRC can always terminate the call when
it sees that there is no SRS feature tag. Something is already wrong with
if it cannot route a request to an SRS or to the wrong SRS, so even if the
options tag can reject a call, the end result is that there is no
recording happening.

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 Jul 2011 23:35:11 -0400

> I am fine with this format, but why do we have to make it mandatory as you

In my experience, that's what the internationalization guys have pretty
much always required once you get into text intended for human
consumption. You can try doing it another way, but it might cause
problems when you get to the IESG and/or IETF last call.

(Also, I just now realized that I botched the language tag up there: it
should be "ja", not "jp." I got the country and the language confused.
Sorry about that.)

> options tag can reject a call, the end result is that there is no

It's not quite that simple. If you're relying on feature tags, then a
forking proxy in the middle -- one that is unaware of feature tags --
may end up routing the call to multiple devices. Imagine one is an SRS
and the other is a phone set to auto-answer. (OMA has use cases around
this; I can send references if you want verification that real networks
intend to have phones auto-answer).

With the Require header, the auto-answer phone sends an error; the SRS
sends a success response; the proxy forwards the best response (which is
the SRS success response), and everything works.

Without the Require header, the auto-answer phone sends a 200; the SRS
sends a 200; the responses race to the proxy; the phone might well win;
and then the SRC would be forced to tear down that session. What happens
after that depends on how well the SRC handles the late 200 response
from the SRS -- but it's easy to imagine that implementations won't get
this rather complicated race situation correct.

I think the first scenario is a lot more elegant, and far more prone to
success. Is there some actual reason we don't want a Require tag?

/a

---

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

Hi all,

In the past (during IETF-78 timeframe), we had discussion about SRC
initiated recording and SRS initiated recording. In case I recollect
correctly, SRS initiated recording is more complicated and made
out-of-scope. The couple of complications which I could think of:

1) RS mapping to participant:  In B2BUA+SRC servers, multiple
participants are handled and RS has to be mapped with the specific
participant in case of persistent recording. There is a need for
participant(recording AOR) information in SRS-initiated INVITE. Without
this information, SRC is clueless about which participant has to be
recorded for this specific RS.

2) RS mapping to CS: In case of selective recording, multiple CS exists
in B2BUA+SRC servers wherein SRS initiated INVITE has to mention which
CS has to be recorded. This is something similar to join operation for
CS in SRC.

I'm not against SRS-initiated RS dialog but in case SIPREC solution
includes SRS-Initiated recording, it has to be generic enough.

Thanks
Partha

> Sent: Wednesday, July 27, 2011 7:56 AM
> To: Elwell, John; Adam Roach; SIPREC (SIP Recording) WG; 
> >> You are right about the wording that it should be either 
> SRC or SRS 
> >> for the From header. However, a related note on this is that this 
> >> draft does not intend to address SRS-initiated recording. We had 
> >> previous discussions and the agreement is that we will 
> only address 
> >> SRC-initiated recording in this draft.
> >[JRE] The past agreement that it was the SRC that would 
> decide whether 
> >a particular CS, or part of a CS, should be recorded. I don't recall 
> >any discussion about the direction of the INVITE request to 
> establish the RS.
> >(persistent recording), so it might be feasible for the SRS to 
> >establish the RS and then the SRC can decide when to use 
> that RS for recording CSs.
> 
> You are right, we agree that SRC would always be the element 
> that decides a particular CS to be recorded and it would be 
> up to the SRS to accept the recording or not based on local 
> policy. This is independent of how the RS is established, 
> although I can see that having SRS-initiated RS should 
> normally apply to persistent recordings since an SRS cannot 
> decide which call to record in the initial INVITE. We can add 
> a note to clarify this use case.
> 
> >
> >John (as individual)
> >
> >
> >> 
> >> >
> >> >information that can be extracted by the application. This raises 
> >> >two issues. First: if this is intended exclusively for human 
> >> >consumption, you must take internationalization into account. The
> >> simplest solution
> >> >implementation would ever want to take action based on the 
> >> >SRS-Status (especially when it can indicate something as 
> profound as
> >> "SRS failure",
> >> I think the general agreement is that we want a simple 
> mechanism for 
> >> the SRS to send a snapshot request to the SRC. The content 
> provided 
> >> by the SRS is meant to be additional information for the 
> SRC to log 
> >> for a person to read, therefore, it would be optional for 
> the SRC to 
> >> process the content.
> >> I am okay with defining multiple fields to address the multiple 
> >> languages; how would you name the header names?
> >> 
> >> >
> >> >reasonable.  However, the proposed solution has nothing that 
> >> >prevents this situation. It seems this would be trivially 
> solved by
> >> adding a new
> >> Even though using Request would prevent a UAS from answering the 
> >> call, this does not guarantee that routing elements would 
> be able to 
> >> route an INVITE request with an options tag to an actual SRS 
> >> instance.
> >> That's why
> >> we opted not to use options tag for this since an SRS can register 
> >> with the feature tag to let the registrar know where a SRS is 
> >> registered.
> >> 
> >> >
> >> >/a
> >> 
> >> 
> >>                 
> >> CONFIDENTIALITY NOTICE: This e-mail and any files attached may 
> >> contain confidential and proprietary information of Alcatel-Lucent 
> >> and/or its affiliated entities. Access by the intended 
> recipient only 
> >> is authorized. Any liability arising from any party acting, or 
> >> refraining from acting, on any information contained in 
> this e-mail 
> >> is hereby excluded. If you are not the intended recipient, please 
> >> notify the sender immediately, destroy the original 
> transmission and 
> >> its attachments and do not disclose the contents to any 
> other person, 
> >> use it for any purpose, or store or copy the information in any 
> >> medium. Copyright in this e-mail and any attachments belongs to 
> >> Alcatel-Lucent and/or its affiliated entities.
> >>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 00:33:52 -0400

> should be "ja", not "jp." I got the country and the language confused.

ISO 639 has like over 400 active languages.  Do we really want to have to deal with it, even for only the top 10-20 languages?
Besides, logging of SIP message info is already full of English so it's not like one can really avoid it.  And this isn't for human consumption - it's for engineers. ;)

Also, now that I read that section of this draft...
1) It talks about example reasons for requesting snapshots as:
   ... Failure scenarios can include
   failure to parse metadata information (syntax error), failure to
   match metadata information with the current metadata snapshot
   (semantic error), or failure at the SRS.

For at least the first two reasons, I don't see how asking for the metadata again is going to fix anything.  It's not like the SRC can change the syntax or semantics of the metadata it sent to the SRS previously.  It' going to get the same error again, and again, and again.  And for the third reason (failure of the SRS), are we saying the SRS has enough saved state to be able to send the in-dialog snapshot re-INVITE request, but not to remember the actual metadata?
What actual use-case is there for asking for another snapshot?

2) The section says the metadata snapshot request can be sent in an UPDATE request, and the SRC can send it in the response.  Since this draft describes the SDP as metadata, using an UDPATE model won't work since the SRS doesn't have SDP to send in the UPDATE request, and the SRC can't put in SDP in a response to UPDATE if there was no SDP offer in the request. (compared to re-INVITE, where the SRS can send an offer-less re-INVITE, the SRC can send the SDP offer in the 200 and the SRS can send the answer in the ACK)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 27 Jul 2011 07:44:52 -0400

> ISO 639 has like over 400 active languages.  Do we really want to have to deal with it, even for only the top 10-20 languages?

That's why my original recommendation was to have semantic header with
meaning governed by a numeric registry. You know, like SIP error codes.
Once something is human-readable-only, all kinds of human factors
considerations come into play.

/a

---

From: Leon Portman <[email-masked]>
Date: Wed, 27 Jul 2011 16:01:28 +0300

Yes, I agree that to use of error codes probably a better idea.

Regarding Hadriel points below, if SRS triggers a snapshot request, it will not just receive the same message as partial update but a complete CS description so it can solve the problem of inconsistent state or message format.

Regarding the ability to send reInvite, it depends on SRS composition because components that handle RS signaling and actual call state not always the same

Regards

Leon

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 09:29:54 -0400

> considerations come into play.

Agreed and I thought the same as you, including assuming that the SRC could do something different based on the code.
The header could be named "Reason".  ;)

-hadriel

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 27 Jul 2011 07:24:15 -0700

>includes SRS-Initiated recording, it has to be generic enough.

The general problem is that the SRS has no knowledge about the calls in
progress unless the SRC tells the SRS about it or the SRS discovers them
through other means. That's why we don't have a general solution for
SRS-initiated recording. However, it is possible to have the SRS to
initiate a recording session for persistent recording as John mentioned
although I can only see this being useful this only use case.

Since the architecture draft mentioned the possibility of having SRS to
initiate the recording session, it would be logical to have the protocol
draft to provide text to explain how this can work. Perhaps we should ask
whether the architecture draft should actually include this mechanism.

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 27 Jul 2011 07:31:30 -0700

On 11-07-27 12:33 AM, "Hadriel Kaplan" <[email-masked]> wrote:
>
>2) The section says the metadata snapshot request can be sent in an
>UPDATE request, and the SRC can send it in the response.  Since this
>draft describes the SDP as metadata, using an UDPATE model won't work
>since the SRS doesn't have SDP to send in the UPDATE request, and the SRC
>can't put in SDP in a response to UPDATE if there was no SDP offer in the
>request. (compared to re-INVITE, where the SRS can send an offer-less
>re-INVITE, the SRC can send the SDP offer in the 200 and the SRS can send
>the answer in the ACK)

That's a good question. Do we consider a full metadata snapshot as the
combination of both metadata XML plus SDP, or just the metadata XML only?
I was under the impression that it is metadata XML only but it may make
sense to send everything in case the SRS really loses everything it knows
about the recording session.

---

From: Leon Portman <[email-masked]>
Date: Wed, 27 Jul 2011 17:34:46 +0300

I agree that it is a valid scenario however the main question if do we want to handle it now or delay it as a followup work?

Leon

---

From: Leon Portman <[email-masked]>
Date: Wed, 27 Jul 2011 17:41:10 +0300

Yes, I think resending the latest SDP is a good idea because metadata points to there ( at least the current media session elements)

Leon

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jul 2011 11:05:59 -0400

On 7/27/11 10:31 AM, Henry Lum wrote:
>
>
> On 11-07-27 12:33 AM, "Hadriel Kaplan"<[email-masked]>  wrote:
>>

Well, the xml includes the mapping from the MS in xml to the m-line in 
SDP (via label). If we send xml without the SDP, then either we must not 
send the part containing the labels (which would be less than "complete" 
metadata), or else we must specify that the label references are to the 
most recent SDP if SDP is not included.

I can't offhand think of a major reason why this wouldn't work.

This is related to some detail we don't have yet. If we have sent 
metadata for an MS with its label in the past, and later send another 
o/a without metatdata for that MS, must the SDP include the 
corresponding label? Can that label move to a different m-line than it 
was on before?

I think we can go two ways on that:
- any labels that have an outstanding reference from an MS must
   be present in future SDP. If not, it implies the cessation of that MS.

- when MS metadata with a label is received by the SRS, it is
   immediately transformed into an m-line offset, and *that* is saved.
   The MS is bound to the m-line with that offset in all future SDP
   until the metadata is revised.

I'm not sure which of these is better. The second seems a bit simpler. 
But only the first would allow transmitting "full" metadata without an 
offer.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 27 Jul 2011 18:15:04 +0300

I think we should not have "ghost" m-lines in SDP. Meaning that MS currently does not contribute into RS medias, it should not have corresponding label in SDP.

Leon

On Jul 27, 2011, at 6:05 PM, Paul Kyzivat <[email-masked]> wrote:

> Well, the xml includes the mapping from the MS in xml to the m-line in SDP (via label). If we send xml without the SDP, then either we must not send the part containing the labels (which would be less than "complete" metadata), or else we must specify that the label references are to the most recent SDP if SDP is not included.
> 
> This is related to some detail we don't have yet. If we have sent metadata for an MS with its label in the past, and later send another o/a without metatdata for that MS, must the SDP include the corresponding label? Can that label move to a different m-line than it was on before?
> 
> I'm not sure which of these is better. The second seems a bit simpler. But only the first would allow transmitting "full" metadata without an offer.
> 
>    Thanks,
>    Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Jul 2011 11:24:45 -0400

> I think we should not have "ghost" m-lines in SDP. Meaning that MS currently does not contribute into RS medias, it should not have corresponding label in SDP.

I don't know how to interpret that.
Are you expressing support for the first option I listed?
Or are you saying something different?

	Thanks,
	Paul

> Leon
>
> On Jul 27, 2011, at 6:05 PM, Paul Kyzivat<[email-masked]>  wrote:
>

---

From: Leon Portman <[email-masked]>
Date: Wed, 27 Jul 2011 19:50:58 +0300

Yes, first one seems to be more straight forward

Leon

---

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

Hadriel,

The complete metadata request requirement is because metadata XML
processing is done in SRS after sending the success response to metadata
request from SRC. 

Hi all,

I agree with Hadriel for strengthening the usecase for complete metadata
request from SRS. 

I have slight difference of opinion in UPDATE SDP handling:
SIPREC Metadata is always the combination of RS SDP from SRC & metadata
XML. But RS SDP is not required to be offer. In case metadata request
from SRS with UPDATE & SDP message, some of the SDP attributes are
negotiated by SRC but it does not affect the nature of media metadata.
So, 200 OK for UPDATE will carry metadata XML and metadata SDP.  Please
let me know which attribute will have the problem after the negotiation.

Thanks
Partha

> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: Wednesday, July 27, 2011 10:21 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> >> I think we should not have "ghost" m-lines in SDP. Meaning 
> that MS currently does not contribute into RS medias, it 
> should not have corresponding label in SDP.
> > 
> >>>>> 2) The section says the metadata snapshot request can 
> be sent in 
> >>>>> an UPDATE request, and the SRC can send it in the 
> response.  Since 
> >>>>> this draft describes the SDP as metadata, using an UDPATE model 
> >>>>> won't work since the SRS doesn't have SDP to send in the UPDATE 
> >>>>> request, and the SRC can't put in SDP in a response to 
> UPDATE if 
> >>>>> there was no SDP offer in the request. (compared to re-INVITE, 
> >>>>> where the SRS can send an offer-less re-INVITE, the SRC 
> can send 
> >>>>> the SDP offer in the 200 and the SRS can send the answer in the 
> >>>>> ACK)
> >>>> 
> >>>> That's a good question. Do we consider a full metadata 
> snapshot as 
> >>>> the combination of both metadata XML plus SDP, or just 
> the metadata XML only?
> >>>> I was under the impression that it is metadata XML only 
> but it may 
> >>>> make sense to send everything in case the SRS really loses 
> >>>> everything it knows about the recording session.
> >>> 
> >>> Well, the xml includes the mapping from the MS in xml to 
> the m-line in SDP (via label). If we send xml without the 
> SDP, then either we must not send the part containing the 
> labels (which would be less than "complete" metadata), or 
> else we must specify that the label references are to the 
> >>> This is related to some detail we don't have yet. If we 
> have sent metadata for an MS with its label in the past, and 
> later send another o/a without metatdata for that MS, must 
> the SDP include the corresponding label? Can that label move 
> to a different m-line than it was on before?
> >>> 
> >>> - any labels that have an outstanding reference from an 
> MS must  be 
> >>> present in future SDP. If not, it implies the cessation 
> of that MS.
> >>> 
> >>> I'm not sure which of these is better. The second seems a 
> bit simpler. But only the first would allow transmitting 
> "full" metadata without an offer.
> >>> 
> >>>    Thanks,
> >>>    Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Jul 2011 22:13:18 +0200

In my mind, the prime reason for sending a snapshot request was if the SRS, somehow, had lost a partial update. This assumes that updates are sequence numbered. If there is a gap in sequence numbering, request the complete metadata. I don't know how likely this is, but I feel uncomfortable blindly accepting updates on the assumption that that there is no gap in sequencing. It is probably better to detect the gap in sequencing and take action then, rather than waiting for some error to occur (e.g., a reference to an object ID that you don't know existed because you missed the update that created that object).

It tend to agree that total failures of SRS, resulting in loss of state, would result in loss of the RS dialog, and hence a need to recover the whole RS. I also agree that badly formed XML, for example, is unlikely to be corrected by asking for a snapshot.

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.

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 27 July 2011 05:34
> To: Adam Roach
> Cc: Henry Lum; SIPREC (SIP Recording) WG; 
> ISO 639 has like over 400 active languages.  Do we really 
> want to have to deal with it, even for only the top 10-20 languages?
> Besides, logging of SIP message info is already full of 
> English so it's not like one can really avoid it.  And this 
> isn't for human consumption - it's for engineers. ;)
> 
> For at least the first two reasons, I don't see how asking 
> for the metadata again is going to fix anything.  It's not 
> like the SRC can change the syntax or semantics of the 
> metadata it sent to the SRS previously.  It' going to get the 
> same error again, and again, and again.  And for the third 
> reason (failure of the SRS), are we saying the SRS has enough 
> saved state to be able to send the in-dialog snapshot 
> re-INVITE request, but not to remember the actual metadata?

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 28 Jul 2011 08:00:22 -0700

Are you suggesting that we need to introduce a new sequence number to each
metadata update at the metadata level or at the protocol level? Since
metadata updates are sent over INVITE or UPDATE transaction, each update
needs to be sent in sequential order although there is no explicit
numbering for each update. I am assuming that each update transaction can
be transported successfully to the SRS in order, although it is possible
for the SRS to lose an update for whatever reason beyond the transport
level so the SRS may be unaware that it has lost an update.

Henry

On 11-07-27 4:13 PM, "Elwell, John" <[email-masked]>
wrote:

>In my mind, the prime reason for sending a snapshot request was if the
>SRS, somehow, had lost a partial update. This assumes that updates are
>sequence numbered. If there is a gap in sequence numbering, request the
>complete metadata. I don't know how likely this is, but I feel
>uncomfortable blindly accepting updates on the assumption that that there
>is no gap in sequencing. It is probably better to detect the gap in
>sequencing and take action then, rather than waiting for some error to
>occur (e.g., a reference to an object ID that you don't know existed
>because you missed the update that created that object).
>
>It tend to agree that total failures of SRS, resulting in loss of state,
>would result in loss of the RS dialog, and hence a need to recover the
>whole RS. I also agree that badly formed XML, for example, is unlikely to
>be corrected by asking for a snapshot.
>
>John (as individual)
>
>John Elwell

---

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

Henry,

Could you please explain the usecase/scenario wherein metadata is lost in SRS apart from transport failure or system crash 

Thanks
Partha 

> Sent: Thursday, July 28, 2011 8:30 PM
> To: Elwell, John; Hadriel Kaplan; Adam Roach
> Cc: SIPREC (SIP Recording) WG; 
> Subject: Re: [siprec] Reasons for snapshot request
> 
> Are you suggesting that we need to introduce a new sequence 
> number to each metadata update at the metadata level or at 
> the protocol level? Since metadata updates are sent over 
> INVITE or UPDATE transaction, each update needs to be sent in 
> sequential order although there is no explicit numbering for 
> each update. I am assuming that each update transaction can 
> be transported successfully to the SRS in order, although it 
> is possible for the SRS to lose an update for whatever reason 
> beyond the transport level so the SRS may be unaware that it 
> has lost an update.
> 
> Henry
> 
> >uncomfortable blindly accepting updates on the assumption that that 
> >there is no gap in sequencing. It is probably better to 
> detect the gap 
> >in sequencing and take action then, rather than waiting for 
> some error 
> >to occur (e.g., a reference to an object ID that you don't 
> know existed 
> >It tend to agree that total failures of SRS, resulting in loss of 
> >state, would result in loss of the RS dialog, and hence a need to 
> >recover the whole RS. I also agree that badly formed XML, 
> for example, 
> >is unlikely to be corrected by asking for a snapshot.
> >
> >John (as individual)
> >
> >John Elwell
> >> ISO 639 has like over 400 active languages.  Do we really want to 
> >> have to deal with it, even for only the top 10-20 languages?
> >> Besides, logging of SIP message info is already full of English so 
> >> it's not like one can really avoid it.  And this isn't for human 
> >> consumption - it's for engineers. ;)
> >> 
> >> For at least the first two reasons, I don't see how asking for the 
> >> metadata again is going to fix anything.  It's not like 
> the SRC can 
> >> change the syntax or semantics of the metadata it sent to the SRS 
> >> previously.  It' going to get the same error again, and again, and 
> >> again.  And for the third reason (failure of the SRS), are 
> we saying 
> >> the SRS has enough saved state to be able to send the in-dialog 
> >> snapshot re-INVITE request, but not to remember the actual 
> metadata?

---

From: [email-masked]
Date: Thu, 28 Jul 2011 17:04:16 +0000

It can be for example crash of one of SRS components that responsible for maintain such state.

Leon
Sent from my BlackBerry® smartphone from orange

-----Original Message-----
From: "Parthasarathi R (partr)" <[email-masked]>
Sender: [email-masked]
Date: Thu, 28 Jul 2011 22:29:37 
To: Henry Lum<[email-masked]>; Elwell, John<[email-masked]>; Hadriel Kaplan<[email-masked]>; Adam Roach<[email-masked]>
Cc: SIPREC \(SIP Recording\) WG<[email-masked]>; <[email-masked]>
Subject: Re: [siprec] Reasons for snapshot request

Henry,

Thanks
Partha

---

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

Leon,

High availability in SRS will serve the purpose and there is no need to query SRC for it. IMO, it is more specific to SRS implementation.

Thanks
Partha 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 28, 2011 10:34 PM
> To: Parthasarathi R (partr); [email-masked]; Henry 
> Lum; John Elwell; Hadriel Kaplan; Adam Roach
> Sent from my BlackBerry(r) smartphone from orange
> 
> To: Henry Lum<[email-masked]>; Elwell, 
> John<[email-masked]>; Hadriel 
> Kaplan<[email-masked]>; Adam Roach<[email-masked]>
> Cc: SIPREC \(SIP Recording\) WG<[email-masked]>; 
> <[email-masked]>
> Could you please explain the usecase/scenario wherein 
> metadata is lost in SRS apart from transport failure or system crash 
> 
> Thanks
> Partha 
> 
> number to 
> > each metadata update at the metadata level or at the 
> protocol level? 
> > Since metadata updates are sent over INVITE or UPDATE transaction, 
> > each update needs to be sent in sequential order although 
> there is no 
> > explicit numbering for each update. I am assuming that each update 
> > transaction can be transported successfully to the SRS in order, 
> > although it is possible for the SRS to lose an update for whatever 
> > reason beyond the transport level so the SRS may be unaware that it 
> > has lost an update.
> > 
> > Henry
> > 
> > >Siemens Enterprise Communications Limited is a Trademark 
> Licensee of 
> > >Siemens AG.
> > >
> > >
> English so 
> may contain 
> > confidential and proprietary information of Alcatel-Lucent 
> and/or its 
> > affiliated entities. Access by the intended recipient only is 
> > authorized. Any liability arising from any party acting, or 
> refraining 
> > from acting, on any information contained in this e-mail is hereby 
> > excluded. If you are not the intended recipient, please notify the 
> > sender immediately, destroy the original transmission and its 
> person, use 
> > it for any purpose, or store or copy the information in any medium. 
> > Copyright in this e-mail and any attachments belongs to 
> Alcatel-Lucent

---

From: Michael Baj <[email-masked]>
Date: Thu, 28 Jul 2011 17:14:36 +0000

Leon,

In this use case, would it not also be the case that when the system recovers from the crash, that it has also lost its SIP dialog state for the RS?  In which case, how could it even request an update for the metadata when it can't communicate to the SRC?

In general, I have not seen a practical use case where a metadata update is required.  If we can't come up with a practical use case, I see little need for this to exist in the draft.

Mike

---

From: [email-masked]
Date: Thu, 28 Jul 2011 17:15:06 +0000

Partha Hi

Actually assumption of high availability (redundancy) on SRS side is implementation or deployment decision. It is always a good idea for delta based protocol to be able to send current snapshot of the state in order to make sure that both side are in synch.

Leon 

-----Original Message-----
From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 28 Jul 2011 22:39:17 
To: <[email-masked]>; <[email-masked]>; Henry Lum<[email-masked]>; John Elwell<[email-masked]>; Hadriel Kaplan<[email-masked]>; Adam Roach<[email-masked]>
Cc: SIPREC (SIP Recording) WG<[email-masked]>; <[email-masked]>
Subject: RE: [siprec] Reasons for snapshot request

Leon,

Thanks
Partha

---

From: [email-masked]
Date: Thu, 28 Jul 2011 17:16:30 +0000

Michael Hi

It is not always the case where RS sessions and media are not terminated at the same components as one that maintains states and populates database.

Leon

-----Original Message-----
From: Michael Baj <[email-masked]>
Date: Thu, 28 Jul 2011 17:14:36 
To: <[email-masked]><[email-masked]>
Cc: [email-masked]<[email-masked]>
Subject: Re: [siprec] Reasons for snapshot request

Leon,

Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 13:17:38 -0400

> It can be for example crash of one of SRS components that responsible for maintain such state.

Yes I figured someone could theoretically store the XML metadata in an offline database but store the SIP and SDP state info locally, and a databse corruption/failure could somehow require re-learning the XML info.  But I just want to make sure that the odds of such a thing are high enough or important enough to recover from, because this complicates the protocol -  and making the protocol more complicated increases the chances of failure or interop problems, not to mention testing and troubleshooting and such.  The alternative is to say in such a failure case the SRS just ends the RS session. (it is a failure case after all)

-hadriel

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 28 Jul 2011 10:37:21 -0700

I agree we don't want to follow a path where we come up with a complex
recovery mechanism that dictates certain implementation. The SRS always
have the option of terminating the RS anyways, so I think whatever we come
up with should be really simple to address some basic cases.

Henry

On 11-07-28 1:17 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>Yes I figured someone could theoretically store the XML metadata in an
>offline database but store the SIP and SDP state info locally, and a
>databse corruption/failure could somehow require re-learning the XML
>info.  But I just want to make sure that the odds of such a thing are
>high enough or important enough to recover from, because this complicates
>the protocol -  and making the protocol more complicated increases the
>chances of failure or interop problems, not to mention testing and
>troubleshooting and such.  The alternative is to say in such a failure
>case the SRS just ends the RS session. (it is a failure case after all)
>
>-hadriel
>
>

---

From: [email-masked]
Date: Thu, 28 Jul 2011 17:41:12 +0000

I don't think that terminating RS from SRS side and loosing recording is a good way for SRS to learn missing CS metadata

Leon

-----Original Message-----
From: "Henry Lum" <[email-masked]>
Date: Thu, 28 Jul 2011 10:37:21 
To: Hadriel Kaplan<[email-masked]>; <[email-masked]>
Cc: Parthasarathi R (partr)<[email-masked]>; <[email-masked]>; John Elwell<[email-masked]>; Adam Roach<[email-masked]>; SIPREC (SIP Recording) WG<[email-masked]>; <[email-masked]>
Subject: Re: [siprec] Reasons for snapshot request

Henry

---

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

At the meeting yesterday there seemed to be support from some people (e.g., Adam Roach) for having the snapshot request available for cases where the SRS has failed to receive one or more updates, as detected by examining sequence numbers. The consensus of the meeting was that we need it for this case at least (and if we have it for this case, I think Leon's concern would be accommodated too).

John

John Elwell

> Sent: 28 July 2011 18:41
> To: Henry Lum; Hadriel Kaplan
> Cc: Parthasarathi R (partr); [email-masked]; Elwell, 
> John; Adam Roach; SIPREC (SIP Recording) WG; 
> I don't think that terminating RS from SRS side and loosing 
> recording is a good way for SRS to learn missing CS metadata
> 
> Leon
> Cc: Parthasarathi R (partr)<[email-masked]>; 
> <[email-masked]>; John 
> Elwell<[email-masked]>; Adam 
> Roach<[email-masked]>; SIPREC (SIP Recording) 
> WG<[email-masked]>; <[email-masked]>
> >> It can be for example crash of one of SRS components that 
> responsible
> >>for maintain such state.
> >

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 29 Jul 2011 07:37:50 -0700

To make it as lightweight as possible, what if the one and only way for
an SRS to request a metadata snapshot is in response to a metadata
update?
For example, the SRC sends a SIP UPDATE or re-INVITE with metadata.
The SRS indicates in its response that it needs a snapshot, perhaps
using a SIP error response (e.g. 488 or a new one) with an appropriate
reason phrase.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Friday, July 29, 2011 8:14 AM
> To: [email-masked]; Henry Lum; Hadriel Kaplan
> Cc: [email-masked];
[email-masked]; SIPREC (SIPRecording) WG
> At the meeting yesterday there seemed to be support from some people
(e.g., Adam Roach) for having the
> snapshot request available for cases where the SRS has failed to
receive one or more updates, as
> detected by examining sequence numbers. The consensus of the meeting
was that we need it for this case
> at least (and if we have it for this case, I think Leon's concern
would be accommodated too).

---

From: [email-masked]
Date: Fri, 29 Jul 2011 14:41:02 +0000

I am not sure about that. Metadata update could be sent after very long time leaving SRS in non consistent state.

Leon

-----Original Message-----
From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 29 Jul 2011 07:37:50 
To: Elwell, John<[email-masked]>; <[email-masked]>; Henry Lum<[email-masked]>; Hadriel Kaplan<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; SIPREC (SIPRecording) WG<[email-masked]>
Subject: RE: [siprec] Reasons for snapshot request

Cheers,
Charles

Behalf Of Elwell, John

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 29 Jul 2011 07:41:50 -0700

I like this idea, however, the badly behaving SRS will have to wait until the next update coming from the SRC before having a chance to ask for a snapshot request. Will this work for the SRS? Perhaps Leon who is asking for this feature can comment on this.
 
Henry

________________________________

From: Charles Eckel (eckelcu) [mailto:[email-masked]]
Sent: Fri 7/29/2011 10:37 AM
To: Elwell, John; [email-masked]; Henry Lum; Hadriel Kaplan
Cc: [email-masked]; [email-masked]; SIPREC (SIPRecording) WG
Subject: RE: [siprec] Reasons for snapshot request

Cheers,
Charles

Behalf Of Elwell, John

---

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

I like this approach, but 488 is not specific enough (it can also be used to reject and SDP offer), and I don't think any existing response code would fit. Perhaps we have to define a new one.

John (as individual) 

> Sent: 29 July 2011 15:38
> > Registered office: Brickhill Street, Willen Lake, Milton 
> Keynes, MK15
> 0DJ.
> > > WG<[email-masked]>; 
> > > >offline database but store the SIP and SDP state info 
> locally, and
> a

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 30 Jul 2011 00:01:01 +0530

Couple of questions:
- Are we saying here that a SRS must send an error response (4XX) on
getting an error while processing an UPDATE/re-INVITE request having
SIPREC XML  body ?
 Or are we saying that an SRS in response to a UPDATE/re-INVITE asks for
complete snapshot through an error code even though the processing of
UPDATE itself may not have any errors ?

I agree with Leon that this may not be efficient as an SRS has to wait
till it receives an UPDATE/re-INVITE from SRC before asking for a
snapshot by when it may have already lost a good amount of metadata.

Ram

> Sent: Friday, July 29, 2011 2:00 PM
> To: Charles Eckel (eckelcu); [email-masked]; Henry Lum;
> HadrielKaplan
> Cc: [email-masked]; draft-portman-siprec-
> [email-masked]; SIPREC (SIPRecording) WG
> I like this approach, but 488 is not specific enough (it can also be
> used to reject and SDP offer), and I don't think any existing response
> code would fit. Perhaps we have to define a new one.
> 
> John (as individual)
> 
> > > Siemens Enterprise Communications Limited is a Trademark Licensee
> of
> > Siemens AG.
> > >
> > >
> > > > >databse corruption/failure could somehow require re-learning
the
> > XML
> > > > >info.  But I just want to make sure that the odds of such a
> thing
> > are

---

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

An SRS could do either, but the former is how I would expect for the
mechanism to be used in general. If an SRS experiences some asynchronous
error or detects a mismatch independent of SIP re-INVITE/UPDATE, then
the latter case could apply. But I see that as being pretty unlikely and
would not want to complicate the protocol unnecessarily to accommodate
it.

Cheers,
Charles

> From: Ram Mohan R (rmohanr)
> Sent: Friday, July 29, 2011 2:31 PM
> To: Elwell, John; Charles Eckel (eckelcu); [email-masked];
Henry Lum; HadrielKaplan
> - Are we saying here that a SRS must send an error response (4XX) on
getting an error while processing
> an UPDATE/re-INVITE request having SIPREC XML  body ?
>  Or are we saying that an SRS in response to a UPDATE/re-INVITE asks
for complete snapshot through an
> error code even though the processing of UPDATE itself may not have
any errors ?
> I agree with Leon that this may not be efficient as an SRS has to wait
till it receives an UPDATE/re-
> INVITE from SRC before asking for a snapshot by when it may have
already lost a good amount of
> metadata.
> > > [email-masked]; SIPREC
(SIPRecording)
> > WG
> > > [email-masked]; SIPREC
(SIPRecording)
> > WG
Licensee
the

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 30 Jul 2011 03:54:22 +0530

Inline

> From: Charles Eckel (eckelcu)
> Sent: Friday, July 29, 2011 5:46 PM
> To: Ram Mohan R (rmohanr); 'Elwell, John'; [email-masked]';
> 'Henry Lum'; 'HadrielKaplan'
> Cc: [email-masked]'; 'draft-portman-siprec-
> [email-masked]'; 'SIPREC (SIPRecording) WG'
> mechanism to be used in general. If an SRS experiences some
> asynchronous error or detects a mismatch independent of SIP re-
> INVITE/UPDATE, then the latter case could apply. But I see that as
> being pretty unlikely and would not want to complicate the protocol
> unnecessarily to accommodate it.

Even I would expect the first mechanism to be used most of the times. I
just asked the question to get a clear understanding on what the
proposal here is.  However the challenge here is if an SRS detects
asynchronous errors.

IMO the second one is not the right way due to following reasons:
- an SRS may not prefer to wait till its next message (UPDATE/re-INVITE)
by when it would have lost some information. Not all SRC may store the
past information and hence this approach may not work
- I am also not sure if its right to respond to a SIP message with a 4XX
response (intending to request for something) even though the processing
of message itself did NOT result in any errors.

So I don't prefer option 2.
Ram

> > I agree with Leon that this may not be efficient as an SRS has to
> wait till it receives an UPDATE/re-
> > > > > > I agree we don't want to follow a path where we come up with
> a
> > > > complex
> > > > > > On 11-07-28 1:17 PM, "Hadriel Kaplan"
> <[email-masked]>
> > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >troubleshooting and such.  The alternative is to say in
such
> > > > > > a failure
> > > > > > >case the SRS just ends the RS session. (it is a failure
case
> > > > > > after all)
-------------------------------------------------------------
> -

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 30 Jul 2011 01:03:12 +0200

On second thoughts, I am not so sure about this approach. The SIP response code is meant to denote an error at the SIP layer, not the application layer. Furthermore, I would imagine some implementations might send a 200 response (to denote reception), then pass the XML to the application layer. If the application layer then detects a sequence error it is too late to send a 4xx response.

John (as individual) 

> From: Elwell, John 
> Sent: 29 July 2011 19:00
> To: 'Charles Eckel (eckelcu)'; [email-masked]; Henry 
> Lum; Hadriel Kaplan
> I like this approach, but 488 is not specific enough (it can 
> also be used to reject and SDP offer), and I don't think any 
> existing response code would fit. Perhaps we have to define a new one.
> 
> John (as individual) 
> 
> (SIPRecording) WG
> (SIPRecording) WG
> > > > >databse corruption/failure could somehow require 
> re-learning the
> > XML
> > > > >info.  But I just want to make sure that the odds of 
> such a thing
> > are

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jul 2011 20:58:21 -0400

IMO we should not assume that the SRS processes the metadata before 
responding to the message carrying it. (And I think we decided that long 
ago.) Hence I think it unreasonable to use an error response to the sip 
message to indicate there are issues with the metadata. (Its also a 
"layer violation".)

And if we are not assuming that, then it seems unreasonable for the SRS 
to have to wait for another request from the SRC before it can request a 
snapshot.

So, I think the request for a snapshot should be handled as *some* sort 
of data in a body of a message from SRS to SRC. I think it does not 
matter whether that is carried in a request or a response. I'm less 
concerned with the *form* of that body.

	Thanks,
	Paul