Re: [rtcweb] rtcweb Digest, Vol 17, Issue 10

[Remi Scavenius <[e-mail]>]

The programme of the WebRTC Conference (Paris, October 10-12) is online:
http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html

Regards

Remi Scavenius, agenda manager.

Le 5 juil. 2012 à 13:30, [e-mail] a écrit :

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
> 
> 
> 
> Send rtcweb mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/rtcweb
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of rtcweb digest..."
> Today's Topics:
> 
>   1. Re: Do we still need PRANSWER? (Chenxin)
>   2. Re: RTP Usage: Is RTP Retransmission REQUIRED or	RECOMMENDED
>      (Randell Jesup)
>   3. Re: Do we still need PRANSWER? (I?aki Baz Castillo)
>   4. Re: Do we still need PRANSWER? (Olle E. Johansson)
>   5. Re: Do we still need PRANSWER? (Roman Shpount)
> 
> De : Chenxin <[e-mail]>
> Date : 5 juillet 2012 06:00:15 HAEC
> À : Roman Shpount <[e-mail]>
> Cc : "[e-mail]" <[e-mail]>
> Objet : Rép : [rtcweb] Do we still need PRANSWER?
> 
> 
> +1
>  I think PRANSWER is still useful for Jingle interop especially  for ICE candidate trickling.
>  
> But I think we should not leave the WebRTC-SIP interop  problem to the application layer gateway.
>  
> I find some words in chart:   
>  9.  The group will consider options for interworking with legacy VoIP
>         equipment.
>  
> it is necessary to solve SIP interop problem in RTCWEB other than leaving it to implementor.
>  
> BR,
>     Xin
> From: Roman Shpount [mailto:[e-mail]] 
> Sent: Thursday, July 05, 2012 3:47 AM
> To: [e-mail]
> Subject: [rtcweb] Do we still need PRANSWER?
>  
> It looks like WebRTC-SIP interop without an application layer gateway would not be possible in the near future due to all the media transport requirements that were introduced. Given that SIP interop is no longer possible, why do we still need PRANSWER? Since an application layer gateway must be deployed, the same gateway can handle both serial and parallel forking. The WebRTC application will work with the gateway to create new streams or to create new connections, as necessary when new SIP dialogs are created and new answers are received.
> _____________
> Roman Shpount
> 
> 
> 
> De : Randell Jesup <[e-mail]>
> Date : 5 juillet 2012 07:10:55 HAEC
> À : [e-mail]
> Objet : Rép : [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED
> 
> 
> On 7/4/2012 10:23 AM, Stefan Hakansson LK wrote:
>> On 07/02/2012 11:51 PM, Randell Jesup wrote:
>>> 
>>>> Again, this is about making _support_ for retransmission a requirement,
>>>> not _use_.
>>> 
>>> 
>>> If you don't mandate use, what does mandating "support" buy you?  An
>>> implementation (see above about PSTN gateways) might always decline to
>>> use retransmission, so what does MUST (REQUIRE) buy you?  I say SHOULD
>>> (RECOMMEND), with a statement that it's strongly recommended it be
>>> supported if video is supported, especially for non-single-purpose
>>> devices (i.e. browsers).
>>> 
>>> In either case, you need to think about who decides to use re-xmit or
>>> not, what influences that, and if the app has visibility into this.
>>> Someone could as an rtx-time=0 to the SDP.  Or not include one, but
>>> never actually retransmit a packet regardless of NACKs - it could just
>>> repair via IDR (or other means).
>>> 
>>> So here's a real problem related to retransmission: since the request is
>>> not specific and negotiated (it's normally a generic NACK), the receiver
>>> who sent the NACK has no idea if it will get a retransmission, an IDR
>>> (or IDR slice), another form of repair (pframe/slice against
>>> known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, it
>>> doesn't know if it should freeze the video or play with errors. It has
>>> to decide if it *thinks* the sender will use retransmission, or if it
>>> doesn't, does the receiver want to freeze video until an IDR or other
>>> repair is done, which might be a while.
>> 
>> Isn't retransmission negotiated using "rtx", "atp" and so on?
> 
> Support for it is.  However, negotiating support for it doesn't solve the problem of not knowing how the sender will respond to a NACK (or SLI/RPSI/etc).  Generally, the sender has to make the decision, but the receiver has to guess.
> 
>> 
>> One way of removing the uncertainty would be to require that all browsers support RTP retransmission: This way, any RTP endpoint sending a NACK to a browser would know that that packet would be retransmitted (given that congestion does not prohibit, or NACK packet is lost etc.).
> 
> Um, no.  Just because both sides support retransmission does not mean that a NACK will generate a retransmission.  Retransmission only makes sense in some instances, and there's no guarantee that retransmission will be possible (for example, the requested packet might have timed out and been thrown away).
> 
>> 
>> If we have this in place, I'm confident that implementors will quickly develop strategies on how and when to _use_ retransmission in the best way. There has already been input made on its usefulness.
> 
> Sure, and they will anyways.  RECOMMENDED or REQUIRED, it really doesn't matter to the implementation.  For that matter, even if REQUIRED there's nothing that says it has to be offered or accepted.  Even if that were mandated, the implementation could accept but with a 0-length rtx-time.  So it's really unclear what REQUIRED buys you that RECOMMENDED doesn't.
> 
>> 
>> Maybe the problem with legacy not always supporting retransmission is not that big. First of all, legacy is to a large extent audio only (e.g. PSTN), and no one is arguing for retransmission there. Secondly, I fail to see that this situation would be improved in any way if browsers are only recommended (and not required) to support RTP retransmission.
>> 
>> So I think we should require rtcweb capable browsers to support RTP retransmission.
>> 
>>> 
>>> We also need to think about when a receiver should use SLI or RPSI.  PLI
>>> can also be used and should be if the other options don't negotiate (so
>>> it's important to offer it).  Certainly it's more work to keep track of
>>> the contents of each packet (slices, etc), especially in things like
>>> H.264 NALU aggregation packets, than it is to just respond to an SLI.
>>> 
>>> That said, my previous systems just used NACK and let the sender decide
>>> the correct repair, but I wasn't leveraging slices and wasn't using
>>> retransmission, so there was only minor complexity (looking at possible
>>> reference frames).
> 
> 
> -- 
> Randell Jesup
> [e-mail]
> 
> 
> 
> 
> 
> De : Iñaki Baz Castillo <[e-mail]>
> Date : 5 juillet 2012 10:48:53 HAEC
> À : Roman Shpount <[e-mail]>
> Cc : [e-mail]
> Objet : Rép : [rtcweb] Do we still need PRANSWER?
> 
> 
> 2012/7/4 Roman Shpount <[e-mail]>:
>> It looks like WebRTC-SIP interop without an application layer gateway would
>> not be possible in the near future due to all the media transport
>> requirements that were introduced. Given that SIP interop is no longer
>> possible, why do we still need PRANSWER? Since an application layer gateway
>> must be deployed, the same gateway can handle both serial and parallel
>> forking.
> 
> No please, don't decide/mandate/impose how the signaling must be
> implemented. And don't assure that pure SIP signaling cannot be used
> in the browser neither force the usage of annoying B2BUA's or
> signaling-protocol-exotic-and-buggy-gateways in order to interop with
> SIP networks (mostly because pure SIP interop is already possible
> without negative elements like B2BUA's or signaling gateways).
> 
> I want a pure SIP proxy and handle parallel and serial SIP forking as
> RFC 3261 states, without magic servers breaking things. And this
> *already* works [1] so it IS possible.
> 
> If most of the people assume that WebRTC-SIP interop requires some
> amateur and limited JSON based signaling protocol between the
> (stupid?) browser and a magic JSON-SIP-MEDIA gateway
> (super-intelligent?), that's their assumption, but that should not be
> mandatory by specs.
> 
> About the media plance interop: ok, WebRTC has added lot of stuff, but
> AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible
> to interop in the media plane without negative intermediary elements.
> In the other side, once WebRTC is extended I'm pretty sure that SIP
> designers and vendors will try to satisfy WebRTC media requirements
> within SIP, so let's leave the door open rather than "requiring $$$$$
> B2BUA's black-death-boxes".
> 
> Please, don't limit or force the network topology.
> 
> 
> 
>> The WebRTC application will work with the gateway to create new
>> streams or to create new connections, as necessary when new SIP dialogs are
>> created and new answers are received.
> 
> No, sorry, no. Or yes (in your specific case), but not in mine.
> 
> 
> Regards.
> 
> 
> [1] http://sip-on-the-web.aliax.net/
> 
> 
> -- 
> Iñaki Baz Castillo
> <[e-mail]>
> 
> 
> 
> 
> De : "Olle E. Johansson" <[e-mail]>
> Date : 5 juillet 2012 11:12:55 HAEC
> À : Roman Shpount <[e-mail]>
> Cc : [e-mail]
> Objet : Rép : [rtcweb] Do we still need PRANSWER?
> 
> 
> 
> 4 jul 2012 kl. 21:46 skrev Roman Shpount:
> 
>> It looks like WebRTC-SIP interop without an application layer gateway would not be possible in the near future due to all the media transport requirements that were introduced. Given that SIP interop is no longer possible
> 
> I think that's a bad conclusion, Roman.
> 
> I talked about the installed base of SIP devices and their RTP stack. It doesn't mean that ALL SIP implementations won't be able to interop with WebRTC and that there never will be SIP connected to webrtc, either in a browser app or in a server implementation. I do expect that new SIP apps will arise and that the current ones will be upgrading. 
> 
> SIP interop is definitely possible in WebRTC regardless of the RTP layer.
> 
> I still think there's value in interop with a large installed base of RTP-capable devices. Having media relays in the media path is known not to improve media quality.
> 
> /O
> 
> 
> 
> De : Roman Shpount <[e-mail]>
> Date : 5 juillet 2012 13:30:14 HAEC
> À : Iñaki Baz Castillo <[e-mail]>
> Cc : [e-mail]
> Objet : Rép : [rtcweb] Do we still need PRANSWER?
> 
> 
> This was all written out of frustration mainly by the direction taken by this group on adding things that are not strictly necessary but break interoperability. It is completely incomprehensible to me  why the group decided to add PRANSWER if connection cloning is just as easy to implement and would make, on one hand, interop easier, on another hand add significant new functionality. When I am saying that connection cloning is easy to implement I mean that I am willing to build a prototype based on chromium code that implements it. Getting the new API through IETF/W3C is above my skill level, since I am fairly bad at writing drafts.
> 
> On Thu, Jul 5, 2012 at 4:48 AM, Iñaki Baz Castillo <[e-mail]> wrote:
> 2012/7/4 Roman Shpount <[e-mail]>:
> > It looks like WebRTC-SIP interop without an application layer gateway would
> > not be possible in the near future due to all the media transport
> > requirements that were introduced. Given that SIP interop is no longer
> > possible, why do we still need PRANSWER? Since an application layer gateway
> > must be deployed, the same gateway can handle both serial and parallel
> > forking.
> 
> No please, don't decide/mandate/impose how the signaling must be
> implemented. And don't assure that pure SIP signaling cannot be used
> in the browser neither force the usage of annoying B2BUA's or
> signaling-protocol-exotic-and-buggy-gateways in order to interop with
> SIP networks (mostly because pure SIP interop is already possible
> without negative elements like B2BUA's or signaling gateways).
> 
> I want a pure SIP proxy and handle parallel and serial SIP forking as
> RFC 3261 states, without magic servers breaking things. And this
> *already* works [1] so it IS possible.
> 
> 
> I do not doubt that some SIP interop on the signaling level is possible.  It would break, however, on a first case of parallel forking. My main concern, however, is the media level interop with any existing devices.
> 
> Correct me if I am wrong, but your already working solution is using an older WebRTC implementation that supported plain RTP.
> 
> If most of the people assume that WebRTC-SIP interop requires some
> amateur and limited JSON based signaling protocol between the
> (stupid?) browser and a magic JSON-SIP-MEDIA gateway
> (super-intelligent?), that's their assumption, but that should not be
> mandatory by specs.
> 
> I do not want magic gateways either, but it looks like when this group is adding features it assumes some sort of gateway would be present.
>  
> About the media plance interop: ok, WebRTC has added lot of stuff, but
> AFAIK if the SIP side implements ICE + SDES-SRTP it should be possible
> to interop in the media plane without negative intermediary elements.
> In the other side, once WebRTC is extended I'm pretty sure that SIP
> designers and vendors will try to satisfy WebRTC media requirements
> within SIP, so let's leave the door open rather than "requiring $$$$$
> B2BUA's black-death-boxes".
> 
> 
> SDES-SRTP support is not something that this group decided upon. If the group is honest about its security requirements (JavaScript application is not trusted), then SDES-SRTP should not be allowed. This means you need ICE+DTLS-SRTP+AVPF support in the SIP device to operate directly with WebRTC on the media plane. I curious if you can name one device that support all of those. I would actually buy one for interop alone. And from experience, I doubt that large SIP vendors would do anything meaningful for a while. 
> 
> Please, don't limit or force the network topology.
> 
> I do not, but I think that what the group effectively does. I got a feeling most of the major contributors only care about a limited sets of apps that do not need to concern themselves with interop. I also got a feeling that they are more concerned about marketing then security.
> 
> 
> > The WebRTC application will work with the gateway to create new
> > streams or to create new connections, as necessary when new SIP dialogs are
> > created and new answers are received.
> 
> No, sorry, no. Or yes (in your specific case), but not in mine.
> 
> It is, unfortunately, the only thing I can do in my case, since all the SIP end points I am dealing with (SIP Trunks in PBXs and SIP from VoIP vendors) do not support any encryption, have flaky support for SIP re-Invites, and some do parallel forking. It is the real world, and here, it is a magic box or bust.
>  
> [1] http://sip-on-the-web.aliax.net/
> 
> _____________
> Roman Shpount
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb