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

[Christer Holmberg <[e-mail]>]

Hi, 

>> I don't like the idea of having to send UPDATE/re-INVITE for every new early dialog.
>
> Hi Christer, it was just a suggestion, I'm not traying to mandating or standarizing nothing :)

And I didn't like the suggestion :)

>> In addition, I am not even sure it would work with ICE. Remember that ICE allows the UAS to send 
>> an "answer" unreliably (the unreliabe 18x is re-transmitted a few times), but since it's not a real 
>> answer, the UAC is not allowed to send an UDPATE.
>
> 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 :)

Regards,

Christer





>> In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the 
>> *same* address/candidate parameters as the "parent" PeerConnection. In such case there is no need to send an UPDATE.
>
> Sure! but my suggestion was based on the assumption that WebRTC won't allow reusing the same local address/candidates in two different PeerConnection's.

Regards.




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