Subject: Re: [siprec] Metadata XML document error representation for whole doc or for portion of doc

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 2 Mar 2011 16:52:14 +0530

Hi all,

Thanks for your opinion and suggestion. From this mail thread, it is
clear that there is no known usecase for error indication to the portion
of the Metadata XML document but the error response *MUST* be send back
by SRS to SRC through application (SIP) mechanism. I'll update -01
version of draft-ram-siprec-metadata-format-00 based on this conclusion.

Thanks
Partha   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Leon Portman
Sent: Monday, February 28, 2011 9:48 PM
To: Henry Lum; Paul Kyzivat (pkyzivat); Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Metadata XML document error representation
forwhole doc or for portion of doc

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Monday, February 28, 2011 6:13 PM
To: Paul Kyzivat; Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Metadata XML document error representation for
whole doc or for portion of doc

> >> We are also thinking of providing the SRS with a mechanism to 
> >> request the SRC to ask for the current snapshot
> so
> >> that the SRC/SRS can reset the states in the case where SRS is in a

> >> really bad state. By doing so, we may be able to avoid providing
> nack
> >> responses and avoid using a chatty protocol.
> > [JRE] Yes, and the request to resend full metadata could optionally
> include some sort of error report that gave rise to the request. That 
> error report could, for example, include the sequence number of the 
> metadata update that was found to be in error.
> 
> That is sort of what I had in mind about getting the two sides in
sync.
> But we will have to think more about exactly what it means.
> At best I think it will describe the *current* state of things in this

> RS, without regard to what has happened in the past.
> 
> Even that may present some technical challenges. But we should keep 
> this desire in mind.

[[hlum]] I agree it would be reasonable for the SRC to send the current
state as a snapshot and forget what happened previously. The subsequent
sequence numbers only refers to the current snapshot rather than the
original one, so in a way we are resetting the sequence number.

------------------------------------------------------------------------
-------------------------------------------
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
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 2 Mar 2011 19:17:33 +0530

Hi all, 

Another issue discussed as part of the below mail thread is whether
metadata (XML+SDP) error has to be responded synchronously (SIP
Request/[SIP provisional response]/SIP Response) or asynchronously(SIP
Request/SIP Response/SIP Error request/SIP Error response).

Synchronous Error handling:
>From SRC perspective, synchronous error handling is simple to implement
as there is no extra context or state to be maintained about the earlier
SIP transactions. 

In SRS, SDP Metadata portion *MUST* be processed in synchronously to
meet offer/answer model requirement. Now the question is whether XML
takes so much of a time wherein the error MUST be handled asynchronous?
The simple SRS will be able to send provisional response and respond
back final response once the complete XML check is done. My reasoning is
so because B2BUA normally handles INVITE/RE-INVITE in a way that send
(100 trying) provisional response to the incoming dialog side, send
INVITE/RE-INVITE to the outgoing dialog side which may take upto 32 sec
delay to respond and forwards 200 OK to incoming dialog side once it is
received from outgoing dialog side and it is well working deployed
model. Please let me know in which situation this mechanism has issues
specific to SIPREC & XML.

Asynchronous Error handling:
Here as well in SRS, SDP Metadata portion *MUST* be processed in
synchronously to meet offer/answer model requirement. 
  
Two cases exists from SRC perspective.
1) In case the sequence number has to be maintained by SRC for
asynchronous error handling, then it *MAY* require SRC to maintain the
earlier transaction which is overkill as SRC will not keep track or
record its previous state. 

2) In most of the scenario, it is not possible to re-record but it is
only possible to re-sync. In case the motivation of asynchronous error
is to re-sync metadata by SRS to SRC, it is very similar to SRS
requesting for current complete metadata (SDP+XML) from SRC. On
receiving re-sync request, SRC has to trigger the complete metadata
towards SRS. The sequence number from SRS *MAY* be used for logging
purpose if required. 

Please let me know which one of the above asynchronous behavior is
expected from SRC. Also, instead of asynchronous error message, do you
wish to create re-sync request mechanism from SRS which may be used for
error or other purpose as well.

Thanks
Partha

-----Original Message-----

+1

Leon

-----Original Message-----

