Subject: [siprec] Feedback from NENA ICE-8 Event

From: "Simon Farrow" <[email-masked]>
Date: Tue, 3 Dec 2013 10:32:13 -0800

Typically we found SRC where 'forking' the media to the SRS. A call was
setup between a UA and the SRC which was followed by the SRC sending an
INVITE/OK/ACK to the SRS and the media was 'forked' to the SRS.

This worked except for video as a traditional cause of interoperability
problems with video is that parties in a call use different approaches for
video fast update requests. What we witnessed was the SRC may not send the
SRS the original I-Frame as the call was still being setup between the SRC
and SRS but already in progress between the SRC and UA. This was a real
problem if SRC only then sent P-Frames to the SRS. 

In the i3 document the following text was added to help address the issue
but to me this does help the SIPREC specification
"User Agents in the ESInet must support both RFC5104 [160] and RFC5168 [161]
for full frame refresh requests.  The RFC5104 RTCP method is preferred with
fall back to RFC5168 INFO method when the sender does not implement RFC5104"

A couple of thoughts came to mind regarding this issue.

1: Should we state the SRC have a media buffer - I do not think it would be
a problem if sent it as quickly as possible once the session is established
between the SRC and SRS.
2: Should the SRC forward on a RFC5104 RTCP or RFC5168 INFO message sent by
an SRS.

Simon Farrow
Director of Engineering

Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704

Tel: 1-714-546-2002 ext 4311
http://www.stancilcorp.com
[email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Dec 2013 14:21:02 -0500

Do we have anything specific about full frame refresh in -protocol?  Don’t remember it.  We probably want the text Simon cites from NENA 08-003, with some text that says if the frame refresh request mechanism on the CS is different from that on the RS then the SRC has to interwork them.

We then probably could use an implementation note that states that the SRC must buffer video such that if the RS is established after the CS, the RS must start with a full I-Frame.

Brian

On Dec 3, 2013, at 1:32 PM, Simon Farrow <[email-masked]> wrote:

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

---

From: Henry Lum <[email-masked]>
Date: Tue, 3 Dec 2013 19:42:17 +0000

The protocol spec mentions the use of FIR for generating a full I-frame in section 8.1.7, but I think it should be an implementation issue to have an SRC to buffer media to start with a full I-frame in an RS since an SRC is not always an RTP endpoint. Also some endpoints don't generate I-frames very often; if a CS is not recorded in the beginning of the call but recorded later during the call, then it's hard to mandate an SRC to buffer media without a recording so that it can generate an I-Frame in the middle of the call.

Henry

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: December-03-13 2:21 PM
To: Simon Farrow
Cc: [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

Do we have anything specific about full frame refresh in -protocol?  Don't remember it.  We probably want the text Simon cites from NENA 08-003, with some text that says if the frame refresh request mechanism on the CS is different from that on the RS then the SRC has to interwork them.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Dec 2013 14:51:05 -0500

You MUST start the RS with an I-frame unless you know that every block will be refreshed soon.  Since the SRS can’t manage the timing of the RS vs the CS, it has to be up the the SRC to fix it.
We can talk about how much clipping is acceptable, but the SRC has to arrange an I-Frame as the first thing in the RS.

I’d do this by asking for an i-frame as soon as I started establishing the RS, and have enough buffering to cover receipt of the I-Frame to the RS media flowing.

What would be really hard to handle is a CS that didn’t implement FIR.

Brian

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 4 Dec 2013 06:46:20 +0000

Another way would be to have a persistent RS between SRC and SRS and
record the CS from the beginning. But again Persistent RS is not feasible
in all cases.
I think the best we have today is to have SRC request for I-Frame via FIR
request as soon as RS is setup/being setup. This would still create a
small clip.

Perhaps we need to have some text on what is a acceptable clip.

Regards,
Ram

-----Original Message-----
From: Brian Rosen <[email-masked]>
Date: Wednesday, 4 December 2013 1:21 AM
To: Henry Lum <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

>You MUST start the RS with an I-frame unless you know that every block
>will be refreshed soon.  Since the SRS can¹t manage the timing of the RS
>vs the CS, it has to be up the the SRC to fix it.
>We can talk about how much clipping is acceptable, but the SRC has to
>arrange an I-Frame as the first thing in the RS.
>
>I¹d do this by asking for an i-frame as soon as I started establishing
>the RS, and have enough buffering to cover receipt of the I-Frame to the
>RS media flowing.
>
>What would be really hard to handle is a CS that didn¹t implement FIR.
>
>Brian
>> The protocol spec mentions the use of FIR for generating a full I-frame
>>in section 8.1.7, but I think it should be an implementation issue to
>>have an SRC to buffer media to start with a full I-frame in an RS since
>>an SRC is not always an RTP endpoint. Also some endpoints don't generate
>>I-frames very often; if a CS is not recorded in the beginning of the
>>call but recorded later during the call, then it's hard to mandate an
>>SRC to buffer media without a recording so that it can generate an
>>I-Frame in the middle of the call.
>> 
>> Henry
>> 
>> Do we have anything specific about full frame refresh in -protocol?
>>Don't remember it.  We probably want the text Simon cites from NENA
>>08-003, with some text that says if the frame refresh request mechanism
>>on the CS is different from that on the RS then the SRC has to interwork
>>them.
>> 
>> We then probably could use an implementation note that states that the
>>SRC must buffer video such that if the RS is established after the CS,
>>the RS must start with a full I-Frame.
>> 
>> Brian
>>

---

From: "Dave Higton" <[email-masked]>
Date: Wed, 4 Dec 2013 08:36:57 +0000

What you're saying is that a video call MUST have video recorded right from the start, otherwise it isn't going to work.

Dave

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: 03 December 2013 19:42
To: Brian Rosen; Simon Farrow
Cc: [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

Henry

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: December-03-13 2:21 PM
To: Simon Farrow
Cc: [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

Brian

NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 4 Dec 2013 10:39:21 +0000

I am not sure how we can ensure that video is recorded from start always.
For example if you RS is setup by SRC only after CS is connected (based on
a policy) which is going to be the case practically in most scenarios then
you will not be able to start recording from start.

Ram

-----Original Message-----
From: Dave Higton <[email-masked]>
Date: Wednesday, 4 December 2013 2:06 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

>What you're saying is that a video call MUST have video recorded right
>from the start, otherwise it isn't going to work.
>
>Dave
>
>I-frames very often; if a CS is not recorded in the beginning of the call
>but recorded later during the call, then it's hard to mandate an SRC to
>buffer media without a recording so that it can generate an I-Frame in
>the middle of the call.
>
>Henry
>
>NICE Systems UK Limited ("NICE") is registered in England under company
>number, 3403044. The registered office of NICE is at Tollbar Way, Hedge
>End, Southampton, Hampshire SO30 2ZP.
>
>Confidentiality: This communication and any attachments are intended for
>the above-named persons only and may be confidential and/or legally
>privileged. Any opinions expressed in this communication are not
>necessarily those of NICE. If this communication has come to you in error
>you must take no action based on it, nor must you copy or show it to
>anyone; please delete/destroy and inform the sender by e-mail immediately.
>
>Viruses: Although we have taken steps toward ensuring that this e-mail
>and attachments are free from any virus, we advise that in keeping with
>good computing practice the recipient should ensure they are actually
>virus free.

---

From: Henry Lum <[email-masked]>
Date: Wed, 4 Dec 2013 14:11:21 +0000

Should it always be the SRC sending FIR or the SRS can do that? I guess if we want to make SRS to be interoperable with any SRC then it would be simpler for the SRS to expect an IFrame as soon as RS is established. This means mandating the SRC to do something such as sending FIR or generate one on its own based on the SRC's RTP role. 

Acceptable clip is hard to quantify as a requirement, and I agree we should still put some text to point this out and let SRC to optimize this as an implementation issue.

Regards,
Henry

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: December-04-13 1:46 AM
To: Brian Rosen; Henry Lum
Cc: [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

Regards,
Ram

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Dec 2013 09:45:59 -0500

Some small confusion here.

The FIRST video sent by the SRC to the SRS has to be an I-frame.  If it’s not, the SRS will have to discard frames until it finds an I-Frame.  It could send a FIR to the SRC to ask for that I-Frame, but the SRC already knows it must send one, so that FIR isn’t very useful.

The SRC could be a lot of different kinds of things.  If it is, for example, a mixer (conference bridge, say), then it might be generating the video its sending to the SRS, and it can arrange an I-Frame to come first.  If it’s a video endpoint, then it would be recording two streams, its own and the stream it receives.  We need to take these separately:

For the stream its sending, it has two options.  One is that it creates an entirely separate encoding for the RS.  In that case, it can start with an I-Frame.  The other option is that it clones the stream it’s sending to the other endpoint.  In that case, it essentially has to behave as if it received a FIR from the other endpoint - finish the frame it’s encoding, then send an I-Frame to both the other endpoint and the SRS.  From then on, it’s sending the same stream to both.  If it gets a FIR from either the other endpoint or the SRS, it generates an I-Frame to both.

For the stream its receiving, it also has two options.   It can re-encodes the stream it decoded, in which case it can arrange an I-Frame to come first.  Or, it can clone the stream it receives,  In that case, it will need to send a FIR to the other endpoint.  It will have to clip until it gets that I-Frame.  There really isn’t much a choice.  That FIR should be sent as soon as it realizes it will be creating an RS.

Brian

---

From: Henry Lum <[email-masked]>
Date: Wed, 4 Dec 2013 15:06:35 +0000

The SRC can also be an RTP translator that simply forks media from an endpoint to the SRS. In this case, the SRC can send an FIR to the endpoint to generate an I-Frame when RS is established.

Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: December-04-13 9:46 AM
To: Henry Lum
Cc: Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

The FIRST video sent by the SRC to the SRS has to be an I-frame.  If it's not, the SRS will have to discard frames until it finds an I-Frame.  It could send a FIR to the SRC to ask for that I-Frame, but the SRC already knows it must send one, so that FIR isn't very useful.

The SRC could be a lot of different kinds of things.  If it is, for example, a mixer (conference bridge, say), then it might be generating the video its sending to the SRS, and it can arrange an I-Frame to come first.  If it's a video endpoint, then it would be recording two streams, its own and the stream it receives.  We need to take these separately:

For the stream its sending, it has two options.  One is that it creates an entirely separate encoding for the RS.  In that case, it can start with an I-Frame.  The other option is that it clones the stream it's sending to the other endpoint.  In that case, it essentially has to behave as if it received a FIR from the other endpoint - finish the frame it's encoding, then send an I-Frame to both the other endpoint and the SRS.  From then on, it's sending the same stream to both.  If it gets a FIR from either the other endpoint or the SRS, it generates an I-Frame to both.

For the stream its receiving, it also has two options.   It can re-encodes the stream it decoded, in which case it can arrange an I-Frame to come first.  Or, it can clone the stream it receives,  In that case, it will need to send a FIR to the other endpoint.  It will have to clip until it gets that I-Frame.  There really isn't much a choice.  That FIR should be sent as soon as it realizes it will be creating an RS.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Dec 2013 10:23:21 -0500

Sure, that’s like my last example.  The key is that there will be clipping until one arrives and is sent to the SRS.  If there is a requirement to not clip, then some other way to get the video is needed other than clone RTP packets.  It’s not all that hard to re-encode.

I think the best we can do here, since we can’t impose requirement on the other endpoints, is to have some discussion of the topic in the text and recommend FIR support.  Since there are problems where the SRS really has to request a FIR from the SRC, we need to require support for it in both SRS and SRC, but that is unrelated to the topic of initial I-Frame.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Dec 2013 10:26:16 -0500

Why do we need to define what is an acceptable clip?
It is the SRC that is deciding to initiate the recording. So why isn't 
it at the discretion of the SRC what clip is acceptable? This is a 
quality of implementation issue, not a standardization issue.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Dec 2013 10:34:33 -0500

> fall back to RFC5168 INFO method when the sender does not implement RFC5104"

ISTM that we need to have some text about how to deal with the two 
mechanisms. I don't think we can require UAs in the CS to support both 
mechanisms. So I think we must make it a requirement on the SRC and/or 
the SRS to deal with interworking.

ISTM that we can reasonably put a requirement on the SRS to support both 
mechanisms.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Dec 2013 10:37:52 -0500

Actually, I think you have to require the SRC to support both mechanisms, because you want the best chance it can send a FIR to the other UA in the CS.  You could allow the SRS to choose, but actually, I’d say require 5104.

Brian

On Dec 4, 2013, at 10:34 AM, Paul Kyzivat <[email-masked]> wrote:

> ISTM that we need to have some text about how to deal with the two mechanisms. I don't think we can require UAs in the CS to support both mechanisms. So I think we must make it a requirement on the SRC and/or the SRS to deal with interworking.
> 
> ISTM that we can reasonably put a requirement on the SRS to support both mechanisms.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Dec 2013 11:31:50 -0500

> Actually, I think you have to require the SRC to support both mechanisms, because you want the best chance it can send a FIR to the other UA in the CS.  You could allow the SRS to choose, but actua…

I mention the SRS first because it is generally the most capable device, 
and the one there are the fewest of.

SRCs may be incorporated into all sorts of things, some fairly limited.

If an SRC is just relaying the frame refresh requests, it may be easier 
for it to only support what the CS supports rather than interworking two 
mechanisms.

But I haven't thought through fully whether there are problems with this.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 4 Dec 2013 16:43:55 +0000

Agree that this is purely implementation dependent. IMO we can have some
text on what SRC is expected to do (like Request for FIR or pass FIR from
SRS if it gets one or generate I-frame) depending on what the SRC is
(mixer or translator)

Ram

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Date: Wednesday, 4 December 2013 8:56 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

>>>> On Dec 3, 2013, at 1:32 PM, Simon Farrow
>>>><[email-masked]>
>>>> wrote:
>>>>
>>>>> problems with video is that parties in a call use different
>>>>>approaches
>>>>> for
>>>>> video fast update requests. What we witnessed was the SRC may not
>>>>>send
>>>>> the
>>>>> SRS the original I-Frame as the call was still being setup between
>>>>>the
>>>>> SRC
>>>>> "User Agents in the ESInet must support both RFC5104 [160] and
>>>>>RFC5168
>>>>> [161]
>>>>> for full frame refresh requests.  The RFC5104 RTCP method is
>>>>>preferred
>>>>> with

---

From: Brian Rosen <[email-masked]>
Date: Wed, 4 Dec 2013 13:31:20 -0500

But, the SRC really, really wants to be able to get a FIR to the UA in the CS.  Therefore, it has to support both.  No limitation of the SRC in this regard can be made up by smarts in the SRS.  So the SRC has to support both 5104 and 5168.  You could, I suppose say that if the SRC knows, for sure, that each and every one of the UAs in the CS supports one of them, then it doesn’t have to support the other.

If the SRC supports both, then the SRS could, in theory, support either.  I think that is a mistake.  It should support 5104, it’s a better mechanism.  5168 documents an old mechanism. 

Interworking the two is pretty easy.  If you really think that it’s a burden, then supporting both on the SRS would fix that.

Brian

On Dec 4, 2013, at 11:31 AM, Paul Kyzivat <[email-masked]> wrote:

> I mention the SRS first because it is generally the most capable device, and the one there are the fewest of.
> 
> If an SRC is just relaying the frame refresh requests, it may be easier for it to only support what the CS supports rather than interworking two mechanisms.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Dec 2013 16:39:15 -0500

> Interworking the two is pretty easy.  If you really think that it’s a burden, then supporting both on the SRS would fix that.

I'm thinking of a UA that acts as its own SRC. Maybe it only supports 
one of the mechanisms, so it knows the one it supports is used on the 
CS. So it can use that one on the RS too.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 10 Dec 2013 09:45:53 +0000

I'm not sure we need to place any requirements on the SRC or SRS. We
currently recommend that SRCs, SRSs, and recording aware UAs support and
use FIR (RFC 5104). We mention the potential use of SIP INFO (RFC 5168)
but state it is to be used for backward compatibility purposes. FIR is
preferred. See section 8.1.7.1.
If the SRC does not support SIP INFO (RFC 5168) and a UA within a given CS
only supports SIP INFO, the SRC will not be able to record that CS. Video
might not even work in the first place. I think this a quality of
implementation question, not something SIPREC should mandate. Same for the
SRS. A mismatch in FIR/SIP INFO between the SRC and SRS should result in
the RS establishing as audio only in my opinion. We could make the
existing recommendation stronger, but I think it is fine as is.
Section 8.2 provides information on how an SRC and SRS should deal with
packet loss. I thought of this as covering the initial I-frame case, but
perhaps more details are needed here?

Cheers,
Charles

On 12/4/13 1:39 PM, "Paul Kyzivat" <[email-masked]> wrote:

>> But, the SRC really, really wants to be able to get a FIR to the UA in
>>the CS.  Therefore, it has to support both.  No limitation of the SRC in
>>this regard can be made up by smarts in the SRS.  So the SRC has to
>>support both 5104 and 5168.  You could, I suppose say that if the SRC
>>knows, for sure, that each and every one of the UAs in the CS supports
>>one of them, then it doesn¹t have to support the other.
>>
>> If the SRC supports both, then the SRS could, in theory, support
>>either.  I think that is a mistake.  It should support 5104, it¹s a
>>better mechanism.  5168 documents an old mechanism.
>>
>> Interworking the two is pretty easy.  If you really think that it¹s a
>>burden, then supporting both on the SRS would fix that.
>
>>>> Actually, I think you have to require the SRC to support both
>>>>mechanisms, because you want the best chance it can send a FIR to the
>>>>other UA in the CS.  You could allow the SRS to choose, but actually,
>>>>I¹d say require 5104.
>>>
>>> I mention the SRS first because it is generally the most capable
>>>device, and the one there are the fewest of.
>>>
>>> If an SRC is just relaying the frame refresh requests, it may be
>>>easier for it to only support what the CS supports rather than
>>>interworking two mechanisms.
>>>
>>>>>>RFC5168 [161]
>>>>>>preferred with
>>>>>mechanisms. I don't think we can require UAs in the CS to support
>>>>>both mechanisms. So I think we must make it a requirement on the SRC
>>>>>and/or the SRS to deal with interworking.
>>>>>

---

From: "Dave Higton" <[email-masked]>
Date: Tue, 10 Dec 2013 10:50:50 +0000

You seem to be saying that, if video recording doesn't work, it's not our problem.

It's exactly our problem.  If someone wants to record video, and they engineer the system according to the eventual SIPREC RFC, it should work every time.  That's what the SIPREC RFC is for.

Dave

-----Original Message-----
From: siprec [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: 10 December 2013 09:46
To: Paul Kyzivat; Brian Rosen
Cc: [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 11 Dec 2013 09:44:22 +0000

Hi Dave,

I see your point, and I do not necessarily disagree. SIPREC
interoperability is obviously important to me as well. However, we did not
go so far as to mandate support for specific audio codecs or specific
video codecs. What if the CS is negotiated to use codecs the SRS does not
support? Do we need to mandate the SRC to transcode, or mandate support
for a common set of codecs? I was lumping support for FIR and/or SIP INFO
into quality of implementation decisions rather than things we need to
mandate. The current spec provides the guidance I mentioned but does not
provide any strict requirements. The recent findings at the NENA event are
making me rethink this position, so I am happy to hear more about you and
others think.

Cheers,
Charles

On 12/10/13 11:50 AM, "Dave Higton" <[email-masked]> wrote:

>It's exactly our problem.  If someone wants to record video, and they
>engineer the system according to the eventual SIPREC RFC, it should work
>every time.  That's what the SIPREC RFC is for.
>
>Dave
>

---

From: "Dave Higton" <[email-masked]>
Date: Wed, 11 Dec 2013 10:42:32 +0000

Hi Charles,

We have to look at the system as a whole.  The system has to be engineered so that all required recording takes place to an adequate standard; conformance to various RFCs is required in order to guarantee this.  In turn, conformance to those RFCs should be sufficient to guarantee adequate results.

The SRS has to be engineered to record all the media that the customer wants to record.  If the communications system is prepared to negotiate a video codec and the customer wants to record the video of the CS, the SRS and SRC must be engineered and provisioned to work together in terms of the codecs and/or transcoding.

It's worth pointing out, as you say, that one of the options must be true: either the SRS supports all the codecs that the SRC does, or the SRC transcodes as necessary.

It all hangs on the conditional "if recording is required" - but isn't that true by definition, otherwise the SIPREC RFC wouldn't be in consideration?

Dave

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
Sent: 11 December 2013 09:44
To: Dave Higton; [email-masked]
Subject: Re: [siprec] Feedback from NENA ICE-8 Event

Hi Dave,

Cheers,
Charles