Subject: [rtcweb] Question about JSEP createOffer

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 6 May 2012 13:40:31 -0500

I have a question about something I came across in the JSEP draft.

6.1.2 of JSEP draft 0 has the following text regarding "createOffer":

   As an offer, the generated SDP will contain the full set of

   capabilities supported by the session (as opposed to an answer, which

   will include only a specific negotiated subset to use); for each SDP

   line, the generation of the SDP must follow the appropriate process

   for generating an offer. In the event createOffer is called after the

   session is established, createOffer will generate an offer that is

   compatible with the current session, incorporating any changes that

   have been made to the session since the last complete offer-answer

   exchange, such as addition or removal of streams. If no changes have

   been made, the offer will be identical to the current local

   description.

The first and last sentences might conflict if the SDP Answerer later wants to create a new Offer.  The local configuration based on the first offer/answer will contain only the selected media configuration, whereas it is desirable for the new Offer to contain the full set of capabilities of the (new) Offerer.  I think this text needs to change to reflect this case.  Am I missing something?

Richard

---

From: Justin Uberti <[email-masked]>
Date: Tue, 8 May 2012 10:46:32 -0400

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.

On Sun, May 6, 2012 at 2:40 PM, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

>  I have a question about something I came across in the JSEP draft.****
>
> ** **
>
> 6.1.2 of JSEP draft 0 has the following text regarding “createOffer”:****
>
> ** **
>
>    As an offer, the generated SDP will contain the full set of****
>
>    capabilities supported by the session (as opposed to an answer, which**
> **
>
>    will include only a specific negotiated subset to use); for each SDP***
> *
>
>    line, the generation of the SDP must follow the appropriate process****
>
>    for generating an offer. In the event createOffer is called after the**
> **
>
>    session is established, createOffer will generate an offer that is****
>
>    compatible with the current session, incorporating any changes that****
>
>    have been made to the session since the last complete offer-answer****
>
>    exchange, such as addition or removal of streams. If no changes have***
> *
>
>    been made, the offer will be identical to the current local****
>
>    description.****
>
> ** **
>
> The first and last sentences might conflict if the SDP Answerer later
> wants to create a new Offer.  The local configuration based on the first
> offer/answer will contain only the selected media configuration, whereas it
> is desirable for the new Offer to contain the full set of capabilities of
> the (new) Offerer.  I think this text needs to change to reflect this case.
>  Am I missing something?****
>
> ** **
>
> Richard****
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 May 2012 11:33:10 -0400

On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <[email-masked]> 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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 9 May 2012 06:24:59 +0000

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.

2)       It is possible to change the codec in the middle of the Session as Roman mentioned.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Cc: [email-masked]
Subject: Re: [rtcweb] Question about JSEP createOffer

On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <[email-masked]<mailto:[email-masked]>> 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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 9 May 2012 23:02:16 -0400

On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi <
[email-masked]> 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.

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

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.

> ****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Roman Shpount
> *Sent:* Tuesday, May 08, 2012 9:03 PM
> *To:* Justin Uberti
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] Question about JSEP createOffer****
>
> ** **
>
>
> ****
>
> ****
> Richard,****
> case.****
> Roman Shpount****

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 10 May 2012 08:10:58 +0000

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:[email-masked]]
Sent: Thursday, May 10, 2012 8:32 AM
To: Ravindran, Parthasarathi
Cc: Roman Shpount; [email-masked]
Subject: Re: [rtcweb] Question about JSEP createOffer

On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> 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>

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Question about JSEP createOffer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 10 May 2012 09:48:37 -0400

On Thu, May 10, 2012 at 4:10 AM, Ravindran, Parthasarathi <
[email-masked]> 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:[email-masked]]
> *Sent:* Thursday, May 10, 2012 8:32 AM
> *To:* Ravindran, Parthasarathi
> *Cc:* Roman Shpount; [email-masked]
>
> [email-masked]> 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.****
>
> section. This should already work today. ****
>

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
> need to resend all codecs. ****
>

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.

****
> create a new PeerConnection), right?****
>
> ** **
>
> 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: Roman Shpount <[email-masked]>
Date: Thu, 10 May 2012 12:53:58 -0400

> cases is relevant to their application.
If you inter-operate with anything SIP, you need to do a full new offer
every time you get a re-INVITE without a body. The reason for this is you
are working with an external system. Thus you cannot guess if this
re-INVITE was generated by an existing call or some sort of third party
call control application which will need a full offer. This is not
something that is specific to SIP only. Every time you will implement any
type of interconnect between disjoint systems you will deal with a similar
problem.
_____________
Roman Shpount