Re: [rtcweb] Question about JSEP createOffer

["Ravindran, Parthasarathi" <[e-mail]>]

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]<mailto:[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>

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] Question about JSEP createOffer


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