Subject: [siprec] Comment on draft-ietf-siprec-protocol-02

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 15 Nov 2011 04:39:37 +0000

1) "may" is used instead of normative statement "MAY".
   a) Sec 4.2 Para 1 Line 2
   b) Sec 4.2 Para 3 Line 5

2) Figure 4: I guess that port 22458 "m" line is video instead of current audio.

3) Please clarify the following statement in Sec 6.1.1 "Note that when a CS
   stream is muted/unmuted, this information is conveyed in the metadata
   by the SRC. " because I don't know how metadata convey this currently.

4) Whether the normative statement required for mute? Sec 6.1.1
   "The SRC SHOULD not modify the media stream with
   a=inactive for mute since this operation is reserved for pausing the
   RS media."

5) Sec 4.2 and Sec 8.1 has duplicate information of metadata delivery which shall 
   be avoided.

6) content type shall be "application/rs-metadata+xml" instead of current 
"application/rs-metadata"

7) full metadata snapshot shall be passed across using UPDATE as well. But the current
statement on Sec 8.1 misleading "When the SRC sends a full metadata snapshot, the SRC MUST
   send an INVITE request with an SDP offer and the "recording-session"
   disposition."

8) Sec 8.2: whether rs-metadata-request body shall be changed as SIP header or clear indication 
within the message to indicate metadata request. Also, reason for logging could be mentioned explicitly like "logging: SRS internal error"

9) Sec 8.2: If logging is mandatory for SRS, Any recommendation of logging text from SRS for the generic request

Thanks
Partha

---

From: Leon Portman <[email-masked]>
Date: Tue, 15 Nov 2011 13:03:15 +0800

Partha Hi

Please see below

Regards

Leon

> 1) "may" is used instead of normative statement "MAY".
[Leon] I am not sure that we want to emphasize MAY in this specific section, it is an over part.

> 2) Figure 4: I guess that port 22458 "m" line is video instead of current audio.

[Leon] Yes, good catch. Thanks
>   by the SRC. " because I don't know how metadata convey this currently.
[Leon] Yes, it is not defined yet in metadata. We should rephrase it to "may be conveyed in metadata"
>   a=inactive for mute since this operation is reserved for pausing the
[Leon] It is related to point #3 that "mute" should not be handled like "hold"

> 5) Sec 4.2 and Sec 8.1 has duplicate information of metadata delivery which shall 

[Leon] 4.2 is the overview section. We could have some repetition here with detailed sections.
> "application/rs-metadata"
[Leon] I am ok with that
>   send an INVITE request with an SDP offer and the "recording-session"
[Leon] I remember having discussion to mandate INVITE in order to make sure that SDP will be present as well. Dont have any strong preferences here.

> within the message to indicate metadata request. Also, reason for logging could be mentioned explicitly like "logging: SRS internal error"
[Leon]  I am ok with that. Any opinions?

> 9) Sec 8.2: If logging is mandatory for SRS, Any recommendation of logging text from SRS for the generic request

[Leon] Please elaborate.
> 
> Thanks
> Partha
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 00:14:08 +0000

Leon,

Please read inline

Thanks
Partha

>-----Original Message-----
>From: Leon Portman [mailto:[email-masked]]
>Sent: Tuesday, November 15, 2011 1:03 PM
>To: Ravindran, Parthasarathi; [email-masked]
>Cc: [email-masked]
>Subject: Re: [sipprec] Comment on draft-ietf-siprec-protocol-02
>
>
>Partha Hi
>
>Please see below
>
>Regards
>
>Leon
<partha> I'm not very sure whether it is appropriate to use "may" in the specification. 
</partha>

>"may be conveyed in metadata"
<partha> Currently, it is outside the scope of metadata and IMO, it is better
to remove "mute/unmute" from protocol spec </partha>

>[Leon] It is related to point #3 that "mute" should not be handled like
<partha> IMO, there should be no normative statement related to mute </partha>

>[Leon] 4.2 is the overview section. We could have some repetition here
<partha> I can live with incase everybody wants with duplication on text
</partha>

>> 6) content type shall be "application/rs-metadata+xml" instead of
>> current "application/rs-metadata"
>>
>[Leon] I am ok with that
>> 7) full metadata snapshot shall be passed across using UPDATE as well.
>> But the current statement on Sec 8.1 misleading "When the SRC sends a
>full metadata snapshot, the SRC MUST
>[Leon] I remember having discussion to mandate INVITE in order to make
>sure that SDP will be present as well. Dont have any strong preferences
>here.
>
<partha> We had the discussion during IETF-80 to mandate INVITE & UPDATE.
But I could not find the reason for not using UPDATE for full snapshot
Request </partha>

>> 8) Sec 8.2: whether rs-metadata-request body shall be changed as SIP
>> header or clear indication within the message to indicate metadata
>request. Also, reason for logging could be mentioned explicitly like
>"logging: SRS internal error"
>>
>> 9) Sec 8.2: If logging is mandatory for SRS, Any recommendation of
>> logging text from SRS for the generic request
>
>[Leon] Please elaborate.
>>
<partha> Currently, it is plain text now whereas SRC has no means to 
understand about  the logs. Some guidelines/suggestion about the text
 helps for the implementation by which SRC understand. </partha>

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 09:25:36 +0800

Partha Thanks

Please see below

Leon

> <partha> I'm not very sure whether it is appropriate to use "may" in the specification. 

[Leon] I dont have any opinions on that
> to remove "mute/unmute" from protocol spec </partha>

[Leon] I agree, Henry, what do you think?
> But I could not find the reason for not using UPDATE for full snapshot

[Leon] I am ok with both

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 10:45:28 +0800

Additional update on sending full metadata snapshot upon SRS request.

In section 8.2 we say:

"   When the SRC receives the request for a metadata snapshot, the SRC
   MUST provide a full metadata snapshot in a separate INVITE
   transaction, along with an SDP offer."

meaning that full metadata is actually separate INVITE transaction.

Leon

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 16 Nov 2011 08:26:09 +0530

Leon,

Please see inline. I have a question here

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Wednesday, November 16, 2011 10:45 AM
> To: Parthasarathi Ravindran; [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] Comment on draft-ietf-siprec-protocol-02
> 

Why should the snapshot be always sent in a separate INVITE. Can't it be
sent as a response to snapshot request from SRS ? Is there a reason why
you want to mandate that way ?

Ram

> >>> [Leon] I am not sure that we want to emphasize MAY in this
specific
> >>> section, it is an over part.
> >>>
> >> <partha> I'm not very sure whether it is appropriate to use "may"
in
> the specification.
> >>>> 3) Please clarify the following statement in Sec 6.1.1 "Note that
> when
> >>> a CS
> >>> [Leon] Yes, it is not defined yet in metadata. We should rephrase
> it to
> >>> "may be conveyed in metadata"
> >>> [Leon] It is related to point #3 that "mute" should not be handled
> like
> >>> "hold"
> >>>
> >> <partha> IMO, there should be no normative statement related to
mute
> </partha>
> >>
> >>>> 5) Sec 4.2 and Sec 8.1 has duplicate information of metadata
> delivery
> >>> which shall
> >>>> be avoided.
> >>>
> >>> [Leon] 4.2 is the overview section. We could have some repetition
> here
> >>> with detailed sections.
> >>>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 03:00:28 +0000

Leon,

I agree with Ram.

It is possible to debate on this normative statement requirement as 
multiple way to request the full snapshot from SRS. Some of the way
from SRS are as follows:

1) REVITE without SDP and siprec-metdata-request body (3 SIP messages)
2) UPDATE with SDP and SIPREC-metadata-request body (2 SIP messages)
3) UPDATE without SDP and SIPREC-metadata-request body and
   Separate (4 SIP messages)

IIUC, current SIPREC protocol mechanism propose to use only OPTION 3
but I prefer to have the implementation choice. As mentioned above, 
OPTION 1 & 2 has less SIP message required to achieve the same compare
to OPTION 3. Hope this clarifies.

Thanks
Partha

>From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
>Sent: Wednesday, November 16, 2011 10:56 AM
>To: Leon Portman; Ravindran, Parthasarathi; [email-masked]
>Cc: [email-masked]
>Subject: RE: [siprec] Comment on draft-ietf-siprec-protocol-02
>
>Leon,
>
>> >>>> "The SRC SHOULD not modify the media stream with a=inactive for
>> >>>> mute since this operation is reserved for pausing
>> the
>> >>>> RS media."
>> >>>>

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 11:13:10 +0800

Yes, please refer to:

http://www.ietf.org/mail-archive/web/siprec/current/msg02436.html

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 11:16:18 +0800

Patha

Please see below

Leon

> 1) REVITE without SDP and siprec-metdata-request body (3 SIP messages)
In this case, is it legal for SRC to answer SDP less INVITE with SDP? Snapshot requires SDP
> 2) UPDATE with SDP and SIPREC-metadata-request body (2 SIP messages)
What if SRS does not have SDP?

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 16 Nov 2011 08:51:40 +0530

Hi Leon,

A comment on this point

> <partha> Currently, it is outside the scope of metadata and IMO, it is

> better to remove "mute/unmute" from protocol spec </partha>

IMO mute/unmute is a property of a device and it is better not to map it
to signaling. SRS could use alternate mechanisms to detect no media. I
would prefer it keep it outside the scope of SIPREC.
An SRC that has the capability to do this may send the information as an
extension data.

Ram

> Sent: Wednesday, November 16, 2011 9:26 AM
it
> to
> >>> But the current statement on Sec 8.1 misleading "When the SRC
sends
> a

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 03:28:09 +0000

Leon, 

Please read inline.

Thanks
Partha

>Sent: Wednesday, November 16, 2011 11:16 AM
>To: Ravindran, Parthasarathi
>Cc: Ram Mohan R (rmohanr); [email-masked]; [email-masked]
<partha> AFAIK, Re-INVITE without SDP is used to get offer from the remote
Side. Even Hadriel mail threads says the same. Could you please point out 
RFC 3261 Section to point how RE-INVITE without offer/answer work? </partha>

>What if SRS does not have SDP?
<partha> In that case, it will end-up in OPTION 1 or 3 but please note that
It is possible to SRS to send SDP in case it has the idea of what has to be
Recorded. </partha>

>>   Separate (4 SIP messages)

