Subject: [MMUSIC] Trickle ICE for SIP Questions

From: Emil Ivov <[email-masked]>
Date: Wed, 03 Jul 2013 16:13:26 +0200

Hey all,

Christer, Enrico and I are preparing the next version of Trickle ICE for 
SIP. Now that discussions on BUNDLE and the plans seem to be winding 
down, we wanted to run a few questions by the working group.

Q1: Making reliable provisional responses and PRACK mandatory. Obviously 
this would be nice to avoid, so the question is: is there a reasonable 
mechanism to achieve this (and by reasonable, we mean something that 
wouldn't be harder than implementing support for PRACK).

There was some discussion about this back in April and there was a 
suggestion for implementing a 5245-style hack where the answerer 
basically resends the 180 until it knows that it has been received.

5245 uses connectivity checks for this (i.e. it stops 180 
retransmissions when the first connectivity check is received) but we 
don't have that option here since the 180 may contain either none or 
only host candidates so there are strong chances that no binding request 
would be received on them.

Thomas also suggested a second option which would be to also use INFO 
requests with trickled candidates as an indication that 180 was 
received. This however wouldn't work with half trickle so we are 
basically back to vanilla ICE for all (non-re) INVITEs.

Another option would be to mandate an INFO request with 
"end-of-candidates" in response to the 180, but that would be just the 
same as mandating PRACK support.

Thomas also suggested that the answerer can start sending INFOs right 
after it sends its answer in the 180 and then it can just resend the 180 
if the INFOs result in a 481 response.

Personally I think this could potentially be made to work, but it would 
imply a level of complexity that considerably exceeds PRACK support.

Opinions?

Q2: How do we send INFOs? Are they blocking or do we just send them in 
parallel? If the latter, then what happens when an INFO fails because it 
is received out of order? Do we just tell the application to resend the 
candidates asap?

This also leads to the following question:

Q3: What exactly do we send in INFOs? Just the latest batch of freshly 
learned candidates or all candidates we've learned so far? Dale 
suggested that if we do this cumulatively we wouldn't need to worry 
about the case with the out-of-order INFOs from Q2 since the information 
gets resent anyway. A drawback here would obviously be that this adds 
more complexity for trickle ICE users (WebRTC applications specifically)

A third option would be to allow both and leave it to the application.

Comments are most welcome!

Emil

-- 
https://jitsi.org

---

From: Dan Wing <[email-masked]>
Date: Wed, 3 Jul 2013 12:01:46 -0700

On Jul 3, 2013, at 7:13 AM, Emil Ivov <[email-masked]> wrote:

> Hey all,
> 
> Christer, Enrico and I are preparing the next version of Trickle ICE for SIP. Now that discussions on BUNDLE and the plans seem to be winding down, we wanted to run a few questions by the working group.
> 
> Q1: Making reliable provisional responses and PRACK mandatory. Obviously this would be nice to avoid, so the question is: is there a reasonable mechanism to achieve this (and by reasonable, we mean something that wouldn't be harder than implementing support for PRACK).
> 
> There was some discussion about this back in April and there was a suggestion for implementing a 5245-style hack where the answerer basically resends the 180 until it knows that it has been received.
> 
> 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions when the first connectivity check is received) but we don't have that option here since the 180 may contain either none or only host candidates so there are strong chances that no binding request would be received on them.

I might work, because each re-transmission would probably have additional candidates (because the STUN/TURN transactions will have completed), and thus more likely that those re-transmissions (containing those additional candidates) would result in the remote endpoint sending a STUN binding request.

-d

> Thomas also suggested a second option which would be to also use INFO requests with trickled candidates as an indication that 180 was received. This however wouldn't work with half trickle so we are basically back to vanilla ICE for all (non-re) INVITEs.
> 
> Another option would be to mandate an INFO request with "end-of-candidates" in response to the 180, but that would be just the same as mandating PRACK support.
> 
> Thomas also suggested that the answerer can start sending INFOs right after it sends its answer in the 180 and then it can just resend the 180 if the INFOs result in a 481 response.
> 
> Personally I think this could potentially be made to work, but it would imply a level of complexity that considerably exceeds PRACK support.
> 
> Opinions?
> 
> Q2: How do we send INFOs? Are they blocking or do we just send them in parallel? If the latter, then what happens when an INFO fails because it is received out of order? Do we just tell the application to resend the candidates asap?
> 
> Q3: What exactly do we send in INFOs? Just the latest batch of freshly learned candidates or all candidates we've learned so far? Dale suggested that if we do this cumulatively we wouldn't need to worry about the case with the out-of-order INFOs from Q2 since the information gets resent anyway. A drawback here would obviously be that this adds more complexity for trickle ICE users (WebRTC applications specifically)
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Wed, 03 Jul 2013 21:29:18 +0200

Hey Dan,

On 03.07.13, 21:01, Dan Wing wrote:
>> Christer, Enrico and I are preparing the next version of Trickle
>> ICE for SIP. Now that discussions on BUNDLE and the plans seem to
>> be winding down, we wanted to run a few questions by the working
>> group.
>>
>> Q1: Making reliable provisional responses and PRACK mandatory.
>> Obviously this would be nice to avoid, so the question is: is there
>> a reasonable mechanism to achieve this (and by reasonable, we mean
>> something that wouldn't be harder than implementing support for
>> PRACK).
>>
>> retransmissions when the first connectivity check is received) but
>> we don't have that option here since the 180 may contain either
>> none or only host candidates so there are strong chances that no
>> binding request would be received on them.
>
> I might work, because each re-transmission would probably have
> additional candidates (because the STUN/TURN transactions will have
> completed), and thus more likely that those re-transmissions
> (containing those additional candidates) would result in the remote
> endpoint sending a STUN binding request.

If we do it cumulatively, then yes. We can then move to INFOs the moment 
we get either a first check (which would more often be the case with 
half trickle) or a first INFO request (which would be the case for full 
trickle).

This could indeed work. However it would also imply that we keep sending 
candidates cumulatively even in the INFO requests since we wouldn't know 
how many of the 180s got through.

This makes me slightly uncomfortable as it would imply that someone 
would have to maintain state on the sending side, and do a number of 
comparisons on the receiving side ...

Emil

--
https://jitsi.org

>> Thomas also suggested a second option which would be to also use
>> INFO requests with trickled candidates as an indication that 180
>> was received. This however wouldn't work with half trickle so we
>> are basically back to vanilla ICE for all (non-re) INVITEs.
>>
>> "end-of-candidates" in response to the 180, but that would be just
>> the same as mandating PRACK support.
>>
>> Thomas also suggested that the answerer can start sending INFOs
>> right after it sends its answer in the 180 and then it can just
>> resend the 180 if the INFOs result in a 481 response.
>>
>> Personally I think this could potentially be made to work, but it
>> would imply a level of complexity that considerably exceeds PRACK
>> support.
>>
>> Opinions?
>>
>> Q2: How do we send INFOs? Are they blocking or do we just send them
>> in parallel? If the latter, then what happens when an INFO fails
>> because it is received out of order? Do we just tell the
>> application to resend the candidates asap?
>>
>> Q3: What exactly do we send in INFOs? Just the latest batch of
>> freshly learned candidates or all candidates we've learned so far?
>> Dale suggested that if we do this cumulatively we wouldn't need to
>> worry about the case with the out-of-order INFOs from Q2 since the
>> information gets resent anyway. A drawback here would obviously be
>> that this adds more complexity for trickle ICE users (WebRTC
>> applications specifically)
>>

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 4 Jul 2013 13:15:04 +0000

