Subject: Re: [MMUSIC] ICE updated offer

From: Roman Shpount <[email-masked]>
Date: Tue, 14 Oct 2014 15:16:42 -0400

Would the better solution for this entire problem be a SIP option that
allows to suppress ICE restart on new empty re-invite? If both sides
support this option (via the Supported header), then new offer is not sent
in the end of the ICE process. If remote party needs it, then it can do an
empty SIP re-INVITE with this flag set. If intermediary does not support
this, they can remove the option from the Supported header in any direction
and this will cause a new offer-answer transaction per old RFC.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Oct 2014 06:55:53 +0000

Hi,

To base solutions on the sending of empty re-INVITEs is in my opinion not a very good idea. Also, it makes things tricky for intermediaries that need the information. In order for them to trigger re-INVITEs they have to be B2BUA, and that will then cause other problems.

What I suggest has very little impact on ICE as defined today. It only adds some kind of indicator (ice-options attribute value?) whether the second offer is needed or not. Simple :)

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 14 October 2014 22:17
To: [email-masked]
Subject: Re: [MMUSIC] ICE updated offer

Would the better solution for this entire problem be a SIP option that allows to suppress ICE restart on new empty re-invite? If both sides support this option (via the Supported header), then new offer is not sent in the end of the ICE process. If remote party needs it, then it can do an empty SIP re-INVITE with this flag set. If intermediary does not support this, they can remove the option from the Supported header in any direction and this will cause a new offer-answer transaction per old RFC.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Oct 2014 12:18:01 +0200

2014-10-15 8:55 GMT+02:00 Christer Holmberg <[email-masked]>:
> What I suggest has very little impact on ICE as defined today. It only adds
> some kind of indicator (ice-options attribute value?) whether the second
> offer is needed or not. Simple :)

And in case the SDP says that the "second offer" is required, then
what? I mean, should the browser do samething (I mean natively)? or is
it just up to the JS application?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 Oct 2014 12:26:06 +0200

I really don't think browsers have anything to do with this. It is purely a
matter of signalling. Nothing needs to be changed for webrtc one way or
another.

--sent from my mobile
On 15 Oct 2014 12:18 PM, "Iñaki Baz Castillo" <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Oct 2014 10:27:52 +0000

Hi,

>> What I suggest has very little impact on ICE as defined today. It only 
>> adds some kind of indicator (ice-options attribute value?) whether the 
>> second offer is needed or not. Simple :)
>
> And in case the SDP says that the "second offer" is required, then what? I mean, should the browser do samething (I mean natively)? or is it just up to the JS application?

Personally I don't care - as long as there is an updated offer, with the proper information, coming out on the wire.

Obviously, if it's up to the JS application, it needs to know when the candidates have been selected, in order to create and send the second offer.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Oct 2014 10:29:41 +0000

Hi,

>I really don't think browsers have anything to do with this. It is purely a matter of signalling. Nothing needs to be changed for webrtc one way or another.

Correct. It is about what an entity has to signal in order to be ICE compliant. HOW it’s done and managed internally within the client is irrelevant – at least as far as the ICE standard is concerned.

Regards,

Christer

On 15 Oct 2014 12:18 PM, "Iñaki Baz Castillo" <[email-masked]<mailto:[email-masked]>> wrote:

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Oct 2014 12:35:22 +0200

2014-10-15 12:29 GMT+02:00 Christer Holmberg <[email-masked]>:
> Correct. It is about what an entity has to signal in order to be ICE
> compliant. HOW it’s done and managed internally within the client is
> irrelevant – at least as far as the ICE standard is concerned.

It would be easy if the iceconnectionstatechange() event would provide
info about the paired/connected candidate pair. Unfortunately it is a
vague event which provides nothing but just "some of the transports in
your PeerConnection has connected, but I won't tell you which one".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 15 Oct 2014 13:48:32 +0000

I really don't think browsers have anything to do with this. It is purely a matter of signalling. Nothing needs to be changed for webrtc one way or another. 
[TS] I agree. ICE updated offer was introduced to accommodate certain SIP middleboxes. Its relevance outside of SIP is at least debatable.

--sent from my mobile

--
Iñaki Baz Castillo
<[email-masked]>

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 15 Oct 2014 22:06:37 +0530

Hi Thomas,

I'm not seeing that the second offer is relevant only to SIP. Even in case WebRTC entity with (proprietary) signaling & media in the separate device, WebRTC signaling entity will not aware of the actual media IP, port & transport.

