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

[Randell Jesup <[e-mail]>]

On 5/10/2012 6:47 PM, Cullen Jennings wrote:
> On May 10, 2012, at 3:07 PM, Martin Thomson wrote:
>
>> On 10 May 2012 13:56, Cullen Jennings<[e-mail]>  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.

I'll note I've built systems that simply handle in-phone conferencing; 
while there are some annoyances it's most certainly doable.  If the 
caller acts as the MCU you get OWD1+jitter+etc+encode+OWD2 
(OWD=one-way-delay) between the two leaf nodes (though this is no 
different than a normal conference).  Or your app, after the initial 
second answer tells the second answerer to invite the first into a mesh 
conference, if that works - and it may not, so you need to mix or 
forward if you want a conference.   (Forwarding the RTP traffic works at 
the cost of bandwidth and complexity, but simpler media processing and 
less leaf-to-leaf delay.)

If this *is* already a mesh conference you've joined (different usecase 
than above), no mixing or forwarding is needed - you render all the 
streams, and you send media to all the answerers.  This is exactly what 
you want.

However, if two people answer, you do not have to have a conference.  
First of all, the devices rtcweb is intended for generally have enough 
UI available that the user can manage multiple sessions reasonably, 
unlike POTS-type phones.  You can handle it much like a call-waiting 
scenario, though the second answerer might be confused unless you send 
some sort of hold/please-wait message (which, this not being POTS 
devices, you can).

In other cases/applications, the answers may be automated, and the 
channels may not be used immediately - think the VR example, where your 
OFFER is forwarded to any person who comes in "hearing" range, enters 
the room, whatever.  This may be a form of partial-mesh conference 
managed by the server.  These channels may be opened before they're 
actually needed in order to hide setup delay.

My point is to show that the possible uses of parallel forking exist, 
and don't always map to SIP or to classic telephony.  If cloning is 
supported, then these scenarios work.

I'm open to alternative proposals that cover this class of use-cases, if 
they make either "standard" apps simpler to a worthwhile degree, or if 
they make the implementation of webrtc itself noticably simpler, while 
still making these uses possible.  Alternatives may have downsides in 
some cases, in extra call setup delay/clipping or requiring re-invites 
or requiring special application protocols to request a offerer send a 
new invite, and added complexity to apps that wish to handle this.

-- 
Randell Jesup
[e-mail]