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

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.

The point is not to support simultaneous media flow with all forked targets (your talking to me and my daughter at the same time in Martin's example), but to support the ability to negotiate ICE and DTLS independently with each target before one of them "answers", to minimize the potential for clipping.

True parallel forking has been around for a long time and is supported in some (not all) existing systems.  We do not mandate ICE support (for example) because it is commonly deployed, but because it is useful; the same principle should apply here.  I have not heard that simultaneous alerting of multiple registered contacts is not useful, but just that some existing systems find ways of serializing the media interactions.  That is relatively easier to do when you don't support ICE and DTLS since media can flow almost as soon as you signal the SDP changes.

But things are different with ICE and DTLS, particularly if you want to avoid media intermediaries.  Significant clipping is a real possibility if we have to restart ICE/DTLS after the "winner" responds with 200 OK.

This is not a separate use case, but a given aspect of interworking with SIP.

Richard 

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: Thursday, May 10, 2012 5:48 PM
To: Martin Thomson
Cc: Randell Jesup; rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

On May 10, 2012, at 3:07 PM, Martin Thomson wrote:

> On 10 May 2012 13:56, Cullen Jennings <fluffy@iii.ca> wrote:
>> I was looking more for the actually sort of end user use case where this might happen.
> 
> I ring you.
> Your mobile and home phone both ring.
> You answer your mobile, your daughter answers the home phone.
> I get to talk to both of you.
> 
> Of course, that's not such a great outcome.  I can hear both of you,
> but you can't hear each other unless I have really bad echo
> cancellation.
> 
> I tend to think of this as solving a really interesting signaling
> problem that doesn't really have any practical application.  If you
> want to talk to both people, then you should signal the creation of a
> conference call.
> 
> --Martin

That an good use cases, except the people need to be able to hear each other. It gets called lots of things but some PBXs call it bridged line appearance. Variation of it have been discussed in bliss and draft-ietf-bliss-shared-appearances. It really comes down to where you think the conferencing should happen. If it does not happened on the the callers phone, seems like existing jsep idea should be able to do this.  (given the callee is the phone that is most likely out of administrative control of the other two phones that set up bridged line a appearance, assuming that phone can and is willing to do the conferencing seems like a bad architecture for this problem). Again lot of systems do this today in SIP and seem to do it without needing forcing the callers phones to deal with multiple simultaneous calls signaled in some way I don't even know how to signal in SIP. 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb