Re: [Ecrit] Phonebcp issues

[Hannes Tschofenig <[e-mail]>]

Going back to the working group is indeed a difficult issue. I have experienced that already within the GEOPRIV working group and it stalled the work for years. I do, however, wonder whether this is entirely necessary. Isn't there a shorter route where the working group needs to approve the change of the issue. I would even be OK with saying that this entire media loopback functionality is optional and to turn it into an informative reference. 

Another option is to "motivate" the authors of draft-ietf-mmusic-media-loopback to get their work done. There are unfortunately 6 authors on that document and without knowing the history I could imagine that nobody feels responsible for pushing it forward. 

In any case, we need to do something. Just waiting isn't an option. 

On Mar 9, 2012, at 6:19 PM, Brian Rosen wrote:

> To do this, we would have to take the document back into the working group, make changes, and run through the approval process.
> 
> I think this is something we should consult with ADs before we do anything.
> 
> I don't have a problem with making the changes.  I'm just looking for the path of least resistance.
> 
> Brian
> 
> On Mar 9, 2012, at 7:29 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> 
>> Hi Gunnar, 
>> Hi all, 
>> 
>> I agree with you regarding the dependency to the media loopback document. 
>> The required functionality for PhoneBCP is actually pretty simple. 
>> 
>> I would be in favor of untangling the dependency to draft-ietf-mmusic-media-loopback. 
>> 
>> For the SRTP media security I would suggest to go for MUST implement SDES and SHOULD implement DTLS-SRTP. 
>> 
>> Ciao
>> Hannes
>> 
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of ext Gunnar Hellström
>>> Sent: Friday, March 09, 2012 1:26 PM
>>> To: Ecrit
>>> Subject: [Ecrit] Phonebcp issues
>>> 
>>> The final publication of draft-ietf-ecrit-phonebcp has now been hanging
>>> waiting 7 months for draft-ietf-mmusic-media-loopback to be finalized
>>> because it is referenced in the test section.
>>> The status of the media-loopback draft is that it seems to be less
>>> ready
>>> now than 7 months ago.
>>> 
>>> This makes in fact even RFC 6443 impossible to implement, because RFC
>>> 6443 refers to phonebcp for specification of the testing procedure
>>> 
>>> I wonder if it is time to pull phonebcp loose from the dependency of
>>> the
>>> media-loopback draft and specify a simple test method of its own
>>> instead. I do not think that the current specification in phonebcp is
>>> very realistic, with just a loopback. I think the test server could
>>> just
>>> as well generate some own initial test media and then possibly also
>>> mirror some packets when received. The current behavior of the
>>> media-loopback to wait for incoming media before it generates any
>>> outgoing media is not similar to what will be the scenario in real
>>> calls. Both sides in real calls normally take initiative to media
>>> transmission after the session is established. The resulting problems
>>> for NAT traversal of the current media-loopback draft is one of the
>>> issues that has caused its delay.
>>> 
>>> Another small issue: RFC 6443 recommends SRTP to be used for media
>>> security, but phonebcp does not mention media security.
>>> phonebcp is approved, so I do not think it is appropriate to open it
>>> for
>>> such additions. Can this gap be covered in some additional draft, or
>>> can
>>> we rely on implementors to apply both phonebcp and RFC 6443?
>>> 
>>> Gunnar
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit