Subject: Re: [siprec] Reasons for snapshot request

From: "Henry Lum" <[email-masked]>
Date: Thu, 4 Aug 2011 08:06:42 -0700

I think we have already discussed this before that the SIP response is
processed before the application layer so it would be "too late" for an
SRS to send a SIP error response to indicate issues with the metadata in
this message. What I was initially thinking of is that if the SRS is in
a troubled state it could generate a SIP error response regardless of
what the application content is, however, as others have pointed out
this is problematic since it would take a long time before the SRC
generate another update. 

Speaking of the content of the snapshot body, some has suggested to
govern response codes instead of free-form text so that we don't have to
deal with internationalization. What kind of response code can we come
up with for an SRS? So far we have identified two failure scenarios that
an SRS can issue a snapshot request for (with the proposed codes):

- 500 SRS Internal Error
- 510 Missing Metadata Sequence Number

We have agreed that syntax and semantic errors do not belong to snapshot
requests; do we have other failure scenarios to spell out?

Regards,
Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Friday, July 29, 2011 8:58 PM
To: [email-masked]
Subject: Re: [siprec] Reasons for snapshot request

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

On 7/29/11 5:46 PM, Charles Eckel (eckelcu) wrote:
> 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
>
>> -----Original Message-----
>> From: Ram Mohan R (rmohanr)

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

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

-------------------------------------------------------------------------------------------------------------------
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: Thu, 04 Aug 2011 12:21:49 -0400

> requests; do we have other failure scenarios to spell out?

There is another option: a text value that is not intended for display 
to an end user - but only for logging. As long as its presented that way 
I don't think we run into internationalization issues. And since the SRC 
will typically not be attached to a user directly, it probably wouldn't 
want to display it anyway.

I don't think we really need codes, because there aren't really any 
distinct actions to be taken by the SRC. Always just the same action - 
to send a snapshot.

IMO this is "good enough".

	Thanks,
	Paul