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

[Christer Holmberg <[e-mail]>]

Hi, 

>>> I don't agree. If the UAC receives a 180 it means that the 180 has 
>>> been received (regardless it was unreliable), so UPDATE is possible.
>>
>> Ok, small correction: you are not allowed to send a new offer before 
>> you have received the previous answer in a reliably sent response :)
>
> Ok, PRACK (RFC 3262) dates from 2002, so just add "Require: 100rel" in the INVITE and you are done. Of course, if 
> the remote SIP peer does not implement PRACK I am sure it won't implement ICE and SRTP, so interoperability with a WebRTC client is not possible anyway.

Dude, where were you when they wrote RFC 5245? The reason they specified the re-transmission of un-reliable 18x responses was so that ICE entities would NOT have to support PRACK :)

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.

> 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, nobody prevents you from doing that, if you want :)

> 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.

And, just for the record: based on what do you make that assumption?

Regards,

Christer