sync.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 3 Mar 2011 15:41:38 -0800

Hi Partha,

I think we need both. If the error is detected in SDP processing,
handling it in the SIP response synchronously makes sense. If the error
is detected in the metadata processing, it would ideally be handled in
the SIP response synchronously, but it may result in a subsequent
request being sent to indicate and/or recover from the error. Errors may
also be encountered independent of any SIP request processing, and those
will need to be handled asynchronously.
So I think we need both, and how much of the XML to process
synchronously is up to the answerer. Ideally we will structure the XML
such that it is as clear and efficient as possible to identify the XML
that directly impacts the SDP. This will facilitate synchronous
responses.

Cheers,
Charles 

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Parthasarathi R (partr)
> Sent: Wednesday, March 02, 2011 5:48 AM
> To: Leon Portman; Henry Lum; Paul Kyzivat (pkyzivat); Elwell, John
> Cc: [email-masked]
> Subject: [siprec] Synchronous vs Asynchronous Error handling
> 
> Hi all,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Mar 2011 20:37:01 -0500

Charles,

Its my expectation that none of the metadata *need* be processed in 
order to answer an sdp offer. However the sdp will typically be required 
to supplement the metadata processing. So it likely will be necessary to 
queue the xml+sdp for later processing as metadata.

One might want to make decisions about how to construct the answer (e.g. 
whether to accept or reject a media stream) based on the xml metadata. 
If one is capable of doing all the processing synchronously in order to 
do so, go for it. But nobody should be forced to do that.

	Thanks,
	Paul

On 3/3/2011 6:41 PM, Charles Eckel (eckelcu) wrote:
>> specific to SIPREC&  XML.
> Behalf
> Behalf

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 4 Mar 2011 09:22:06 -0800

Hi Paul,

I think we are both saying the same thing, but let me make sure. In
cases in which processing everything synchronously is not feasible, an
implementation MUST send an SDP answer synchronously in order to
complete the existing SIP transaction, then complete the processing of
the metadata asynchronously, and if required, MAY send an offer in
another SIP transaction to address and changes required.

Cheers,
Charles

> From: Paul Kyzivat (pkyzivat)
> Sent: Thursday, March 03, 2011 5:37 PM
> To: Charles Eckel (eckelcu)
> Cc: Parthasarathi R (partr); Leon Portman; Henry Lum; Elwell, John;
[email-masked]
> Subject: Re: [siprec] Synchronous vs Asynchronous Error handling
> 
> Charles,
> 
> >> back final response once the complete XML check is done. My
reasoning
> > is
> >> delay to respond and forwards 200 OK to incoming dialog side once
it
> > is
for
> >>>>> that the SRC/SRS can reset the states in the case where SRS is
in
> > a
> >> attachments and do not disclose the contents to any other person,
use
> > it

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 4 Mar 2011 09:40:36 -0800

SDP processing and metadata processing should be handled independently
and that you can still answer the SDP without requiring metadata to be
processed first. Even though metadata is referencing the label attribute
in the SDP, SDP is not dependent on the metadata.

I also agree that if the SRS can actually interpret and process metadata
in the UPDATE/INVITE request, then it is up to the implementation to do
so. I think what's more important is that we should not need a positive
acknowledgement from the SRS before SRC sends the next metadata update
so that the protocol does not become too chatty. The only
acknowledgement the SRC needs is that the message is received by the SRS
by way of getting a final response in the INVITE/UPDATE.

Regards,
Henry

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, March 03, 2011 8:37 PM
it
for
in
> >> original one, so in a way we are resetting the sequence number.
---------------------------------------------------------------------
> ---

-------------------------------------------------------------------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2011 13:11:43 -0500

yes

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 7 Mar 2011 13:09:42 +0530

IIRC, asynchronous Error handling of metadata is required to re-sync
between SRS & SRC and SRS has to trigger re-sync. Let us discuss the
exact mechanism as part of draft-portman-siprec-protocol-03 draft
review.

Thanks
Partha

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Friday, March 04, 2011 11:42 PM
To: Charles Eckel (eckelcu)
Cc: Parthasarathi R (partr); Leon Portman; Henry Lum; Elwell, John;
[email-masked]

yes