<partha> I have started thinking whether it is appropriate for UPDATE from SRC
to ask SRC to trigger new Re-INVITE/UPDATE towards SRS. ISTM, the proposal mandates
action in SRC to be invoke Re-INVITE/UPDATE using UPDATE whereas UPDATE is not
designed for that. I may be wrong here but we need careful analysis here </partha>

>>> Why should the snapshot be always sent in a separate INVITE. Can't it
>>> be sent as a response to snapshot request from SRS ? Is there a
>>> reason why you want to mandate that way ?
>>>
>>> Ram
>>>
>>>>
>>>> Leon
>>>>
>>>>
>>>>>>>> 2) Figure 4: I guess that port 22458 "m" line is video instead
>>>>>>>> of
>>>>>>> current audio.
>>>>>>>
>>>>>> <partha> Currently, it is outside the scope of metadata and IMO,
>>>>>> it
>>>> is better
>>>>>> <partha> I can live with incase everybody wants with duplication
>>>>>> on
>>>> text
>>>>>> </partha>
>>>>>>
>>>>>>>> 6) content type shall be "application/rs-metadata+xml" instead
>>>>>>>> of current "application/rs-metadata"
>>>>>>>>
>>>>>>> [Leon] I am ok with that
>>>> sends a

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 13:34:10 +0800

If offer-less REINVITE works (it seems to be) i dont have problem with supporting option 1 as well. Any SIP experts opinions?

Leon

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 13:40:58 +0800

Most important from SRS point of view, is to define a mechanism for snapshot request that will not terminate recording session even for shortest possible time.

My concern is if new INVITE will do that.

Leon

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 13:42:51 +0800

My concern is if new INVITE will do that

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Nov 2011 07:24:55 +0100

Hi,

If I understand this correctly the discussion is how should the SRS initiate a snapshot from the SRC and how does this impact the offer/answer.

The snapshot has I believe to include both an SDP offer and the associated XML representing the metadata. The only way to initiate a new SDP offer within the dialog is for the SRS to send a reINVITE without SDP to the SRC causes the SRC to respond with the SDP Offer and associated metadata snapshot in the 200OK which will of course cause the SRS to generate an SDP answer in the ACK.

The SRS could also include an SDP offer in the reINVITE and have the SRC create the answer.

In either case it should be that there is no change in the SDP from the previous offer/answer and therefore it is effectively a session refresh and does not cause an media interruption. 

Regards
Andy

> Sent: 16 November 2011 13:43
> Cc: [email-masked]; [email-masked]
> Most important from SRS point of view, is to define a mechanism for
> snapshot request that will not terminate recording session even for
> shortest possible time.
> 
> > If offer-less REINVITE works (it seems to be) i dont have problem
> with supporting option 1 as well. Any SIP experts opinions?
> >
> > Leon
> >
> >>> In this case, is it legal for SRC to answer SDP less INVITE with
> SDP?
> >>> Snapshot requires SDP
> >>>>>> "   When the SRC receives the request for a metadata snapshot,
> the
> >>> SRC
> >>>>>>>>>> 7) full metadata snapshot shall be passed across using
> UPDATE as
> >>>>>> well.
> >>>>>>>>> [Leon] I remember having discussion to mandate INVITE in
> order to
> >>>>>> make
> >>>>>>>> <partha> We had the discussion during IETF-80 to mandate
> INVITE &
> >>>>>> UPDATE.
> >>>>>>>>>> 8) Sec 8.2: whether rs-metadata-request body shall be
> changed as
> >>>>>> SIP
> >>>>>>>>> request. Also, reason for logging could be mentioned
> explicitly
> >>>>>> like
> >>>>>>>>>> 9) Sec 8.2: If logging is mandatory for SRS, Any
> recommendation
> >>>>> of
> >>>>>>>> <partha> Currently, it is plain text now whereas SRC has no
> means
> >>>>> to
> >>>>>>>> understand about  the logs. Some guidelines/suggestion about
> the
> >>>>>> text

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 14:47:43 +0800

If we will use OK response from SRC to SRS for reporting metadata snapshot and SRS will want to update SDP - for example because it needs to terminate or redirect one of the RS media streams, it will need to do it in separate REINVITE and UPDATE after ACK?

Leon

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 07:30:24 +0000

Leon,

Please read inline.

Thanks
Partha

>Sent: Wednesday, November 16, 2011 2:48 PM
>To: Hutton, Andrew
>Cc: Ravindran, Parthasarathi; [email-masked]; [email-masked]
>If we will use OK response from SRC to SRS for reporting metadata
>snapshot 

<partha> We are in the same page till here </partha>

and SRS will want to update SDP - for example because it needs
>to terminate or redirect one of the RS media streams, it will need to do
>it in separate REINVITE and UPDATE after ACK?

<partha> IIUC, SRS will trigger one another offer/answer to terminate RS
Media stream. But I'm not very clear about the redirect of RS media stream
Scenario </partha>