Emil,
inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Emil Ivov
> Sent: Wednesday, 03 July, 2013 16:13
> To: MMUSIC IETF WG
> Subject: [MMUSIC] Trickle ICE for SIP Questions
> 
> Hey all,
> 
> Obviously
[TS] I'm not convinced about the different level of complexity. 
If you use PRACK you have SIP timer T1 running and would re-transmit the 180 in case that the PRACK is not received. 
Assuming that you want to wait with sending of the INFO until you saw the PRACK, would lead to delay in that case.
If you don't wait you would also have to treat a 481 response to the INFO.
... and you would detect quicker that the 180 was lost than by waiting for the PRACK.

BTW: 5245 recommends to use PRACK. However it does not mandate it, but gives the alternative procedures as an option.
You could do the same here.

> is received out of order? Do we just tell the application to resend the
[TS] I would go with the proposal below and send cumulatively. You also have the CSeq: header field to detect late arrivals.

> more complexity for trickle ICE users (WebRTC applications
[TS] Again I'm not convinced about the complexity. Both peer know their candidates, what is the issue in putting all of them into the INFO?
> A third option would be to allow both and leave it to the application.
[TS] This now adds complexity. ;-) I would just always send all candidates.
Regards
Thomas

---

From: Emil Ivov <[email-masked]>
Date: Fri, 05 Jul 2013 16:12:38 +0200

Hey Thomas

> If you use PRACK you have SIP timer T1 running and would re-transmit the 180 in case that the PRACK is not received.

Right.

> Assuming that you want to wait with sending of the INFO until you saw the PRACK, would lead to delay in that case.

True. Is this the only problem that we are trying to optimize? Save half 
an RTT? (This is a really a question. I am not trying to make a point. I 
am simply trying to understand why PRACK is an issue.)

> If you don't wait you would also have to treat a 481 response to the INFO.

I am always a bit nervous when it comes to interpreting error responses. 
We are indeed likely to get a 481 when sending INFOs and the 180 hasn't 
yet made it to the remote side. However 481 might also imply that our 
dialog is simply dead for some reason and in this case 3261 says:

   If the response for a request within a dialog is a 481
   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
   SHOULD terminate the dialog.

> ... and you would detect quicker that the 180 was lost than by waiting for the PRACK.

As said above: a lost 180 is not the only possible cause for a 408 in 
this case.

> You could do the same here.

Of course. I should have made that clearer: all alternative approaches 
were meant as something we could have in addition to the PRACK one.

Also, keep in mind that the 180 carries an entire SDP answer. If INFOs 
are competing with 180s then they may potentially need to carry that too 
(or at least the ICE parts) and it would be good if we don't have to 
open that can of worms.

> [TS] Again I'm not convinced about the complexity. Both peer know their candidates, what is the issue in putting all of them into the INFO?

I am not sure how current WebRTC stacks handle provisioning of repeating 
candidates. If they don't then it would be up to the receiving JS app, 
to sort our which are the new candidates and which were already there.

The sending side would be similarly tricky for a JS app: it would need 
to construct SDP so that the a=candidate attributes appear under the 
right "a=mid" line.

> [TS] This now adds complexity. ;-)

Likely yes.

Emil

> I would just always send all candidates.

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Jul 2013 12:47:10 -0400

>>> Q1: Making reliable provisional responses and PRACK mandatory.

Yes.

>> If you use PRACK you have SIP timer T1 running and would re-transmit
>> the 180 in case that the PRACK is not received.
>
> Right.
>
>> Assuming that you want to wait with sending of the INFO until you saw
>> the PRACK, would lead to delay in that case.
>

Yes, why is it such an issue to require PRACK?
It is a good thing to implement for many reasons. So in conjunction with 
defining other new functionality, why not require it?

>> ... and you would detect quicker that the 180 was lost than by waiting

This just highlights how "delicate" things get if you start trying to 
work around the lack of PRACK. It might be possible to get something 
that seems to work, but its a house of cards.

>> BTW: 5245 recommends to use PRACK. However it does not mandate it, but
>> gives the alternative procedures as an option.

Yes. The trickle ICE INFOs are *relative* to what was set up in the O/A. 
In the absence of the answer the trickle ICE is problematic.

>>> is received out of order? Do we just tell the application to resend the

*If* you are going to send in a non-blocking way then they should be 
cumulative.

If you treat them as blocking, then they don't have to be, but it might 
still be better.

>> [TS] I would go with the proposal below and send cumulatively. You
>> also have the CSeq: header field to detect late arrivals.

Yes, you can detect the late arrival. But you have at that point already 
acted on the one that should have been preceded by it.

>>> gets resent anyway.

Exactly.

>>> A drawback here would obviously be that this adds
>> [TS] Again I'm not convinced about the complexity. Both peer know
>> their candidates, what is the issue in putting all of them into the INFO?
>

I don't know enough about ICE to comment specifically on this.

But ISTM that this is analogous to what a SIP device must do to manage 
the target set of destinations for a request - it is required to keep 
track and not add the same address to the target set more than once.

	Thanks,
	Paul

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 05 Jul 2013 10:28:22 -0700

Hi,

I did not receive much comments on my proposal to use STUN packets to carry
the new ICE candidates.  To summarize, instead of using the SDP in an INFO and
or UPDATE transaction, the new candidates can be sent on the same path that
the media will use by default (i.e. using the candidate that is copied in the
m= and c= line).  Because this candidate is chosen to always succeed (using a
TURN server), the candidate will always reach their destination.  This will
remove any problem in the signaling path, because it is no longer used to
update the candidates.

Thanks.

On 07/03/2013 07:13 AM, Emil Ivov wrote:
> SIP. Now that discussions on BUNDLE and the plans seem to be winding down,
> we wanted to run a few questions by the working group.
> 
> suggestion for implementing a 5245-style hack where the answerer basically
> resends the 180 until it knows that it has been received.
> 
> 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions
> when the first connectivity check is received) but we don't have that
> option here since the 180 may contain either none or only host candidates
> so there are strong chances that no binding request would be received on
> them.
> 
> requests with trickled candidates as an indication that 180 was received.
> This however wouldn't work with half trickle so we are basically back to
> vanilla ICE for all (non-re) INVITEs.
> 
> Another option would be to mandate an INFO request with "end-of-candidates"
> in response to the 180, but that would be just the same as mandating PRACK
> support.
> 
> Thomas also suggested that the answerer can start sending INFOs right after
> it sends its answer in the 180 and then it can just resend the 180 if the
> INFOs result in a 481 response.
> 
> parallel? If the latter, then what happens when an INFO fails because it is
> received out of order? Do we just tell the application to resend the
> candidates asap?
> 
> learned candidates or all candidates we've learned so far? Dale suggested
> that if we do this cumulatively we wouldn't need to worry about the case
> with the out-of-order INFOs from Q2 since the information gets resent
> anyway. A drawback here would obviously be that this adds more complexity
> for trickle ICE users (WebRTC applications specifically)
> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Emil Ivov <[email-masked]>
Date: Fri, 5 Jul 2013 23:59:40 +0200

On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>

Here's my take:
Default candidates are not guaranteed to work. Also, you only get to
place one candidate as default. What if your peer is IPv6 only and you
chose an IPv4 candidate? Or, what if you are both on the same LAN with
limited Internet connectivity? Or what if the service you use doesn't
even have a TURN server? I am sure we can come up with many other
similar situations.

The only transport that's guaranteed to work prior to ICE is
signalling. There's nothing else that's as reliable as this. (If there
was then we probably wouldn't even need ICE in the first place).

Emil

--
https://jitsi.org

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJR1wI1AAoJECnERZXWan7EpOUQAIEFAeuFxkj0IJoWhiPXBb/L
> ulHURlg00WoK9RJFxLFWHP36lmaQ2y0v7LaFgX1hFoG9TMmMCbyxIfnva+5QFYzx
> LkiOZcgM5XuXjk6Ruke2/vrgByCPPYiCc7+K01+7NMO6tQL8rKxKr1Hq5PPRkUHY
> V6PO+XQd+KK8dm2W1qsR9s16goxqqQzeYJsEOX9mTGjqQdaju75FY88FdFE2rhib
> pdNrr+crC+gqdz/LKMS9so+dKtMMl3KNT39umDQuFkN9Gt+xorbKkvARCbB24xO3
> jPX7koQ0v/eJd1lZwmgkrzMiBDnr/RHigIX3OIuNhL5xilf0Daps5jIkvIJT31gJ
> CUsfR78ykrWp3wJJ7Ck+PQpAyUrCpcctCUR6kEZ4g1gaKRAEWfw1MgieETqtLE8x
> Dwsy2c3Qw7XPi1VRMfc6BmCbrd59hQtIsF07yHZEJuHz8zuJoWN9mKLMsGJn4E4G
> ipIQwruOde7B23YUI0kqBzldRnw5sQ5XDi//rNnd2/KaMhSdxB5+A+g+yy2yQIyN
> m7It4KZ1+BiyOrgK2w8JHkkmbclSV5j3hEEv0pfgt3OoXWwuUqF2rjdQ4NfsXRj4
> D05DUrhrgP7HKp+wxsIi2yyxFaZhkIBnooV/AhyDEh4Lk1KbKPPrSaEUyo6/5CmQ
> CtZLNHXi/Xv3Y3PjrpJF
> =DFTv
> -----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 05 Jul 2013 15:45:25 -0700

On 07/05/2013 02:59 PM, Emil Ivov wrote:
> On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin <[email-masked]>
> wrote: Hi,
> 
> I did not receive much comments on my proposal to use STUN packets to
> carry the new ICE candidates.  To summarize, instead of using the SDP in an
> INFO and or UPDATE transaction, the new candidates can be sent on the same
> path that the media will use by default (i.e. using the candidate that is
> copied in the m= and c= line).  Because this candidate is chosen to always
> succeed (using a TURN server), the candidate will always reach their
> destination.  This will remove any problem in the signaling path, because
> it is no longer used to update the candidates.
> 
>> Here's my take: Default candidates are not guaranteed to work.

Sorry, my summary was incorrect.  It is assumed that half-trickle is used (for
the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3), so the
offerer sends the full set of candidates.

>> Also, you only get to place one candidate as default. What if your peer
>> is IPv6 only and you chose an IPv4 candidate?

With the offerer full set of candidates, it is easy to find the IPv6 TURN
candidate.

> Or, what if you are both on the same LAN with
>> even have a TURN server?

Then what about sending the answerer candidates using all the offerer
candidates available, but in reversed priority order?

>> I am sure we can come up with many other similar situations.
> 
>> The only transport that's guaranteed to work prior to ICE is signalling.
>> There's nothing else that's as reliable as this. (If there was then we
>> probably wouldn't even need ICE in the first place).

ICE is less about reliability than about latency, i.e. so far nobody proposed
to tunnel the media over SIP :-)

>> -- https://jitsi.org
>>>> Christer, Enrico and I are preparing the next version of Trickle ICE
>>>> for SIP. Now that discussions on BUNDLE and the plans seem to be
>>>> winding down, we wanted to run a few questions by the working group.
>>>> 
>>>> Obviously this would be nice to avoid, so the question is: is there a
>>>> reasonable mechanism to achieve this (and by reasonable, we mean
>>>> only host candidates so there are strong chances that no binding
>>>> request would be received on them.
>>>> 
>>>> INFO requests with trickled candidates as an indication that 180 was
>>>> after it sends its answer in the 180 and then it can just resend the
>>>> 180 if the INFOs result in a 481 response.
>>>> 
>>>> because it is received out of order? Do we just tell the application
>>>> to resend the candidates asap?
>>>> 
> _______________________________________________ mmusic mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> 

- -- 
Marc Petit-Huguenin

---

From: Emil Ivov <[email-masked]>
Date: Sat, 06 Jul 2013 00:53:30 +0200

> offerer sends the full set of candidates.

Are you suggesting that we would always need to do half trickle, even 
when we know the other party has support for trickle and can switch to full?
> candidates available, but in reversed priority order?

Even then, endpoint dependent filtering (which seems to be the default 
these days) requires that both ends start sending packets simultaneously 
for server-reflexive addresses to work.

In the case above the trickled candidates wouldn't be able to reach the 
offerer because it wouldn't be sending anything toward the answerer.

> ICE is less about reliability than about latency,

I believe it's always been about both. (Otherwise we would have probably 
stopped at STUN).

> i.e. so far nobody proposed

You'd be surprised ;)

https://java.net/projects/jain-sip-applet-phone

Emil
> iQIcBAEBCAAGBQJR10yBAAoJECnERZXWan7EmtYP+wa1qTpgQNYZpZc5T+/f9+j7
> QJRnTlcU7aIiCX2wDHUILbUk4YCiOh8wKHf7OiLbtAKYlgq+98KyQuViVeiRoVGl
> qpRQnE+Y1SjqY/jVVc4UwJvEeP2TbW5ARmUG/bqN/dLQzNyhyJeBmBIMzYTpmxl7
> SJ1M8xB5Emn8d03zb7jdUtTcy0HqN4a88R3HZqmVWH4M+wRWKVZlq4RGbpiy03Or
> WKc4VFUsuQnRGMZbmkG3EGrEJEhA+kCAthKY1+EORSO6sIUYQVxq58pRmuF8DTgm
> h7MO6Qtco8dJsVqgT2HQ9BZiQ60XP6X+xUPIIjJ3cHaZfjqxC6oSUKo+FXpP9Gaq
> euoEbKdxiA9D37CN2vMWpcLqk0GUOE+7uJ8QVWMfYWTVWCZE1XO9uVhYnNkYtcNN
> 15zmqvzTRrv0qQlCzgLSfeXpBAcsv46GZdqd/HKcczlgutFil7QNFyKAJD9njNLg
> VeO5nWs5Koqn8cug+GlBG/dFNTdFss/0vlX6HsBdyqIpWKPdf4gwueAS3QVieUEb
> cMFKOUzThLpOgTkkhzJQuY9N6ynBiF8Cn1t1cPJQZksMtuKRjRJo5BKHOfwLufk4
> fgLJOuUEJkcklrrBIbqRfpfERGQ4aFZMxvWN3LO3vx4a3bL4/M8kGst871MWMR1S
> EEdIVr/mOjJMEimq9cjK
> =bnR1

-- 
https://jitsi.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 05 Jul 2013 16:14:33 -0700

On 07/05/2013 03:53 PM, Emil Ivov wrote:
> 
> 
> On 06.07.13, 00:45, Marc Petit-Huguenin wrote: On 07/05/2013 02:59 PM, Emil
> Ivov wrote:
>>>> On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin
>>>> <[email-masked]> wrote: Hi,
>>>> 
>>>> I did not receive much comments on my proposal to use STUN packets
>>>> to carry the new ICE candidates.  To summarize, instead of using the
>>>> SDP in an INFO and or UPDATE transaction, the new candidates can be
>>>> sent on the same path that the media will use by default (i.e. using
>>>> the candidate that is copied in the m= and c= line).  Because this
>>>> candidate is chosen to always succeed (using a TURN server), the
>>>> candidate will always reach their destination.  This will remove any
>>>> problem in the signaling path, because it is no longer used to update
>>>> the candidates.
>>>> 
> Sorry, my summary was incorrect.  It is assumed that half-trickle is used
> (for the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3),
> so the offerer sends the full set of candidates.
> 

No, I just am saying that the solution that I propose does not take in account
full-trickle.

> 
>>>>> Also, you only get to place one candidate as default. What if your
>>>>> peer is IPv6 only and you chose an IPv4 candidate?
> 
>>>>> limited Internet connectivity? Or what if the service you use
>>>>> doesn't even have a TURN server?
> 

Right.

>>>>> signalling. There's nothing else that's as reliable as this. (If
>>>>> there was then we probably wouldn't even need ICE in the first
>>>>> place).
> 

You mean TURN?  As long as you do not care about latency, TURN is all you need
as it always works (and that's all we used for a long time, even if it was not
called TURN).  ICE was invented because latency was important - so STUN was
useful - but there is no reliable way to predict if it will work.

> 
> i.e. so far nobody proposed to tunnel the media over SIP :-)
> 
>> You'd be surprised ;)
> 

