Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

[Randell Jesup <[e-mail]>]

On 5/14/2012 4:31 PM, Martin Thomson wrote:
> On 14 May 2012 11:45, Roman Shpount<[e-mail]>  wrote:
>> It is possible to resolve this identity to end
>> point mapping using some sort of HTTP signaling
>
> I think that this was the point.  Your application has some concept of
> identity that maps to one or more registered endpoints.  It can work
> out the signaling such that all devices get notified of a session
> request without the need for this complex cloning mess.

That isn't the point of cloning (getting notified).  It's the server in 
this case that knows about the multiple endpoints.  (For that matter, 
one could be a WebRTC client, and another could be a WebRTC gateway to 
PSTN, and a third could be a network-based answering service where a 
pickup from an actual endpoint would abort the playback/recording - 
another case of a forked ANSWER after a final ANSWER where cloning is 
useful.)

-- 
Randell Jesup
[e-mail]