Re: [rtcweb] Question about JSEP createOffer

[Justin Uberti <[e-mail]>]

On Thu, May 10, 2012 at 4:10 AM, Ravindran, Parthasarathi <
[e-mail]> wrote:

>  Justin,****
>
> ** **
>
> The new media type/codec change by the answerer requires the complete set
> of codec from offerer. It is not appropriate to remember the previously
> offered codec & capabilities as it is subject to vary in the mid-session.
> For example, it is possible for the offerer to remove webcam in the middle
> of the audio session wherein answerer should not expect that video is
> supported by offerer as it was offered initially.****
>
> ** **
>
> Please read inline for more comments.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Justin Uberti [mailto:[e-mail]]
> *Sent:* Thursday, May 10, 2012 8:32 AM
> *To:* Ravindran, Parthasarathi
> *Cc:* Roman Shpount; [e-mail]
>
> *Subject:* Re: [rtcweb] Question about JSEP createOffer****
>
>  ** **
>
> ** **
>
> On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi <
> [e-mail]> wrote:****
>
> I agree with Richard & Roman. “Full” re-OFFER MUST supported required for
> couple of mid session scenario like ****
>
>  ****
>
> 1)      The session is established with audio and then video shall be
> added in the middle in case complete offer is provided in re-OFFER.****
>
> You don't need a complete offer here, just a "full" offer for the video m=
> section. This should already work today. ****
>
> <partha>  IIUC for audio session, each time re-offer MUST contain “full”
> offer for video section </partha>
>

If you have an audio session, and you add video, the offer to add video
will include a "full" offer for video. But changes just to the audio
session itself will obviously not include anything about video. Maybe I
don't understand what you are suggesting.

> ****
>
>  2)       It is possible to change the codec in the middle of the Session
> as Roman mentioned.****
>
>  This also doesn't require a complete offer. The application would need
> to remember what codecs are available so that it could change the offered
> codec to something other than what it is currently using, but it would not
> need to resend all codecs. ****
>
> <partha> Your proposal is limiting as the answerer has no choice to the
> select the preferred codec </partha>
>

I thought the offerer wanted to change the codec. Why would the answerer
need to make a selection? If the 'answerer' wants to use a different codec,
it should make an offer of its own.

****
>
> ** **
>
> I agree Roman's case of a B2BUA seems like it would need a full offer,
> although the idea of connecting an existing call to a new destination seems
> like an uncommon case; the application could simply start a new call (i.e.
> create a new PeerConnection), right?****
>
> ** **
>
> If we decide we need to support this, the simplest way of handling this
> would be to simply extend the |hints| parameter in createOffer to have some
> sort of "complete" flag.****
>
> <partha> your API proposal looks good  as it is possible to re-use the
> existing or offer full based on the application needs. But the application
> developer  MUST aware of the implication as it calls for interop issue in
> case of federation scenario if the full offer is not sent across. </partha>
>

The application developer only needs to do this if supporting these edge
cases is relevant to their application.

> ****
>
>  ****
>
>   ****
>
>  ****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *Roman Shpount
> *Sent:* Tuesday, May 08, 2012 9:03 PM
> *To:* Justin Uberti
> *Cc:* [e-mail]
> *Subject:* Re: [rtcweb] Question about JSEP createOffer****
>
>  ****
>
>
> ****
>
> On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <[e-mail]> wrote:
> ****
>
> Richard,****
>
>  ****
>
> That is an interesting point. Could you give a short example of when such
> a "full" re-OFFER would be used? There are a few ways we could handle this
> case.****
>
>  ****
>
>
> Actually I was the person who argued that "full" capabilities should be
> present in original SIP O/A, when new offer is generated in an existing
> session. The use case for this are B2BUA that connect an existing session
> to a new call or another existing session. Typically, B2BUA would ask one
> of the call parties for the offer (send an INVITE with no body in SIP), get
> the new offer, and send this offer to the newly placed call. In order for
> this to work, all the calling party capabilities should be listed in this
> new offer, in particular all the codecs and all the communications types
> (audio, video, text, etc), or call would not be successfully established.
> _____________
> Roman Shpount****
>
>  ** **
>