Thanks
Partha

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Stach,
> Thomas
> Sent: Wednesday, October 15, 2014 7:19 PM
> To: Emil Ivov; Iñaki Baz Castillo
> Cc: [email-masked]; Roman Shpount; Christer Holmberg
> I really don't think browsers have anything to do with this. It is
> purely a matter of signalling. Nothing needs to be changed for webrtc
> one way or another.
> [TS] I agree. ICE updated offer was introduced to accommodate certain
> SIP middleboxes. Its relevance outside of SIP is at least debatable.
> 
> --sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 Oct 2014 18:39:32 +0200

> I'm not seeing that the second offer is relevant only to SIP. Even in case WebRTC entity with (proprietary) signaling & media in the separate device, WebRTC signaling entity will not aware of the a…

That's not an ICE problem though. It's a WebRTC API problem though and 
trying to solve it by triggering new SDPs would be quite daft really.

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Oct 2014 18:39:25 +0200

2014-10-15 18:36 GMT+02:00 Parthasarathi R <[email-masked]>:
> in case WebRTC entity with (proprietary) signaling & media in the separate device, WebRTC signaling entity will not aware of the actual media IP, port & transport.

If somebody builds a WebRTC entity/endpoint/whatever in which the
signaling "entity" and the media "entity" are not
inter-communicated... then indeed that is a big problem. A big
*design* problem. Just fix it.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 16 Oct 2014 06:17:36 +0000

> 
> Hi Thomas,
> 
> I'm not seeing that the second offer is relevant only to SIP. 
[TS] That is not what I said.
For background on my original statement you may want to refer to
http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01#section-5.4.2 

> Even in case
> WebRTC entity with (proprietary) signaling & media in the separate device,
> WebRTC signaling entity will not aware of the actual media IP, port &
> transport.
> 
> Thanks
> Partha
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Oct 2014 06:23:27 +0000

Hi,

> If somebody builds a WebRTC entity/endpoint/whatever in which the signaling "entity" and the media "entity" are not inter-communicated... then indeed that is a big problem. A big

Obviously the signaling entity needs to be able to control the media entity. If that control is based on the SDP information, that SDP information needs to be correct.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 16 Oct 2014 07:20:14 +0000

> 
> Hi,
> 
> >> in case WebRTC entity with (proprietary) signaling & media in the
> separate device, WebRTC signaling entity will not aware of the actual media
> IP, port & transport.	
> >
> signaling "entity" and the media "entity" are not inter-communicated...
> then indeed that is a big problem. A big
> Obviously the signaling entity needs to be able to control the media
> entity. If that control is based on the SDP information, that SDP
> information needs to be correct.
[TS] The SDP information is correct and it provides everything that the media entity needs (via the candidates).
Since all connectivity checks follow the media path the media entity is also able to learn the eventually used media IP, port & transport.
I agree it is "just" a design problem.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Oct 2014 07:36:33 +0000

Hi,

> Since all connectivity checks follow the media path the media entity is also able to learn the eventually used media IP, port & transport.

That is not how many current deployments work today, and I don't think we should mess those up by fixing something that isn't broken (not sending the second offer is just an optimization).

The request for not sending the second offer came mainly from the WebRTC community. And, as we have noted, the sending of the second offer can be taken of by the JS app, so it doesn't affect the WebRTC API etc.

Now, as I said earlier, the JS app would have to know when the candidates have been selected. BUT, I think that information could be useful to the JS app for other reasons than ICE too.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 16 Oct 2014 10:13:45 +0200

> Obviously the signaling entity needs to be able to control the media entity. If that control is based on the SDP information, that SDP information needs to be correct.

I hope the media entity is able to notify its signaling entity about
the selected candidate pair.

Does your signaling entity trust the remote peer more than its own media entity?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 16 Oct 2014 10:18:14 +0200

> Now, as I said earlier, the JS app would have to know when the candidates have been selected. BUT, I think that information could be useful to the JS app for other reasons than ICE too.

That's impossible with the current API as it is not "transport"-based
but "all-stuff-together"-based, which means that the JS application
has no way to know the number of transports being negotiated, and
hence an API to provide paired candidates is of little use within
WebRTC 1.0.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 16 Oct 2014 09:00:14 +0000

> From: mmusic [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Thursday, October 16, 2014 1:07 PM
> To: Stach, Thomas; Iñaki Baz Castillo; Parthasarathi R
> Cc: [email-masked]; Roman Shpount
> > Since all connectivity checks follow the media path the media entity is also
> able to learn the eventually used media IP, port & transport.
> 
> That is not how many current deployments work today, and I don't think we
> should mess those up by fixing something that isn't broken (not sending the
> second offer is just an optimization).
> 
> The request for not sending the second offer came mainly from the WebRTC
> community. And, as we have noted, the sending of the second offer can be
> taken of by the JS app, so it doesn't affect the WebRTC API etc.
> 
> Now, as I said earlier, the JS app would have to know when the candidates
> have been selected. BUT, I think that information could be useful to the JS
> app for other reasons than ICE too.

Yup, the other use case is that WebRTC/SIP server uses the selected candidates to communicate with the SDN controller to program on-path network devices to prioritize the media streams.

-Tiru

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Oct 2014 09:01:15 +0000

Hi,

>That's impossible with the current API as it is not "transport"-based but "all-stuff-together"-based, which means that the JS application has no way to know the number of transports being negotiated, and hence an API to provide paired candidates is of little use within WebRTC 1.0.

All I need to know is the local address:port that has been selected, and based on that I can create and send the updated offer.

Keep in mind that BUNDLE also mandates a second offer (the BAS offer), so you'd need this even if you don't need to send a second offer due to ICE.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 16 Oct 2014 11:09:16 +0200

> All I need to know is the local address:port that has been selected, and based on that I can create and send the updated offer.

Your browser may support Bundle but the peer may not. If so, your
PeerConnection will establish two (or more) ICE transports thus you
need to know the local address:port for each transport (but at the
same time you never knew the number of transports in place so...).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 16 Oct 2014 09:23:14 +0000

> 
> Keep in mind that BUNDLE also mandates a second offer (the BAS offer), so
> you'd need this even if you don't need to send a second offer due to ICE.
[TS] BAS is based on the same arguments as for the ICE updated offer.
As this will cause similar, if not the same issues, I'd rather handle both in the same way.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Oct 2014 09:24:37 +0000

Even if me would make the BAS optional, one still needs to be able to properly create it.

-----Original Message-----
From: Stach, Thomas [mailto:[email-masked]] 
Sent: 16. lokakuuta 2014 12:23
To: Christer Holmberg; Iñaki Baz Castillo
Cc: Parthasarathi R; Emil Ivov; [email-masked]; Roman Shpount
Subject: RE: [MMUSIC] ICE updated offer

> 
> Keep in mind that BUNDLE also mandates a second offer (the BAS offer), 
> so you'd need this even if you don't need to send a second offer due to ICE.

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 17 Oct 2014 04:33:52 +0530

Hi Thomas,

I understand your original statement now. Hope you understand that the second offer is required to all signaling entity which is controlling the separate media entity irrespective the protocol (SIP/WebRTC/...) used. 

Thanks
Partha

> Sent: Thursday, October 16, 2014 11:48 AM
> To: Parthasarathi R; 'Emil Ivov'; 'Iñaki Baz Castillo'
> Cc: [email-masked]; 'Roman Shpount'; 'Christer Holmberg'

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 17 Oct 2014 04:54:24 +0530

Hi Tiru & all,

<snip>
Yup, the other use case is that WebRTC/SIP server uses the selected
candidates to communicate with the SDN controller to program on-path network
devices to prioritize the media streams.
</snip>

It is yet another good usecase for the updated offer requirement. 

Thanks
Partha

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Thursday, October 16, 2014 2:30 PM
> To: Christer Holmberg; Stach, Thomas; Iñaki Baz Castillo; Parthasarathi
> R
> > > [TS] The SDP information is correct and it provides everything that
> the
> > media entity needs (via the candidates).
> Yup, the other use case is that WebRTC/SIP server uses the selected
> candidates to communicate with the SDN controller to program on-path
> network devices to prioritize the media streams.
> 
> -Tiru
> 
> >
> > Regards,
> >
> > Christer

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 17 Oct 2014 05:07:35 +0530

Hi Emil,

It is ICE problem w.r.t signaling exchange. In case of normal RTP, SDP m line port & c line IP will mention where the media flow occur to the signaling device. In case of SDP with ICE candidate initial offer, it is not clear where RTP flow occurs.

As per the current discussion, there are two well known issues in case second offer is missing:

1) Separate Signaling device will not be able to properly maintain the media resource and policy 
2) On-path network device will not be able to programmed for the given media flow by WebRTC/SIP server

Thanks
Partha

> From: Emil Ivov [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2014 10:10 PM
> To: Parthasarathi R; 'Stach, Thomas'; 'Iñaki Baz Castillo'
> > I'm not seeing that the second offer is relevant only to SIP. Even in
> case WebRTC entity with (proprietary) signaling & media in the separate
> device, WebRTC signaling entity will not aware of the actual media IP,
> port & transport.
>