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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 12 Feb 2014 23:26:09 +0000

We had a lengthy discussion on this, but no resolution.

Dave and I obviously see this differently. This discussion has some
relation to the more recent discussion on lossless recording.
I am happy to add whatever text the group thinks is helpful, but I am not
sure what to add.

Cheers,
Charles

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

>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,
>
>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:
>
>>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
>>
>>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:
>>
>>>On 12/4/13 1:31 PM, Brian Rosen 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.
>>>
>>>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
>>>
>>>> Brian
>>>>
>>>> On Dec 4, 2013, at 11:31 AM, Paul Kyzivat <[email-masked]>
>>>>wrote:
>>>>
>>>>> On 12/4/13 10:37 AM, Brian Rosen wrote:
>>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>>> Brian
>>>>>>
>>>>>> On Dec 4, 2013, at 10:34 AM, Paul Kyzivat <[email-masked]>
>>>>>>wrote:
>>>>>>
>>>>>>> On 12/3/13 1:32 PM, Simon Farrow wrote:
>>>>>>>
>>>>>>>> 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"
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>_______________________________________________
>>>siprec mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/siprec
>>
>>_______________________________________________
>>siprec mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/siprec
>>
>>
>>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.
>>_______________________________________________
>>siprec mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/siprec
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec