Re: [rtcweb] Minimal SDP negotiation mechanism

["Olle E. Johansson" <[e-mail]>]

20 sep 2011 kl. 16:53 skrev Roman Shpount:

> 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.

Agree. I think that would be bad. What do you think?

/O
> _____________
> 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
> 

---
* Olle E Johansson - [e-mail]
* Cell phone [phone], Office [phone], Sweden