Re: [rtcweb] Agenda requests for Atlanta meeting

[Roman Shpount <[e-mail]>]

On Mon, Oct 8, 2012 at 9:41 PM, Cullen Jennings <[e-mail]> wrote:

>
> On Oct 8, 2012, at 18:31 , Roman Shpount <[e-mail]> wrote:
>
> > On Mon, Oct 8, 2012 at 9:26 PM, Cullen Jennings (fluffy) <
> [e-mail]> wrote:
> >
> > Well, what's the end user experience you're trying to achieve  - lets
> say we are talking about audio. Do you want to play the first one or the
> last one? If you want to bridge them into a party line, this is probably
> not how you want the SIP side to happen.
> >
> >
> > This is still serial forking. Imagine the following scenario: You are
> calling a phone number, you dial first provider who starts playing a dial
> tone then uses an UPDATE to connect you to a media server to play an
> announcement after which your call goes to voice mail (another dialog and
> another SDP). This is all fairly legal and not unusual for SIP scenarios.
> Nothing to do with party lines.
>
> Ok, serial forking with early media seems like it should work. Seems like
> the browser would make the offer, that gateway turned into SIP invite that
> then went to sequential forking proxy that send sent the invite to UA A. UA
> A returns a 180 that gets mapped to PRANSWER, the proxy then forks to UA B
> that sends a 200 on a different dialog that gets mapped to answer.


 The only issue is the there is currently no way to map an UPDATE received
in the early dialog to WebRTC API calls. I am probably OK with it not being
handled until the cloning is implemented, but this shows that PRANSWER is
not very useful even for the serial forking.
_____________
Roman Shpount