Re: [siprec] FIR vs. SIP INFO

["Ram Mohan R (rmohanr)" <[e-mail]>]

Proposed text looks good to me.

Ram

-----Original Message-----
From: "Charles Eckel   (eckelcu)" <[e-mail]>
Date: Saturday, 14 June 2014 10:21 am
To: Ram Mohan Ravindranath <[e-mail]>, "[e-mail]"
<[e-mail]>
Subject: Re: [siprec] FIR vs. SIP INFO

>Reviving a sleeping thread …
>
>The sense of the room, as captured in the meeting minutes, was that we add
>a requirement on the SRS to support both methods. Continuing the
>discussion on the list resulted in only one addition comment, from Ram, in
>support of this proposal.
>With this in mind, I propose we append the following to section 8.1.7.1.1:
>
>"To make sure a common mechanism exists between the SRC and SRS, the SRS
>MUST support both mechanisms (FIR and SIP INFO), using FIR when negotiated
>successfully with the SRC, and using SIP INFO otherwise."
>
>Comments and other ideas welcome.
>
>Cheers,
>Charles
>
>On 3/20/14, 8:03 PM, "Ram Mohan R (rmohanr)" <[e-mail]> wrote:
>
>>I prefer option 2 as mandatory since SRS is the one that eventually looks
>>at the media being recorded(RTP) and is the best one to decide on whether
>>to generate a FIR or SIP INFO.  However we may also allow a SRC to
>>generate a FIR/SIP INFO. So I prefer that we can keep MUST for option 2
>>and MAY for option 1.
>>
>>I have a slightly different question on this -
>>Do we want SRS(or SRC) to always generate both FIR and SIP INFO ? There
>>may be cases where endpoint (UA) may support one or both of them. If a UA
>>supports both of them it may result in a case where UA may re-transmit
>>IDR
>>frame twice (one on receipt of FIR and other on on receipt of SIP INFO).
>>This is ok in principle but may lead to more network congestion due to
>>bursty traffic. Is this some thing we should worry about ?
>>
>>Perhaps if there is a way SRS/SRC can find what method the UA prefers
>>(FIR
>>or SIP INFO) it can only generate that.
>>
>>Ram
>>
>>
>>-----Original Message-----
>>From: "Charles Eckel   (eckelcu)" <[e-mail]>
>>Date: Friday, 21 March 2014 2:34 am
>>To: "[e-mail]" <[e-mail]>
>>Subject: [siprec] FIR vs. SIP INFO
>>
>>>To the best of my knowledge, this is the last open item in the protocol
>>>draft. Here is the info from the slide presented at IETF 89 in London:
>>>
>>>FIR and SIP INFO requirements in SRC and/or SRS
>>>------------------------
>>>Section 8.1.7.1.1 SIP INFO for FIR
>>>¨"XML Schema for Media Control² [RFC5168
>>><http://tools.ietf.org/html/rfc5168>] defines an Extensible Markup
>>>Language (XML) Schema for video fast update. Implementations are
>>>discouraged from using the method described except for backward
>>>compatibility purposes. Implementations SHOULD use FIR messages instead.
>>>
>>>NENA ICE-8 event feedback, do we need to say more? Options:
>>>1.SRC MUST support both and provide interworking to what SRS supports
>>>(and
>>>an UA that does not support both MUST NOT use SIPREC?)
>>>2.SRS MUST support both (and allow SRC to support both simultaneously?
>>>And
>>>how do you negotiation that ?)
>>>3.Provide recommendations and leave as quality of implementation
>>>decision
>>>(and live with interoperability issues?)
>>>-----------------------------
>>>
>>>Discussion in room (from minutes:
>>>http://www.ietf.org/mail-archive/web/siprec/current/msg03934.html)
>>>- Paul K - no brainer, SRS is the powerful box - that is the place to
>>>put
>>>requirements - 2 is preferable to 1 - 2 vs. 3, I'm not sure, kind of
>>>inclined for 2 but not sure
>>>- Chair: definitive is best for implementation
>>>- Charles: option 3 is my suggestion (as the draft is), but could live
>>>with option 2 - would appreciate some help with the text - need to think
>>>about use cases - if a UA is capable of dealing with both, it can
>>>simplify
>>>for the SRS, but depends on capabilities of the SRC and SRS - if we can
>>>do
>>>better that is great
>>>- Chair: let's have more list discussion because missing people - but in
>>>favour of documenting one and generally in favour of having the server
>>>do
>>>the work - tentatively think going in the direction of option 2
>>>
>>>Thoughts?
>>>
>>>Cheers,
>>>Charles
>>>
>>>_______________________________________________
>>>siprec mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/siprec
>>
>