Hmm, I do not see SIP as media transport in this project.  What I meant was
something like transporting the media in a SIP INFO.

>>>>>>> Christer, Enrico and I are preparing the next version of
>>>>>>> Trickle ICE for SIP. Now that discussions on BUNDLE and the
>>>>>>> plans seem to be winding down, we wanted to run a few questions
>>>>>>> by the working group.
>>>>>>> 
>>>>>>> Obviously this would be nice to avoid, so the question is: is
>>>>>>> there a reasonable mechanism to achieve this (and by
>>>>>>> reasonable, we mean something that wouldn't be harder than
>>>>>>> implementing support for PRACK).
>>>>>>> 
>>>>>>> There was some discussion about this back in April and there
>>>>>>> was a suggestion for implementing a 5245-style hack where the
>>>>>>> answerer basically resends the 180 until it knows that it has
>>>>>>> been received.
>>>>>>> 
>>>>>>> retransmissions when the first connectivity check is received)
>>>>>>> but we don't have that option here since the 180 may contain
>>>>>>> either none or only host candidates so there are strong chances
>>>>>>> that no binding request would be received on them.
>>>>>>> 
>>>>>>> Thomas also suggested a second option which would be to also
>>>>>>> use INFO requests with trickled candidates as an indication
>>>>>>> that 180 was received. This however wouldn't work with half
>>>>>>> trickle so we are basically back to vanilla ICE for all
>>>>>>> (non-re) INVITEs.
>>>>>>> 
>>>>>>> "end-of-candidates" in response to the 180, but that would be
>>>>>>> just the same as mandating PRACK support.
>>>>>>> 
>>>>>>> Personally I think this could potentially be made to work, but
>>>>>>> it would imply a level of complexity that considerably exceeds
>>>>>>> PRACK support.
>>>>>>> 
>>>>>>> Opinions?
>>>>>>> 
>>>>>>> Q2: How do we send INFOs? Are they blocking or do we just send
>>>>>>> them in parallel? If the latter, then what happens when an INFO
>>>>>>> fails because it is received out of order? Do we just tell the
>>>>>>> freshly learned candidates or all candidates we've learned so
>>>>>>> far? Dale suggested that if we do this cumulatively we wouldn't
>>>>>>> need to worry about the case with the out-of-order INFOs from
>>>>>>> Q2 since the information gets resent anyway. A drawback here
>>>>>>> would obviously be that this adds more complexity for trickle
>>>>>>> ICE users (WebRTC applications specifically)
>>>>>>> 

- -- 
Marc Petit-Huguenin

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 8 Jul 2013 09:24:55 +0000

A few thoughts/response inline

> From: Emil Ivov [mailto:[email-masked]]
> Sent: Friday, 05 July, 2013 16:13
> To: Stach, Thomas
> Cc: MMUSIC IETF WG
> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
> 
> Hey Thomas
> 
> >> for
> we
> INFO
> right
> would
[TS] Saving the half RTT is not my primary goal. When implementing ICE we got away without requiring PRACK. 
I want to keep this property, since it allows 
> I am always a bit nervous when it comes to interpreting error
[TS] We are actually specifying new behavior here. 
Thus, we can specify the rule for the new info package and its application for trickle-ICE in way as exact as possible such that there would be no need for interpretation or nervousness.

>    SHOULD terminate the dialog.
[TS] We are in the dialog establishing phase here and when the 180 was lost we don't even have an early dialog.
So this rule does not apply. The 481 to the INFO would rather be the indicator for this situation. As stated above we can prescribe that the 481 (and only the 481) is to be sent for the INFO and what happens next, i.e. retransmit the 180.
> As said above: a lost 180 is not the only possible cause for a 408 in
[TS] I assume you mean 481.
> 
> > BTW: 5245 recommends to use PRACK. However it does not mandate it,
> but gives the alternative procedures as an option.
[TS] For the trickle-ICE application of the info-package I would just recommend sending (all) the ICE candidates.
This eliminates the competition, you just take what you got last.
> in
> >> parallel? If the latter, then what happens when an INFO fails
> because
> >> it
> freshly
> candidates. 
[TS] As Trickle-ICE is just being specified, we are in a position to specify this handling.
>If they don't then it would be up to the receiving JS app,
[TS] As the ICE/STUN logic resides in the browser not in the JS app, this would be a matter of the API definition to always provide all known candidates towards the JS APP for sending. On the receiving side the JS APP would also just have to push all received candidates through the browser API.

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 8 Jul 2013 09:44:14 +0000

Paul, 

inline