>> If I understand this correctly the discussion is how should the SRS
>initiate a snapshot from the SRC and how does this impact the
>offer/answer.
>>
>> The snapshot has I believe to include both an SDP offer and the
>associated XML representing the metadata. The only way to initiate a new
>SDP offer within the dialog is for the SRS to send a reINVITE without
>SDP to the SRC causes the SRC to respond with the SDP Offer and
>associated metadata snapshot in the 200OK which will of course cause the
>SRS to generate an SDP answer in the ACK.
>>
>> In either case it should be that there is no change in the SDP from
>the previous offer/answer and therefore it is effectively a session
>refresh and does not cause an media interruption.
>>
>> Regards
>> Andy
>>
>>
>>
>>>>>>> IIUC, current SIPREC protocol mechanism propose to use only
>>>>>>> OPTION
>>> 3
>>>>>>>>>>>> Subject: Re: [sipprec] Comment on
>>>>>>>>>>>> draft-ietf-siprec-protocol-
>>> 02
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Partha Hi
>>>>>>>>>>>>
>>>>>>>>>>>> Please see below
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> Leon
>>>>>>>>>>>>> stream is muted/unmuted, this information is conveyed in
>>>>>>>>>>>>> the
>>>>>>>>>>>> metadata
>>>>>>>>>>>>> send an INVITE request with an SDP offer and the
>>>>>>>>>>>>> "recording-
>>>>>>>>> session"
>>>>>>>>>>>>> disposition."
>>>>>>>>>>>>>

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 15:35:33 +0800

Partha

It seems to be that we are converging into solution where SRS will send offer-less INVITE with snapshot request and SRC will response with OK including metadata snapshot XML and SDP and SRS will ACK this SDP. If any media updates are required from SRS , they will be carried in separate INVITE/UPDATE as you have mention below. So we are converging into your option 1 solution.

Please note that it complicates little bit SRC implementation.

Any concerns and comments?

Thank you for raising this issue.

Leon

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 15:48:58 +0800

> you want to mandate that way ?

I guess *a* reason is that the snapshot will need to contain SDP. And 
since it might be changed SDP, it needs to be an offer so that it can be 
answered.

It would still be possible to do this in response to an INVITE, as long 
as the INVITE has no offer.

	Thanks,
	Paul

>>>> to remove "mute/unmute" from protocol spec</partha>
>>>
>>>> <partha>  We had the discussion during IETF-80 to mandate INVITE&
>> UPDATE.
>>>> Request</partha>
>>>> helps for the implementation by which SRC understand.</partha>
>>>>>> Thanks
>>>>>> Partha

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 07:56:34 +0000

Leon,

I'm fine with OPTION 1. Let us discuss in SIPREC meeting on tomorrow to close this open item if possible.

Thanks
Partha

>Sent: Wednesday, November 16, 2011 3:36 PM
>Cc: Andrew Hutton; [email-masked]
>It seems to be that we are converging into solution where SRS will send
>offer-less INVITE with snapshot request and SRC will response with OK
>including metadata snapshot XML and SDP and SRS will ACK this SDP. If
>any media updates are required from SRS , they will be carried in
>separate INVITE/UPDATE as you have mention below. So we are converging
>into your option 1 solution.
>
>>> to terminate or redirect one of the RS media streams, it will need to
>>> do it in separate REINVITE and UPDATE after ACK?
>>
>> <partha> IIUC, SRS will trigger one another offer/answer to terminate
>> RS Media stream. But I'm not very clear about the redirect of RS media
>> stream Scenario </partha>
>>
>>>
>>> Leon
>>>
>>> associated XML representing the metadata. The only way to initiate a
>>> new SDP offer within the dialog is for the SRS to send a reINVITE
>>> without SDP to the SRC causes the SRC to respond with the SDP Offer
>>> and associated metadata snapshot in the 200OK which will of course
>>> cause the SRS to generate an SDP answer in the ACK.
>>>>
>>>>>>>>> It is possible to debate on this normative statement
>>>>>>>>> requirement
>>>>> as
>>>>>>> <partha> AFAIK, Re-INVITE without SDP is used to get offer from
>>>>>>> the
>>>>> remote
>>>>>>> RFC 3261 Section to point how RE-INVITE without offer/answer
>work?
>>>>> </partha>
>>>>>>>
>>>>>>>
>>>>>>> designed for that. I may be wrong here but we need careful
>>>>>>> analysis
>>>>> here </partha>
>>>>>>>
>>>>>>>>>>> From: [email-masked]
>>>>>>>>>>> [mailto:[email-masked]]
>>>>> On
>>>>>>>>>>> Behalf Of Leon Portman
>>>>>>>>>> be sent as a response to snapshot request from SRS ? Is there
>>>>>>>>>> a reason why you want to mandate that way ?
>>>>>>>>>>
>>>>>>>>>> Ram
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Leon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> by the SRC. " because I don't know how metadata convey
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> currently.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a=inactive
>>>>> for
>>>>>>>>>>>>> <partha> IMO, there should be no normative statement
>>>>>>>>>>>>> related
>>>>> to
>>>>>>>>>> mute
>>>>>>>>>>> </partha>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> sure that SDP will be present as well. Dont have any
>>>>>>>>>>>>>> strong
>>>>>>>>>>> preferences
>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> But I could not find the reason for not using UPDATE for
>>>>>>>>>>>>> full
>>>>>>>>>>> snapshot
>>>>>>>>>>>>> Request </partha>
>>>>>>>>>>>>
>>>>>>>>>>>> [Leon] I am ok with both
>>>>>>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 16:06:55 +0800

The reply I just sent was written earlier and just now sent, before I 
caught up on reading and found the subject already much evolved.

> Please note that it complicates little bit SRC implementation.

Another consideration is that it might take time to prepare the shapshot 
for sending, and it is desired not to delay response to the request. 
That is another reason to decouple sending the snapshot from the 
response to the snapshot request.

IMO the SRC should at least have the *option* to defer sending the snapshot.

I'm ok with *allowing* the SRC to send the shapshot with the response if 
it is capable of doing so.

	Thanks,
	Paul

>> <partha>  We are in the same page till here</partha>
>>
>> Scenario</partha>
>>>>>>> Recorded.</partha>
>>>>>>> designed for that. I may be wrong here but we need careful analysis
>>>>> here</partha>
>>>>>>>
>>>>>>>>> OPTION 1&  2 has less SIP message required to achieve the same
>>>>> compare
>>>>> INVITE&

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 08:16:57 +0000

Paul,

IIUC, SRC has to send its current snapshot. I could not understand 
the reason to defer at this stage. Of course, 100 response shall be sent for
RE-INVITE of metadata snapshot request by which will help to defer even if 
required.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Paul Kyzivat
>Sent: Wednesday, November 16, 2011 4:07 PM
>To: [email-masked]
>> It seems to be that we are converging into solution where SRS will
>send offer-less INVITE with snapshot request and SRC will response with
>OK including metadata snapshot XML and SDP and SRS will ACK this SDP. If
>>>> to terminate or redirect one of the RS media streams, it will need
>>>> to do it in separate REINVITE and UPDATE after ACK?
>>>
>>> <partha>  IIUC, SRS will trigger one another offer/answer to
>>> terminate RS Media stream. But I'm not very clear about the redirect
>>> of RS media stream Scenario</partha>
>>>
>>>>
>>>> Leon
>>>>
>>>>> The SRS could also include an SDP offer in the reINVITE and have
>>>>> the
>>>> SRC create the answer.
>>>>>
>>>>>> Most important from SRS point of view, is to define a mechanism
>>>>>> for snapshot request that will not terminate recording session
>>>>>> even for shortest possible time.
>>>>>>
>>>>>>>>>> multiple way to request the full snapshot from SRS. Some of
>>>>>>>>>> the
>>>>>> way
>>>>>>>>>> from SRS are as follows:
>>>>>>>>>>
>>>>>>>> <partha>  In that case, it will end-up in OPTION 1 or 3 but
>>>>>>>> please
>>>>>> note that
>>>>>>>> It is possible to SRS to send SDP in case it has the idea of
>>>>>>>> what
>>>>>> has to be
>>>>>>>> Recorded.</partha>
>>>>>>>>
>>>>>>>>
>>>>>>>> to ask SRC to trigger new Re-INVITE/UPDATE towards SRS. ISTM,
>>>>>>>> the
>>>>>> proposal mandates
>>>>>>>>>>>>>> <partha>  I'm not very sure whether it is appropriate to
>>>>>>>>>>>>>> use
>>>>>> "may"
>>>>>>>>>>> in
>>>>>>>>>>>> the specification.
>>>>>>>>>>>>>> </partha>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <partha>  Currently, it is outside the scope of metadata
>>>>>>>>>>>>>> and
>>>>>> IMO,
>>>>>>>>>>>>>> it
>>>>>>>>>>>> is better
>>>>>>>>>>>>>>>> 4) Whether the normative statement required for mute?
>>>>>>>>>>>>>>>> Sec
>>>>>> 6.1.1
>>>>>>>>>>>>>>>> But the current statement on Sec 8.1 misleading "When
>>>>>>>>>>>>>>>> the
>>>>>> SRC
>>>>>>>>>>>> sends a
>>>>>>>>>>>>>>>> header or clear indication within the message to
>>>>>>>>>>>>>>>> indicate
>>>>>>>>>>> metadata

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 16:41:57 +0800

> In either case it should be that there is no change in the SDP from the previous offer/answer and therefore it is effectively a session refresh and does not cause an media interruption.

IMO you can't assume that.
Its possible that there have been changes that have not yet been 
reported. Would you require that it send the snapshot of only the old 
stuff, not the changes?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 16:46:10 +0800

> RE-INVITE of metadata snapshot request by which will help to defer even if

I think we had this discussion once before.
The application that formats the metadata is a different layer from the 
stack, and may be decoupled from it. We shouldn't assume anything about 
the latency between them.

Is there a *problem* with leaving this as an option for the SRC?
Is it going to matter to the SRS that it must wait for the snapshot?

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Wed, 16 Nov 2011 21:07:20 +0800

Very good point, i have completely forgot about it. From SRS point of view, we can support both modes of operation: immediate response or another re-invite

Leon

On Nov 16, 2011, at 4:46 PM, Paul Kyzivat wrote:

> The application that formats the metadata is a different layer from the stack, and may be decoupled from it. We shouldn't assume anything about the latency between them.
>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 16 Nov 2011 14:07:17 +0000

Paul/Leon,
 
We have discussed about decoupling of "metadata" & "SDP" for SRS but
here it is SRC. Even in case of SRS, we agreed upon that there is no 
need to defer the responses for metadata processing and RE-INVITE/UPDATE
is agreed upon based on this assumption. Snapshot request may be used as 
deferred mechanism to correct metadata.

SRC implementation shall maintain "metadata" & "SDP" in different layer 
but the latency problem is solved by sending "100 trying" for RE-INVITE 
in SRC. The problem with two different transaction (request/response) is that
the possibility of a offer/answer race condition is higher. Apart from 
latency, Could you please specify any advantage in two transaction approach.
Also, two transactions makes me to feel like invoking action in SRC as the
Second transaction is triggered based on the first UPDATE/RE-INVITE with
Snapshot request.

Let us get others opinion for the need of two separate transaction 
(request/response) in SRC.

Thanks
Partha

>Sent: Wednesday, November 16, 2011 9:07 PM
>To: Paul Kyzivat
>Cc: Ravindran, Parthasarathi; [email-masked]
>Very good point, i have completely forgot about it. From SRS point of
>view, we can support both modes of operation: immediate response or
>another re-invite
>
>Leon
>
>>> the reason to defer at this stage. Of course, 100 response shall be
>>> sent for RE-INVITE of metadata snapshot request by which will help to
>>> defer even if required.
>>
>> The application that formats the metadata is a different layer from
>the stack, and may be decoupled from it. We shouldn't assume anything
>about the latency between them.
>>
>>>> Behalf Of Paul Kyzivat
>>>> The reply I just sent was written earlier and just now sent, before
>>>> I caught up on reading and found the subject already much evolved.
>>>>
>>>> send offer-less INVITE with snapshot request and SRC will response
>>>> with OK including metadata snapshot XML and SDP and SRS will ACK
>>>> this SDP. If any media updates are required from SRS , they will be
>>>> carried in separate INVITE/UPDATE as you have mention below. So we
>>>> are converging into your option 1 solution.
>>>>>
>>>> Another consideration is that it might take time to prepare the
>>>> shapshot for sending, and it is desired not to delay response to the
>request.
>>>> I'm ok with *allowing* the SRC to send the shapshot with the
>>>> response if it is capable of doing so.
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>>>>> to terminate or redirect one of the RS media streams, it will
>>>>>>> need to do it in separate REINVITE and UPDATE after ACK?
>>>>>>
>>>>>> terminate RS Media stream. But I'm not very clear about the
>>>>>> redirect of RS media stream Scenario</partha>
>>>>>>
>>>>>>>
>>>>>>> Leon
>>>>>>>
>>>>>>> associated XML representing the metadata. The only way to
>>>>>>> initiate a new SDP offer within the dialog is for the SRS to send
>>>>>>> a reINVITE without SDP to the SRC causes the SRC to respond with
>>>>>>> the SDP Offer and associated metadata snapshot in the 200OK which
>>>>>>> will of course cause the SRS to generate an SDP answer in the
>ACK.
>>>>>>>>
>>>>>>> the previous offer/answer and therefore it is effectively a
>>>>>>> session refresh and does not cause an media interruption.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Andy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>>>>> On Behalf Of Leon Portman
>>>>>>>>>>>>> 1) REVITE without SDP and siprec-metdata-request body (3
>>>>>>>>>>>>> SIP
>>>>>>>>> messages)
>>>>>>>>>>> Side. Even Hadriel mail threads says the same. Could you
>>>>>>>>>>> please
>>>>>>>>> point out
>>>>>>>>>>> <partha>   I have started thinking whether it is appropriate
>for
>>>>>>>>> UPDATE from SRC
>>>>>>>>>>> action in SRC to be invoke Re-INVITE/UPDATE using UPDATE
>>>>>>>>>>> whereas
>>>>>>>>> UPDATE is not
>>>>>>>>>>>>> but I prefer to have the implementation choice. As
>>>>>>>>>>>>> mentioned
>>>>>>>>> above,
>>>>>>>>>>>>>>> Additional update on sending full metadata snapshot upon
>>>>>>>>>>>>>>> SRS
>>>>>>>>>>>> request.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In section 8.2 we say:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> MUST provide a full metadata snapshot in a separate
>>>>>>>>>>>>>>> INVITE transaction, along with an SDP offer."
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why should the snapshot be always sent in a separate
>INVITE.
>>>>>>>>> Can't it
>>>>>>>>>>>>>> be sent as a response to snapshot request from SRS ? Is
>>>>>>>>>>>>>> there a reason why you want to mandate that way ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ram
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Leon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2) Figure 4: I guess that port 22458 "m" line is
>>>>>>>>>>>>>>>>>>> video
>>>>>>>>> instead
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> current audio.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> stream is muted/unmuted, this information is conveyed
>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>> metadata
>>>>>>>>>>>>>>>>>>> by the SRC. " because I don't know how metadata
>>>>>>>>>>>>>>>>>>> convey this
>>>>>>>>>>>>>>>>>> currently.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [Leon] Yes, it is not defined yet in metadata. We
>>>>>>>>>>>>>>>>>> should
>>>>>>>>> rephrase
>>>>>>>>>>>>>>> it to
>>>>>>>>>>>>>>>>>>> 6) content type shall be "application/rs-
>metadata+xml"
>>>>>>>>> instead
>>>>>>>>>>>>>>>>> But I could not find the reason for not using UPDATE
>>>>>>>>>>>>>>>>> for full
>>>>>>>>>>>>>>> snapshot
>>>>>>>>>>>>>>>>> Request</partha>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [Leon] I am ok with both
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <partha>   Currently, it is plain text now whereas SRC
>has
>>>>>>>>>>>>>>>>> no
>>>>>>>>> means
>>>>>>>>>>>>>> to

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Nov 2011 15:08:47 +0100

See below.

> Sent: 16 November 2011 16:42
> To: [email-masked]
> without SDP to the SRC causes the SRC to respond with the SDP Offer and
> associated metadata snapshot in the 200OK which will of course cause
> the SRS to generate an SDP answer in the ACK.
> >

[AndyH] - You are right I was thinking of the case of a snapshot when there has been no change since the last offer/answer. I think it is a corner case but I agree that there could be changes to report in the new offer.

> >>>>>>>>>>> Subject: Re: [sipprec] Comment on draft-ietf-siprec-
> protocol-
> >> 02
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Partha Hi
> >>>>>>>>>>>
> >>>>>>>>>>> Please see below
> >>>>>>>>>>>
> >>>>>>>>>>> Regards
> >>>>>>>>>>>
> >>>>>>>>>>> Leon
> >>>>>>>>>>>> 3) Please clarify the following statement in Sec 6.1.1
> "Note
> >>>>>>>>>>>> that
> >>>>>>>> when
> >>>>>>>>>>> a CS

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 16 Nov 2011 09:10:47 -0800

I agree that the meaning of mute/unmute of CS streams has a lot to do
with the implementation of the endpoint itself. We can keep it outside
of the protocol but I think we should still mention it in the spec so
that we don't confuse the meaning of a=inactive in the recording session
as the same thing as muting in CS stream.

Old text:
   The SRC can temporarily discontinue streaming and collection of
   recorded media from the SRC to the SRS for reason such as masking the
   recording.  In this case, the SRC sends a new SDP offer and sets the
   media stream to inactive (a=inactive) for each recorded stream to be
   paused, as per the procedures in [RFC3264].  To resume streaming and
   collection of recorded media, the SRC sends a new SDP offer and sets
   the media streams with a=sendonly attribute.  Note that when a CS
   stream is muted/unmuted, this information is conveyed in the metadata
   by the SRC.  The SRC SHOULD not modify the media stream with
   a=inactive for mute since this operation is reserved for pausing the
   RS media.

Proposed changes:

   The SRC can temporarily discontinue streaming and collection of
   recorded media from the SRC to the SRS for reason such as masking the
   recording.  Masking the recording is different than a CS participant
muting its media stream; the decision to mask a recording is a matter of
local policy at the SRC. For example, the SRC may mask the recording
when a participant in the CS is collecting sensitive information.
   To temporarily discontinue recording, the SRC sends a new SDP offer
and sets the
   media stream to inactive (a=inactive) for each recorded stream to be
   paused, as per the procedures in [RFC3264].  To resume streaming and
   collection of recorded media, the SRC sends a new SDP offer and sets
   the media streams with a=sendonly attribute.  

Regards,
Henry

> Sent: November-15-11 10:22 PM
> To: Leon Portman; Parthasarathi Ravindran; Henry Lum
> Cc: [email-masked]
it
> >> to "may be conveyed in metadata"
of
it
> > >>>  a=inactive for mute since this operation is reserved for
pausing
on
of
> > > helps for the implementation by which SRC understand. </partha>

-------------------------------------------------------------------------------------------------------------------
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, 17 Nov 2011 04:32:44 +0800

On 11/16/11 10:07 PM, Ravindran, Parthasarathi wrote:
> Paul/Leon,
>
> We have discussed about decoupling of "metadata"&  "SDP" for SRS but

I think that is consistent with what I recall. The point was that the 
SRS need not process the metadata before replying.

> SRC implementation shall maintain "metadata"&  "SDP" in different layer
> in SRC.

Yes, you *can* extend the reinvite transaction by sending provisionals. 
But it still gets ugly then in terms of interaction between layers.

> The problem with two different transaction (request/response) is that
> the possibility of a offer/answer race condition is higher.

Why is that? What sort of race condition? Its of course always possible 
for reinvite to be launched simultaneously by both src and srs, 
resulting in o/a glare. But that is independent of this question. (But 
it does remind me that we probably ought to discuss somewhere the 
implications of a glare case on metadata processing, though in some 
sense it is obvious.)

Are you assuming the snapshot request always comes in an offerless-reinvite?

If it comes in a reinvite with an offer, and the snapshot is required in 
the answer, then the shapshot is required to be consistent with the SDP 
in the offer. That could be a problem. I suppose we could draw up a 
bunch of constraints to prevent that, but its extra work, so why bother? 
If we don't require the snapshot in the response, then we avoid that - 
the src can wait until it can send reinvite with suitable offer.

If snapshot request comes in a reinvite without offer, then there are no 
signaling difficulties with returning the snapshot in the response with 
the offer. And I am fine with *allowing* that, but not requiring it.

If the snapshot request comes in a reinvite without offer, and the 
response does NOT contain the shapshot, then probably it contains an 
offer same as last time, and the answer can as well. At that point, what 
sort of race are you concerned about? It seems the only one would be if 
the SRS send *another* reinvite before the snapshot is received. But I 
see no new problem with that.

The complexities I see are:

- SRS sends reinvite with offer that is different from last agreed,
   regardless of whether this contains a snapshot request or not.

- SRS sends reinvite without offer, the offer in the response
   differs from what was last agreed, and does not contain metadata.

- SRC sends reinvite with offer different from last agreed,
   and without metadata.

- SRC sends reinvite without offer, with or without metadata.

We might want to lay down some rules, such as that the snapshot request 
must never contain an offer, or must always contain an offer identical 
to what was last agreed. But even that may take some consideration - 
some SBCs might take an offerless invite and fill in an offer. :-(

> Apart from

Potentially easier implementation for the SRC.

> Second transaction is triggered based on the first UPDATE/RE-INVITE with

Yes. What is wrong with that?
We do such things all the time. (E.g. SUBSCRIBE triggers NOTIFY.)

> (request/response) in SRC.

I'm arguing to allow flexibility on the part of the SRC.
If you are building an SRC, and you want to implement it to always 
return the snapshot in the response, then you can build it that way.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 17 Nov 2011 07:04:13 +0530

Please see inline

> From: Henry Lum [mailto:[email-masked]]
> Sent: Thursday, November 17, 2011 1:11 AM
> To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi Ravindran
> Cc: [email-masked]

 This is fine as long as we don't mandate an SRC to do this. IMO we can
leave it as a policy and if a SRC is compliant with the policy(due to
regulations in some places) it may support the above behavior.

Thanks,
Ram

it
> > is
> > IMO mute/unmute is a property of a device and it is better not to
map
> > An SRC that has the capability to do this may send the information
as
> > an
> > > >>> 7) full metadata snapshot shall be passed across using UPDATE
> as
> > > well.
> > > >> [Leon] I remember having discussion to mandate INVITE in order
> to
> > > make
> > > >>> 8) Sec 8.2: whether rs-metadata-request body shall be changed
> as
> > > SIP
recommendation
means
> > > > helps for the implementation by which SRC understand. </partha>
-----------------------------------------------------------------------
> --------------------------------------------
> 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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 17 Nov 2011 08:11:44 +0530

My thoughts on this topic of asynchronous processing/sending of
metadata:

I am in favor of having a flexibility on the part of both SRC and SRS.
So that we allow implementations where SRS can respond without
processing snapshot and SRC can respond first(for a snapshot request)
without metadata and can send metadata later.

Regards,
Ram

> Sent: Thursday, November 17, 2011 4:33 AM
> > is agreed upon based on this assumption. Snapshot request may be
used

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 17 Nov 2011 06:24:41 +0000

Paul,

Please read inline.

Thanks
Partha

>From: Paul Kyzivat [mailto:[email-masked]]
>Cc: Leon Portman; [email-masked]
>> need to defer the responses for metadata processing and
>> RE-INVITE/UPDATE is agreed upon based on this assumption. Snapshot
>> request may be used as deferred mechanism to correct metadata.
>
>> SRC implementation shall maintain "metadata"&  "SDP" in different
>> layer but the latency problem is solved by sending "100 trying" for
>> RE-INVITE in SRC.
>
<partha> I doubt because SRC is a real-time and the query is about its call
Control state. </partha>

>resulting in o/a glare. But that is independent of this question.

<partha> ISTM, we are defining the protocol which may often end-up in
Glare which shall be avoided </partha>

 (But
>implications of a glare case on metadata processing, though in some
<partha> It will be good to discuss and define in the protocol document 
</partha>

>Are you assuming the snapshot request always comes in an offerless-
<partha> No </partha>

>in the offer. That could be a problem. 

<partha> It should not be a problem because SRS knows what it wants at this
Stage and there is no provide extra information if SRS is not interested. 
In case SRS asks for audio only, SRC shall send audio as a negotiation
Even though earlier it was negotiated for audio+video negotiation</partha>

I suppose we could draw up a
>the offer. And I am fine with *allowing* that, but not requiring it.
<partha> Hope we have agreement here </partha>

>the SRS send *another* reinvite before the snapshot is received. 
	
<partha> IMO, it is problem introduced due to this design of capability
Request in one transaction and capability response in another transaction. 
</partha>

But I
 
>   regardless of whether this contains a snapshot request or not.
</partha> It is fine and SRS has the way to change 
</partha>
>- SRC sends reinvite with offer different from last agreed,
<partha> Here, atleast there is a need to indication from SRC that 
Metadata will be sent later. Something like 202 OK response or some
Message body indication </partha>

>to what was last agreed.

<partha> I agreed that it is bad and it is not required as well </partha>

 But even that may take some consideration -
>some SBCs might take an offerless invite and fill in an offer. :-(
<partha> It is a messy SBC feature ;-) </partha>

>> Also, two transactions makes me to feel like invoking action in SRC as
>> the Second transaction is triggered based on the first
>> UPDATE/RE-INVITE with Snapshot request.
>
</partha> Howz the relationship between these two transaction are set. 
</partha>

>We do such things all the time. (E.g. SUBSCRIBE triggers NOTIFY.)
<partha> SUB/NOT framework clearly specify how NOTIFY shall 
be created using the new transaction for SUBSCRIBE whereas in SIPREC, 
we need to do using REINVITE/UPDATE for separate transaction. I'm fine
in case we are defining such framework and it is not clear in the 
current specification. </partha>