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

[Iñaki Baz Castillo <[e-mail]>]

2011/10/30 Christer Holmberg <[e-mail]>:
>>> 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 :)

Sure, but WebRTC is not SIP and must not be designed just in order to
interoperate with SIP.


> 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 :)



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



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


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

Ok: in order to allow SIP media forking, WebRTC should allow reusing
the same local candidates in a new PeerConnection (or making a single
PeerConnection capable of sending and receiving RTP to/from more than
a single remote peer).

Remember that WebRTC does not mandate a protocol in-the-wire, so a
developer could make a new/custom protocol in which for each "early
response containing media" it creates a new PeerConnection. However
that does not fit well with SIP. But this is just a SIP issue, not a
WebRTC issue.

Should PeerConnection become more complex just for those willing to
implement SIP (or something that can be mapped to SIP) in WebRTC and
interoperate with SIP?

I insist: this limitation *just* affects to SIP (due to SIP nature in
which a UAC MUST be able to send/receive RTP to different peers using
the same local address). Any other protocol implemented on top of
WebRTC could avoid this limitation with a proper design. So should
WebRTC be conditionated by SIP protocol requirements? I don't think
so, regardless the number of SIP folks participating in this WG (I
still think WebRTC is something for the Web).

So this is the reason of my assumption.


Regards.


-- 
Iñaki Baz Castillo
<[e-mail]>