> Behalf Of Paul Kyzivat
> Sent: Friday, 05 July, 2013 18:47
> To: [email-masked]
> ICE
[TS] I see potential for easier GW/SBC interworking with vanilla-ICE UAs, that did not implement PRACK
> It is a good thing to implement for many reasons. 
[TS] There are also good reasons against PRACK. e.g. the much more complicated state machine.
So in conjunction
> with
[TS] We did not need to require PRACK for vanilla ICE, why require it now. There is a proposal on the table that solves the problem without the complexity of PRACK. 
As already said I don't object to recommending PRACK (as in 5245), I just don't want it mandatory. 

> >> ... and you would detect quicker that the 180 was lost than by
> waiting
> >> for the PRACK.
> 
[TS] Please refer to my reply to Emil, the rule above does not apply here.
> but
[TS] What is the problem? The previous INFO had fewer candidates, you just got all additional candidates.  
I can't see a case were a candidate got removed in a subsequent INFO.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jul 2013 11:53:16 -0400

Thomas,

> I want to keep this property, since it allows

I get it that you think PRACK is hard to implement.
But hard compared to *what*? I suspect that this will introduce 
complexity elsewhere.

> So this rule does not apply. The 481 to the INFO would rather be the indicator for this situation. As stated above we can prescribe that the 481 (and only the 481) is to be sent for the INFO and wh…

This is part of the house of cards that I was talking about.
You seem to be saying that a special rule should be be adopted, allowing 
INFO to be sent from INVITE-UAS before it is known that the dialog has 
been established. And then a special rule for processing 481 responses 
to INFO in this context.

> This eliminates the competition, you just take what you got last.

Certainly it will be simpler if all candidates are sent each time.
But I don't think that means you can just take what you got last. You 
still need to check if what you got is *older* than what you already 
have, and if so ignore it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jul 2013 12:05:15 -0400

Just responding to things that haven't already been covered.

> [TS] I see potential for easier GW/SBC interworking with vanilla-ICE UAs, that did not implement PRACK

I don't get it.

If you are talking about SBCs that terminate/relay media, then the leg 
doing trickle-ICE is separate from the leg doing vanilla-ICE. So what is 
the issue?

And if you have a signaling-only SBC, and one leg supports trickle-ICE 
while the other side supports only vanilla-ICE, then just use 
vanilla-ICE e2e. You won't gain anything by an intermediary trying to 
map trickle-ICE to vanilla-ICE.

> [TS] There are also good reasons against PRACK. e.g. the much more complicated state machine.

Yes, but once you have done it then it is there to use for all sorts of 
things. The alternative seems to be to instead introduce a lot of new 
complexity that is *only* applicable to trickle-ICE.

	Thanks,
	Paul

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 9 Jul 2013 21:20:29 +0000

> Sent: Monday, 08 July, 2013 17:53
> To: [email-masked]
[TS] The remainder of the sentence got lost. It should have read "... since it allows easier introduction RTCWEB client with trickle ICE into a SIP network that never used PRACK."
> But hard compared to *what*? I suspect that this will introduce
[TS] With respect to this complexity I just see the 481 handling for the INFO. 
Compared to all the new states that I need when I implement PRACK (which can include a new offer as you know), I just have to keep the previously sent provisional response together with the INFO request. The latter I have to keep anyhow for potential retransmissions. 
If I get a 481, I resent the 18x and the INFO request.
BTW: Just form emphasis. This is only needed if there is a UDP hop somewhere, in case of TCP/TLS the 18x would never be lost.

> >>     (Call/Transaction Does Not Exist) or a 408 (Request Timeout),
> the
> >> UAC
> > [TS] We are in the dialog establishing phase here and when the 180
> was lost we don't even have an early dialog.
> > So this rule does not apply. The 481 to the INFO would rather be the
> indicator for this situation. As stated above we can prescribe that the
> 481 (and only the 481) is to be sent for the INFO and what happens
> next, i.e. retransmit the 180.
> 
[TS] Let me reject the comparison with a "house of cards". We are currently specifying a new feature. There are no deployed implementations yet. Thus we can exactly specify what should happen at the UAC when it receives an out-of-dialog INFO because the dialog establishing unreliable 18x was lost, i.e. to send 481. 
On the UAS side we can also specify what to do when the INFO gets a 481. I.e. resend the 18x and the INFO request.
I consider this closer to a solid foundation than to a house of cards.

Regards
Thomas

> > [TS] For the trickle-ICE application of the info-package I would just
> recommend sending (all) the ICE candidates.

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 9 Jul 2013 21:21:05 +0000

Paul,

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, 08 July, 2013 18:05
> To: Stach, Thomas
> Cc: [email-masked]

> map trickle-ICE to vanilla-ICE.
[TS] 
If the trickle-ICE side uses PRACK and the vanilla ICE side does not, the interworking SBC does not only have to collect the trickled candidates and send it on as a bunch once trickling finished. It also has to interwork PRACK.
As you know the PRACK request can contain a new SDP offer or you could also use UPDATE for another SDP O/A before the 200 OK to the INVITE request. This is rather nasty to interwork if not impossible.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jul 2013 17:52:33 -0400

> BTW: Just form emphasis. This is only needed if there is a UDP hop somewhere, in case of TCP/TLS the 18x would never be lost.

With PRACK, the work is implementing it as it is specified. And then you 
can use it everywhere, not just for trickle-ICE.

I'm not sure I understand your proposal for using info in the context, 
but I *think* you are asking for *special* handling of 481 for INFO, 
contrary to how specs call for it to be implemented. For one think, this 
would effectively be a revision to some existing specification. And 
maybe you only what this handling when INFO is used for trickle-ICE?

Remember, introducing this will often mean using an existing 
implementation of INFO for this purpose.

> I consider this closer to a solid foundation than to a house of cards.

Lets first decide in you are proposing a special mechanism for use with 
trickle-ICE, or if you are proposing a revison (bug fix?) to INFO, or to 
3261 & 5057.

If you are proposing a change in how INFO works exclusively when used 
for trickle-ICE then I think it is a non-starter.

If you are proposing a revision regarding the handling of presumed-to-be 
in-dialog requests from UAS to UAC before the UAS has proof that the UAC 
knows of the dialog, then we can talk.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jul 2013 17:59:04 -0400

> As you know the PRACK request can contain a new SDP offer or you could also use UPDATE for another SDP O/A before the 200 OK to the INVITE request. This is rather nasty to interwork if not impossib…

If trickle-ICE worked without PRACK, then the SBC *still* needs to 
collect up all the trickled candidates and send them when it can based 
on the limitations of vanilla-ICE. So the use of trickle-ICE provides no 
speedup compared to using vanilla-ICE e2e.

Also, it sounds like trickle-ICE is requiring changes in the ordering of 
how candidates are tried. If one side uses trickle-ICE and the other 
doesn't, then ISTM that may break.

So I'm still not seeing a case here when it makes sense to gateway 
between trickle-ICE and vanilla-ICE. There may be one, but I'm not 
seeing it.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Wed, 10 Jul 2013 00:41:04 +0200

A few cross mail replies:

