Subject: [siprec] Transport of snapshot request

From: "John Elwell" <[email-masked]>
Date: Thu, 17 Nov 2011 09:15:08 -0000

There has been a long thread discussing the SIP messages for snapshot 
requests.

First, I see no reason to tie the snapshot request and the metadata 
transmission to the same transaction (request/response). If they are tied 
together, this imposes unncessary time and architectural constraints on the 
SRC. I much prefer an approach similar to the subscribe/notify approach of 
RFC 3265 - use different transactions. I am rather unsympathetic to 
allowing, as an option, metadata transmission in a response. Apart from the 
timing and arcchitectural concerns, there is no means of responding to a 
response if anything is wrong. Keep it simple, and allow metadata 
transmission only in requests, as in NOTIFY.

Second, I think it is an SRC decision whether it needs a further 
offer-answer exchange. When sending the request containing the metadata, the 
SRC must ensure that any references to media description labels are 
consistent with the last SDP sent by the SRC - if not, the SRC can initiate 
a further offer-answer exchange at the same time as the metadata 
transmission.

Perhaps it is my imagination, but I thought we had on the table at one time 
the notion of:
- SRS sends snapshot request in an UPDATE request.
- SRC sends medata in an UPDATE request (with offer if it needs to change 
SDP, otherwise without).

I have lost track of how we came to diverge from this simple model.

John

---

From: Leon Portman <[email-masked]>
Date: Thu, 17 Nov 2011 17:46:37 +0800

John, Nice to have you back on the list.

Actually discussion during IETF meeting was started to converge to similar as you describe below.

Regards

Leon

On Nov 17, 2011, at 5:15 PM, John Elwell wrote:

> There has been a long thread discussing the SIP messages for snapshot requests.
> 
> First, I see no reason to tie the snapshot request and the metadata transmission to the same transaction (request/response). If they are tied together, this imposes unncessary time and architectural constraints on the SRC. I much prefer an approach similar to the subscribe/notify approach of RFC 3265 - use different transactions. I am rather unsympathetic to allowing, as an option, metadata transmission in a response. Apart from the timing and arcchitectural concerns, there is no means of responding to a response if anything is wrong. Keep it simple, and allow metadata transmission only in requests, as in NOTIFY.
> 
> Second, I think it is an SRC decision whether it needs a further offer-answer exchange. When sending the request containing the metadata, the SRC must ensure that any references to media description labels are consistent with the last SDP sent by the SRC - if not, the SRC can initiate a further offer-answer exchange at the same time as the metadata transmission.
> 
> Perhaps it is my imagination, but I thought we had on the table at one time the notion of:
> - SRC sends medata in an UPDATE request (with offer if it needs to change SDP, otherwise without).
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Brad Winslow <[email-masked]>
Date: Wed, 23 Nov 2011 16:52:41 +0000

Hi Folks,

In the situation where the SRS needs a metadata update, it most likely will need an SDP update, as there is no guarantee the metadata-only update would be consistent with the current SDP label attributes of the SRS, aren't we asking for trouble if we allow a metadata-only update?  If we decide on a full update, metadata + SDP, should we settle on UPDATE or INVITE to transmit the update from SRC to SRS?

As an aside, there is an expectation that the SRC behaves as a SIP UA, in this case it should be able to respond to an offer-less re-INVITE from the SRS and provide metadata and SDP in the response.

Finally, if the SRS receives an INVITE for a new recording session, should we have an error code response which indicates the SRS is not interested in recording the session, not as a failure status, just as a status to terminate the recording.  This presupposes the SRS may make policy decisions for recording.

Thanks in advance for your thoughts,
Brad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: Thursday, November 17, 2011 4:47 AM
To: John Elwell
Cc: [email-masked]
Subject: Re: [siprec] Transport of snapshot request

Regards

Leon

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 1 Dec 2011 00:47:28 +0000

Hi all,

I agree with UPDATE without SDP based snapshot request in case there is 
an agreement that SRS will never generate offer as there is no possibility
of offer-answer race condition based on snapshot request mechanism. So,
I'm interested in hearing everybody opinion on "no offer from SRS" stance
For SIPREC. 

Brad/John,

Please read inline.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Brad Winslow
>Sent: Wednesday, November 23, 2011 10:23 PM
>To: [email-masked]
>In the situation where the SRS needs a metadata update, it most likely
>will need an SDP update, as there is no guarantee the metadata-only
>update would be consistent with the current SDP label attributes of the
>SRS, aren't we asking for trouble if we allow a metadata-only update?
<partha> Snapshot request UPDATE without SDP from SRS is used to trigger
Metadata request in SRC using RE-INVITE or UPDATE method 
</partha>

>If we decide on a full update, metadata + SDP, should we settle on
>UPDATE or INVITE to transmit the update from SRC to SRS?
<partha> We have common understanding here </partha>

>
>As an aside, there is an expectation that the SRC behaves as a SIP UA,
>in this case it should be able to respond to an offer-less re-INVITE
>from the SRS and provide metadata and SDP in the response.
>
<partha> offerless Re-INVITE with 100 + 200 response is currently considered 
as alternative Proposal to UPDATE without SDP snapshot request </partha>

>Finally, if the SRS receives an INVITE for a new recording session,
>should we have an error code response which indicates the SRS is not
>interested in recording the session, not as a failure status, just as a
>status to terminate the recording.  

<partha> It will be negative response in case INVITE with require:siprec is 
not accepted using 200 OK right? Do we need the new server negative 5xx 
response code for this policy decision? </partha>
 
This presupposes the SRS may make
>policy decisions for recording.
>
>transmission to the same transaction (request/response). If they are
>tied together, this imposes unnecessary time and architectural
>constraints on the SRC. 

<partha> The model proposed is request/provisional response/response
Wherein RE-INVITE/100/200 trying shall be used wherein there is no
Immediate response to SRS. </partha>

I much prefer an approach similar to the
>subscribe/notify approach of RFC 3265 - use different transactions.

<partha> The downside of this approach is 4 SIP messages per every
Service. I'm seeing the middle ground of offerless RE-INVITE with
Provisional response (100) and final response wherein 3 messages are 
Involved but there is no extra offer/answer race condition from SRS. 

Having said that, in case it is confirmed that SRS will never offer
Then I'm fine with UPDATE based snapshot request </partha>

 I am
>rather unsympathetic to allowing, as an option, metadata transmission in
>a response. Apart from the timing and architectural concerns, there is
>no means of responding to a response if anything is wrong. Keep it
>simple, and allow metadata transmission only in requests, as in NOTIFY.
>>
>offer-answer exchange. When sending the request containing the metadata,
>the SRC must ensure that any references to media description labels are
>consistent with the last SDP sent by the SRC - if not, the SRC can
>initiate a further offer-answer exchange at the same time as the
>metadata transmission.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Dec 2011 10:46:59 +0800

> I'm interested in hearing everybody opinion on "no offer from SRS" stance

I don't see how it would ever make sense for the SRS to make an offer to 
the SRC, so I'm fine with declaring that invalid SRS behavior.

As far as a snapshot without SDP, I agree it is unlikely that a snapshot 
would not require an SDP update. But I see no reason to exclude it in 
the unlikely event that a case comes up when it is valid.

This would be a problem if a snapshot request was in an UPDATE without 
SDP and the snapshot was required to be in the reply. But as long as the 
SRC can wait and send the snapshot in a request it initiates, it can 
make any offer it needs to, or potentially it could do the snapshot in 
an UPDATE without SDP if no SDP was needed.

	Thanks,
	Paul

> <partha>  We have common understanding here</partha>
>
>>
> as alternative Proposal to UPDATE without SDP snapshot request</partha>
>
> response code for this policy decision?</partha>
>
>> Of Leon Portman
> Immediate response to SRS.</partha>
>
> Then I'm fine with UPDATE based snapshot request</partha>
>
>   I am