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

[Roman Shpount <[e-mail]>]

On Mon, May 14, 2012 at 5:25 AM, Tim Panton <[e-mail]> wrote:

>
> On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote:
>
> > Support for multiple registered contacts and (parallel) forking are
> pretty fundamental to SIP.  This has little to do with conferencing.  Some
> systems (not all) may support only serial forking or may serialize media
> interactions associated with parallel forking, but forking remains widely
> deployed and useful.
>
>
> I have a feeling that it is mostly useful because SIP is managing both the
> signalling and the identity.
> In most WebRTC cases, the real identity of the user will be established
> with a web protocol (perhaps OAuth).
> The identity used in any browser based legacy signalling (e.g. SIP) will
> be a second-order derived or temporary identity.
>
> In that case there is no need for SIP to use the same  temporary identity
> for both my phones, which (I think)
> renders the forking case significantly less useful.
>
>
I strongly disagree with this. I can still be calling somebody via, let's
say, their email address and end up talking to two people using two
different devices. I think there is always going to be the situation where
one identity (email address, support link on the web site) will map to
multiple physical end points. It is possible to resolve this identity to
end point mapping using some sort of HTTP signaling before media connection
is setup and then to generate offers for each end point, but this would
make signaling more complex, and would slow down the call connect process
by at least half the round trip time.
_____________
Roman Shpount