On 09.07.13, 23:20, Stach, Thomas wrote:
> BTW: Just form emphasis. This is only needed if there is a UDP hop
> somewhere, in case of TCP/TLS the 18x would never be lost.

What does this change for anyone? Clients have no way of knowing whether
there would be UDP hops along the way so they would always need to be
ready for this option.

> [TS] As Trickle-ICE is just being specified, we are in a position to

While this is true, I see the following issue here: cumulative sending
is only necessary for SIP/UDP (which is quite a paradox because SIP/UDP
with ICE would break in a big number of cases).

> [TS] As the ICE/STUN logic resides in the browser not in the JS app,
> this would be a matter of the API definition to always provide all
> known candidates towards the JS APP for sending. On the receiving
> side the JS APP would also just have to push all received candidates
> through the browser API.

I find it strange that we would be imposing constraints on a new generic
API because of a broken use case that only exists with one usage
protocol. Especially given that the said use case (SIP+ICE over UDP) is
NOT going to work anyway because of MTUs and improper IP fragmentation
handling on various devices today.

>>> We are indeed likely to get a 481 when sending INFOs and the 180
>>> hasn't yet made it to the remote side. However 481 might also
>>> imply that our dialog is simply dead for some reason and in this
>>> case 3261 says:
>>>
>>>
>>> the UAC SHOULD terminate the dialog.
>
> was lost we don't even have an early dialog. So this rule does not
> apply.

I am not sure this is true. There *is* an early dialog at the side 
that's sending the 180. The INFO is a second request within that same 
dialog and 3261 is very clear that a 481 would lead to termination of 
the dialog. Specifying different behaviour here would mean that many 
developers may need to start fighting/changing their SIP stacks.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Jul 2013 17:49:32 +0000

Hi,

As I've been on vacation, I tried to go through this thread in one sweep. I may have missed/misunderstood some parts, and my apologies if my comments below have already been dealt with.

First, regarding 180, no matter if we use PRACK or not, SIP requires the SDP to be identical in all 180 responses. That means you can't add new candidates in subsequent 180 responses (eventhough vanilla ICE uses 180s without PRACK, the SDP is identical in all 180s, AFAIR).

Second, I get a little confused when we talk about the UAS sending INFO before it knows that the dialog is established, and that we would define some new handling rules when an error response is received. Now, IF we want the UAC to inform the UAS that the dialog has been established, we don't need PRACK for that. The UAC could send an INFO when it receives the 180, and when the UAS receives the INFO it knows the dialog has been established. I haven't thought so much about it, so I am not suggesting such mechanism at this point, I am only saying that it would be a possible solution from a SIP protocol perspective :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Sun, 21 Jul 2013 20:56:55 +0200

Hey Christer,

On 21.07.13, 19:49, Christer Holmberg wrote:
> Hi,
>
> As I've been on vacation,

Hope you had a good one!

> I tried to go through this thread in one
> sweep. I may have missed/misunderstood some parts, and my apologies
> if my comments below have already been dealt with.
>
> First, regarding 180, no matter if we use PRACK or not, SIP requires
> the SDP to be identical in all 180 responses. That means you can't
> add new candidates in subsequent 180 responses (eventhough vanilla
> ICE uses 180s without PRACK, the SDP is identical in all 180s,
> AFAIR).

Good point!

> Second, I get a little confused when we talk about the UAS sending
> INFO before it knows that the dialog is established, and that we
> would define some new handling rules when an error response is
> received. Now, IF we want the UAC to inform the UAS that the dialog
> has been established, we don't need PRACK for that. The UAC could
> send an INFO when it receives the 180, and when the UAS receives the
> INFO it knows the dialog has been established. I haven't thought so
> much about it, so I am not suggesting such mechanism at this point, I
> am only saying that it would be a possible solution from a SIP
> protocol perspective :)

This could indeed work! It would also make a lot of sense in cases where 
both agents are doing full trickle.

Of course it does mean that, especially in half trickle scenarios, we 
basically have one full end-to-end signalling RTT (180 + INFO) during 
which trickling will be completely blocked. This could take a while.

Still, if we don't come up with a better alternative, the worst case 
(i.e. half trickle + slow signalling) shouldn't be much worse than 
vanilla ICE.

Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 21 Jul 2013 17:40:57 -0400

How is this better than PRACK?

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Jul 2013 00:06:45 +0200

> How is this better than PRACK?

Well, you don't have to worry about supporting offers and answers in the 
PRACK (which could indeed be a pain).

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jul 2013 06:24:14 +0000

Hi,

>How is this better than PRACK?

I didn't say it's better :)

Regards,

Christer

On 7/21/13 2:56 PM, Emil Ivov wrote:
>> I tried to go through this thread in one sweep. I may have 
>> missed/misunderstood some parts, and my apologies if my comments 
>> below have already been dealt with.
>>
> This could indeed work! It would also make a lot of sense in cases 
> where both agents are doing full trickle.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jul 2013 06:33:18 +0000

Hi,

> Well, you don't have to worry about supporting offers and answers in the PRACK (which could indeed be a pain).

In my years of "PRACK experience", PRACK itself (for the purpose of acknowledging reliable 18x responses) has never been a problem. But, I agree there could be issues when it is used for O/A - especially if one wants to reject an offer. In my experience, however, offers in PRACK are normally used e.g. to change pre-condition state, and/or to remove codecs, so the likelihood of rejection based on the SDP content should be rather small.

There are also implementations that don't accept offers in PRACK to begin with, but I think that goes under "bad implementation" :)

Having said that, not specific to trickle ICE, if O/A is a show stopper for the community to use PRACK, maybe that is something we need to look into on a more general level.

Regards,

Christer

>>> much about it, so I am not suggesting such mechanism at this point, 
>>> I am only saying that it would be a possible solution from a SIP 
>>> protocol perspective :)
>>

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Jul 2013 12:40:36 +0200

On 22.07.13, 08:33, Christer Holmberg wrote:
> Having said that, not specific to trickle ICE, if O/A is a show stopper for the community to use PRACK,

Well, speaking as an implementor, I can completely see how many would 
feel uneasy about adding this to working implementations. It basically 
means adding some additional complexity with no actual benefit in return.

> maybe that is something we need to look into on a more general level.

You mean something like PRACK-lite that doesn't have offer answer? This 
sounds like something that could be relatively straightforward to 
specify. It would basically have to mimic PRACK but remove the part that 
talks about the additional O/A possibilities.

Trickle ICE for SIP could then have a dependency on it ...

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jul 2013 11:11:42 +0000

Hi,

>> In my years of "PRACK experience", PRACK itself (for the purpose of acknowledging reliable 18x responses) has never been a 
>> problem. But, I agree there could be issues when it is used for O/A - especially if one wants to reject an offer. In my experience, however, 
>> offers in PRACK are normally used e.g. to change pre-condition state, and/or to remove codecs, so the likelihood of rejection based on the SDP content should be rather small.
>>
>> There are also implementations that don't accept offers in PRACK to 
>> begin with, but I think that goes under "bad implementation" :)
>>
> Well, speaking as an implementor, I can completely see how many would feel uneasy about adding this to working implementations. It basically means adding some additional complexity with no actual benefit in return.
>
> You mean something like PRACK-lite that doesn't have offer answer? This sounds like something that could be relatively straightforward to specify. It would basically 
> have to mimic PRACK but remove the part that talks about the additional O/A possibilities.

It could perhaps even be a request without a response, similar to ACK, which would make it even more "lite". When the UAS receives it, it simply ceases the transmission of the 18x.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Tue, 23 Jul 2013 19:06:15 +0200

> It could perhaps even be a request without a response, similar to ACK, which would make it even more "lite". When the UAS receives it, it simply ceases the transmission of the 18x.

Hmm ... this sounds like something that would make a lot of proxies and 
SIP stacks unhappy.

I actually think we could pull this off with simple PRACKs. Only, rather 
than using the "100rel" tag we go for something like "100rel-lite" which 
could be defined to indicate that a UA supports PRACK but only for 
reliability (and PRACK bodies are not allowed).

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2013 19:23:49 +0000

Hi,

You are right that sending a request, without a response, would cause problems.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Emil Ivov [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: Paul Kyzivat [[email-masked]]; Stach, Thomas [[email-masked]]; [email-masked] [[email-masked]]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

Emil

--
https://jitsi.org

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 24 Jul 2013 03:28:52 +0000

I prefer the 180 resend approach and all the right things are already looking at them.  I have always objected to mandating use of PRACK. Obviously I'm fine with things that have PRACK can use it but I want some solution for things that don't. 

One small note, the SDP in the 180 can change as long as the to-tag is also changed.

---

From: Alan Johnston <[email-masked]>
Date: Wed, 24 Jul 2013 05:45:48 -0400

Agree with Cullen - if there is a reasonable approach (such as
retransmitting 180) that avoids PRACK, then we should use this approach.

- Alan -

On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy) <[email-masked]
> wrote:

>
> I prefer the 180 resend approach and all the right things are already
> looking at them.  I have always objected to mandating use of PRACK.
> Obviously I'm fine with things that have PRACK can use it but I want some
> solution for things that don't.
>
> retransmissions when the first connectivity check is received) but we don't
> have that option here since the 180 may contain either none or only host
> candidates so there are strong chances that no binding request would be
> received on them.
> >
> "end-of-candidates" in response to the 180, but that would be just the same
> as mandating PRACK support.
> >
> after it sends its answer in the 180 and then it can just resend the 180 if
> the INFOs result in a 481 response.
> >

---

From: Emil Ivov <[email-masked]>
Date: Wed, 24 Jul 2013 12:01:01 +0200

Hey Alan, Cullen,

> retransmitting 180) that avoids PRACK, then we should use this approach.

There is one and it comes down to requiring the remote side to send an 
INFO request as soon as it gets it. The INFO request could contain 
trickled candidates (in the case of full trickle) or just 
end-of-candidates (in the case of half-trickle).

This could work and, personally, I have no issue with it.

I believe the suggestion that Christer made was: given how the above 
basically works as a PRACK minus the O/A and given how the O/A in PRACKs 
seems to be a deal breaker for many, then we might want to generalize 
the above mechanism so that other specs can also use it.

Cheers,
Emil

> - Alan -
>
>
> On Tue, Jul 23, 2013 at 11:28 PM, Cullen Jennings (fluffy)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     I prefer the 180 resend approach and all the right things are
>     already looking at them.  I have always objected to mandating use of
>     PRACK. Obviously I'm fine with things that have PRACK can use it but
>     I want some solution for things that don't.
>
>     On Jul 3, 2013, at 8:13 AM, Emil Ivov <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      > Hey all,
>      >
>     ICE for SIP. Now that discussions on BUNDLE and the plans seem to be
>     something that wouldn't be harder than implementing support for PRACK).
>      >
>      > There was some discussion about this back in April and there was
>     a suggestion for implementing a 5245-style hack where the answerer
>     we don't have that option here since the 180 may contain either none
>     or only host candidates so there are strong chances that no binding
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
https://jitsi.org

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 24 Jul 2013 22:25:05 +0530

Hi Emil,

As Cullen suggested in case 180 with different to-tag is used by UAS then
INFO package itself is not required right?

Thanks
Partha

> Sent: Wednesday, July 24, 2013 3:31 PM
> To: Alan Johnston
> Cc: Cullen Jennings (fluffy); MMUSIC IETF WG
> >     One small note, the SDP in the 180 can change as long as the to-
> tag
> >     is also changed.
> >
> >
> >
> Trickle
> be
> there
> was
> none
> use
> was
> far?

---

From: "Vijaya Mandava (vimandav)" <[email-masked]>
Date: Wed, 24 Jul 2013 18:22:21 +0000

180 with different to-tag would mean call is forked.
If uac side do not support call forking, then we cannot use this 180
response to collect trickled candidates.

As Emil said, I think INFO is the right way to go here.

Thanks,
Vijaya

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Jul 2013 19:47:01 +0000

Hi,

Keep in mind that, no matter if we use PRACK, PRACK-lite, INFO, or simply re-transmission, the SDP can not change from one 180 to another (for the same To tag, that is).

Regards,

Christer

-----Original Message-----
From: Vijaya Mandava (vimandav) [[email-masked]]
To: Parthasarathi R [[email-masked]]; &apos;Emil Ivov&apos; [[email-masked]]; &apos;Alan Johnston&apos; [[email-masked]]
CC: Cullen Jennings (fluffy) [[email-masked]]; &apos;MMUSIC IETF WG&apos; [[email-masked]]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

Thanks,
Vijaya

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 24 Jul 2013 19:56:17 +0000

> response to collect trickled candidates.

If it is a UAC, it supports this so I don't see the problem.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Jul 2013 20:34:37 +0000

Hi,

Wouldn't the UAC need to know that the 180s come from the same UAS?

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Wed, 24 Jul 2013 22:49:12 +0200

> If it is a UAC, it supports this so I don't see the problem.

One problem is that the UAC could support it to the extent of making it 
visible to the user:

   "Your contact is being alerted on these N locations"

And of course there's also the fact that we would be creating several 
dialogs per call, that we'd then need to clean and garbage collect.

Why would we want to go there?

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Jul 2013 20:57:27 +0000

There is a very nice, easy and lightweight mechanism for cleaning: 199 :)

Regards,

Christer

-----Original Message-----
From: Emil Ivov [[email-masked]]
To: Cullen Jennings (fluffy) [[email-masked]]
CC: Alan Johnston [[email-masked]]; MMUSIC IETF WG [[email-masked]]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

Emil

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 25 Jul 2013 21:18:33 +0530

Hi Emil,

In the mentioned situation, different To-tag with same contact header for
trickled SDP, So there will be no "N" locations. 

My reading of the draft is that this draft is not required in case UPDATE
(RFC 3311) method is supported. UPDATE with SDP will update trickle
candidate within 18x. 

The aim of the draft is to support Trickle ICE for SIP user agent which does
not support RFC 3311 for last 11 years. AFAIK, different "to tag" is the
simpler way to solve the problem in UAS side. I have concern w.r.t INFO
mechanism as it adds one method for handling SDP and complicates the
existing SDP O/A handling (RFC 6337).

