Re: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)

[Christer Holmberg <[e-mail]>]

Hi, 

>> Having said that, *today* PRACK support may be more common (75%, according to the SIPit report) than back in those 
>> days, and if in addition SRTP mandates PRACK support there might not be a real-life problem.
>
> Oh, I didn't know that SRTP mandates PRACK, then we are done :)

I don't think SRTP as such mandates PRACK. But, whatever media negotiations, that require reliably sent SDP, you want to do during the early dialog require PRACK.

>>> Anyhow, let's remember that the purpose of WebRTC is not the 
>>> interoperability with old SIP phones which implement nothing but plain SIP and plain RTP.
>>
>> I agreed.
>>
>> And, my main concern is not whether endpoints will support PRACK, but having to send new offers just because of forking.
>
> Of course I prefer not having to use that but, should WebRTC modify PeerConnection specs just for allowing SIP media forking?

WebRTC is not going to modify anything. AFAIK, we will ask W3C to do it, based on our wishes and requirements.

However, it would only be needed if we decide to support parallel forking. If we choose to only require support of serial forking, you may not have to create new PeerConnections - if you can modify the remote media parameters of the existing one.

As I've said before, I am personally fine with supporting serial forking, but if we can get parallel forking "for free" that's of course good.


>>>> So I don't expect that WebRTC will allow reusing the same local candidates in a new PeerConnection just to allow SIP media forking.
>>>
>>> Well, that's what we have to figure out.
>>
>> I would also like to know what non-SIP folks think about this.

First I think the SIP folks shall agree on what THEY want. Then we'll see whether/how it's possible to achieve, and what others think.


Regards,

Christer