Re: [rtcweb] Minimal SDP negotiation mechanism

[Roman Shpount <[e-mail]>]

There are actually three related issues here:

1. As mentioned earlier, a single offer in SIP can create multiple dialogs
with independent answers. Each dialog is independent from each other and it
is up to end user device to choose how to render it (mix audio, play the
audio from the latest, display multiple videos side by side). These dialogs
can be early (created by a provisional response) or final (created by a
success response), but this distinction typically does not affect the media
plane. There are a number of common use cases for forking with multiple
answers such as service announcements (play some announcement from a media
server using an early dialog then start playing audio from the call using
another dialog), color ring back (play custom music while dialing the user),
find me/follow me (where call can be answered by the desk and cell phone
creating two final dialogs). One of the biggest design issues with such
multiple answer fork scenarios is that there is no way to map received media
to the actual answer, since there is nothing in the answer SDP which
identifies the response RTP stream.

2. The second scenario is non-standard, but very widely used -- in the same
dialog, different responses are send in the provisional and final SIP
responses. This is usually a result of forking being masked by a B2BUA or
SBC. Even though this is non-standard this is usually trivial to implement,
since all that needs to be done is to reinitialize the media stream based on
the new answer.

3. Even when multiple answers are not used, multiple different media streams
can be sent based on the offer. First of all, it is common to receive media
before the signaling response is received. Second, standard requires that
offerer should be ready to receive media once the offer is sent and there is
nothing that prevents multiple media streams from being sent to it.
Furthermore, multiple answers only define what media and where should be
sent to the answerer, but in no way specifies how many remote parties, from
which addresses, and what type of media will send the media to the offerer.
New media streams with new SSRC from new addresses with new media types
present in the offer can be added at any time without the offer/answer
exchange. Typically this is supported in such a way that only the newest
media stream, after probation interval, is played and older media streams
are ignored, but other more robust solutions are possible.

If we plan to interop with existing VoIP solutions, we will need to support
1 and 2, as well as define the expected behavior for 3.
_____________
Roman Shpount


On Tue, Sep 20, 2011 at 9:40 AM, Olle E. Johansson <[e-mail]> wrote:

>
> 20 sep 2011 kl. 15:15 skrev Christer Holmberg:
>
> >
> > Hi,
> >
> >>> Once we start requiring that the PeerConnection know the
> >>> difference between "early" media and "late" media, it seems
> >>> to me we're slipping down a slippery slope.
> >>
> >> The difference between early and late media is purely a
> >> billing decision in PSTN. I don't think we should separate
> >> these on the rtcweb side. It's a PSTN gateway issue, not
> >> something to be bothered with in rtcweb.
> >
> > It's not about knowing the difference between "early" and "late" media -
> it's about whether the API and browser need to support multiple SIMULTANOUS
> SDP answers - or whether we assume that the JS SIP app will always, at any
> given time, only provide ONE SDP answer to the API and browser.
>
> I just wanted to get rid of the early/late media discussion. As you state,
> the forking issue with getting multiple responses is a separate issue.
>
> Do we have any use cases using forking? Is forking a desired feature or
> something that SIP brought in?
>
> To give an example to those of you with no SIP history:
>
> In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from
> different devices. This means that you actually have multiple calls and need
> to hang up all of those that you do not want, or just mix them somehow and
> live with it.
>
> With early media, it gets even more confusing, because you will get an SDP
> answer before the call is in up state (in 180/183 response) then another SDP
> answer from another device at 200 OK. In this case you have an early dialog
> with early media with the device sending the first answer, a dialog that
> terminates at 200 OK.
>
> Supporting this behaviour adds complexity. And not all SIP devices support
> these situations properly, as we've proven at SIPit testing.
>
> Which leads to an unshameful plug: SIPit in Monaco is now open for
> registration - for all SIP developers to attend :-)
>
> /O
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>