Including Christer in this mail thread as he replied in the parallel mail
thread.

Thanks
Partha

> Sent: Thursday, July 25, 2013 2:19 AM
> To: Cullen Jennings (fluffy)
> Cc: Vijaya Mandava (vimandav); Parthasarathi R; Alan Johnston; MMUSIC
> IETF WG

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 25 Jul 2013 21:25:04 +0530

Hi Christer,

The only way to identify whether it is same from UAS is to look into contact
header/IP address of the SIP response. In this situation, contact header and
IP address of SIP response is same all for "to-tag".

My concern is w.r.t INFO with SDP handling. I have written in the different
thread.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: Thursday, July 25, 2013 2:05 AM
To: Cullen Jennings (fluffy); Vijaya Mandava (vimandav)
Cc: Alan Johnston; MMUSIC IETF WG
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

Hi,

Regards,

Christer

-----Original Message-----
From: Cullen Jennings (fluffy) [[email-masked]]
To: Vijaya Mandava (vimandav) [[email-masked]]
CC: Alan Johnston [[email-masked]]; MMUSIC IETF WG
[[email-masked]]

---

From: Emil Ivov <[email-masked]>
Date: Thu, 25 Jul 2013 18:38:16 +0200

Hey Partha,

> trickled SDP, So there will be no "N" locations.

Having the same contact header does not automatically suggest that this 
is somehow a fake fork (unless I am missing the text that says this in 
3261). You could potentially have this if the fork is done by a B2BUA or 
a PSTN gateway for example.

> (RFC 3311) method is supported. UPDATE with SDP will update trickle

Use of UPDATE has already been discussed and we pretty much agreed not 
to go that way.

A mail from Alan and the preceding discussion:
http://www.ietf.org/mail-archive/web/mmusic/current/msg10660.html

A follow up with a nice summary from Dale:
http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html

> existing SDP O/A handling (RFC 6337).

That's the thing, trickle ICE is not part of Offer/Answer. It's a 
separate channel for agent-to-agent communication. Use of SDP is just a 
convenient coincidence.

> Including Christer in this mail thread as he replied in the parallel mail

I believe he is on the list I don't think that's an issue :)

Cheers,
Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 19:32:55 -0400

> reliability (and PRACK bodies are not allowed).

This is crazy!

Every new option presents backward compatibility issues, implementation 
issues, ...

It doesn't make sense to define a new option that is a subset of a long 
time existing option. This is *not* rocket science. Just tell people 
they need to support 100rel as a precondition for trickle ICE. If they 
find trickle ice worthwhile they can implement it.

I'd be amazed if there are any SBCs that don't support PRACK. (But 
Hadriel will fill us in about that.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Jul 2013 08:29:58 +0000

Hi,

I am not sure we would need to define anything new - we could simply say that Trickle ICE UAs don't send Offer/Answers in PRACKSs :)

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: Emil Ivov [[email-masked]]
CC: Christer Holmberg [[email-masked]]; Stach, Thomas [[email-masked]]; [email-masked] [[email-masked]]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

This is crazy!

        Thanks,
        Paul

---

From: "Vijaya Mandava (vimandav)" <[email-masked]>
Date: Fri, 26 Jul 2013 14:09:46 +0000

To add more to this -
PRACK can be enabled or disabled. Trickle Ice UA's would not be affected by this, Since we rely on INFOs to send trickled candidates.

Thanks,
Vijaya

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 26, 2013 4:29 AM
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>, Emil Ivov <[email-masked]<mailto:[email-masked]>>
Cc: "mmusic_ietf.org" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions

---

From: "Parthasarathi R" <[email-masked]>
Date: Fri, 26 Jul 2013 23:32:40 +0530

Hi Emil,

Please read inline.

Thanks
Partha

> Sent: Thursday, July 25, 2013 10:08 PM
> To: 'MMUSIC IETF WG'
<Partha>The discussion is not about fake fork. The contact indicates
location of the UAS. In case of PSTN & B2BUA as UAS, PSTN & B2BUA contact
SIP URI is the location for UAC. From the UAC perspective, there is no "N"
location in UAS due to fake forking as you expect.</Partha>

> http://www.ietf.org/mail-archive/web/mmusic/current/msg10678.html

<Partha> Sorry for the delay discussion. I'm still seeing few aspects  
Missing from the discussion. I'll write the separate mail thread for this
</Partha>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Jul 2013 18:43:43 +0000

Hi,

Wasn't this discussion started due to the fact that the UAS cannot send INFO until it knows that a dialog has been established?

Regards,

Christer

-----Original Message-----
From: Vijaya Mandava (vimandav) [[email-masked]]
To: Christer Holmberg [[email-masked]]; Paul Kyzivat [[email-masked]]; Emil Ivov [[email-masked]]
CC: mmusic_ietf.org [[email-masked]]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
To add more to this -

Thanks,
Vijaya

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Jul 2013 18:48:58 +0000

Hi,

Two different UASs could have the same Contact value, if they e.g. are located in private networks.

Of course, you could use the instance-id, but then we would need to require support of that extension...

Regards,

Christer

-----Original Message-----
From: Parthasarathi R [[email-masked]]
To: &apos;Emil Ivov&apos; [[email-masked]]; &apos;MMUSIC IETF WG&apos; [[email-masked]]
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
Hi Emil,

Please read inline.

Thanks
Partha

---

From: "Stach, Thomas" <[email-masked]>
Date: Sun, 28 Jul 2013 14:36:46 +0000

... chiming in after vacation

> Sent: Wednesday, 24 July, 2013 12:01
> To: Alan Johnston
[TS] I think this also works for me.
> seems to be a deal breaker for many, 
[TS] It is not only the O/A in PRACK, but also the arbitrary number of further O/As in UPDATEs before the 200OK to the initial INVITE.
> then we might want to generalize
[TS] Yes, I think that would be good. 
Paul also seemed to propose to do something generic with my INFO/481/ re-send 18x proposal. 
http://www.ietf.org/mail-archive/web/mmusic/current/msg11754.html 
I liked that as well, but as said above I could also live with acknowledging the 18x with an immediate INFO from the UAC.
Regards 
Thomas

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 28 Jul 2013 23:27:16 +0530

Hi Emil & all,

I had gone through UPDATE vs INFO argument for SIP trickle ICE. As Trickle
ICE is candidate sharing only and also shall happen incrementally, so the
INFO based back channel mechanism was preferred. I have concern with SDP
back channel mechanism after the first O/A is complete as there are more
possibity for race conditions between INFO from UAS and UPDATE from UAC.
UPDATE from UAC is sent across for multiple reasons and  I'll list update
few of the scenarios which come to my mind immediately :

1) Bundle
2) ICE restart
3) Commit for the single codec after negotiation

INFO for trickle ICE leads to confusion due to race conditions between
UPDATE from UAC and un-ordered INFO from UAS. 

Also, it is not clear to me how media IP address as part back channel as it
is part of SDP O/A. In case SDP is designed to carry to media codec
negotiation & media IP address separately (like Jingle/H.245), back channel
mechanism works well 

Thanks
Partha