[MMUSIC] [mmusic-trickle-ice-sip] : Conflict in Figure 10 against 4.1.1 & 4.1.2

[MMUSIC] [mmusic-trickle-ice-sip] : Conflict in Figure 10 against 4.1.1 & 4.1.2 | Race condition between 183 & INFO

ayush jain <jain.ayush09@gmail.com> Fri, 01 April 2016 04:50 UTC

MIME-Version: 1.0
Date: Fri, 01 Apr 2016 10:20:49 +0530
Message-ID: <CAAMRqPuGRw5zDxVUFaUkH0e6eRztfGXn6tf8wTm-7OH49xuv9Q@mail.gmail.com>
From: ayush jain <jain.ayush09@gmail.com>
To: mmusic@ietf.org
Content-Type: multipart/alternative; boundary="001a11c2de1c7be23f052f651fab"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/IsJnLxx8XbAMi_jCPce216koVvc>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: [MMUSIC] [mmusic-trickle-ice-sip] : Conflict in Figure 10 against 4.1.1 & 4.1.2 | Race condition between 183 & INFO
Precedence: list

Hi,

(Re-posting here as suggested by Paul)

As per [draft-ietf-mmusic-trickle-ice-sip-03], Section - 5.4 - Fallback to
Half Trickle, figure 10 depicts:


   - Bob initiating INFO immediately after responding with 183 (Answer) to
   Alice. But I believe that might create a race condition. Either 183 should
   be reliable (Prack) or else Bob should wait till it receives INFO from
   Alice as per 4.1.1 & 4.1.2.

Reason being - While sending Info, Bob won't know otherwise whether 183 has
been received by Alice. (Would be a race condition between 183 & Info, If
183 wins the race, its fine, other case, Alice would receive Info for a
dialog which doesn't exist)


Regards,
_Ayush


---------- Forwarded message ----------
From: Thomas Stach <thomass.stach@gmail.com>
Date: Thu, Mar 31, 2016 at 10:10 PM
Subject: Re: SIP Usage for Trickle ICE -
draft-ietf-mmusic-trickle-ice-sip-03 | Conflict in Figure 10 against 4.1.1
& 4.1.2
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <
christer.holmberg@ericsson.com>, ayush jain <jain.ayush09@gmail.com>, "
enrico.marocco@telecomitalia.it" <enrico.marocco@telecomitalia.it>, "
emcho@jitsi.org" <emcho@jitsi.org>


inline

Am 2016-03-31 um 18:25 schrieb Paul Kyzivat:

On 3/31/16 11:23 AM, Christer Holmberg wrote:

Hi,

I don't have the RFC in front of me, but Paul may have the answer :)


I'll offer an opinion. See below.

I see no reason why you should not be able to send INFO. 183 indicates
that the UAS has received the INVITE, so...

Regards,

Christer

Sent from my Windows Phone
------------------------------------------------------------------------
From: ayush jain <mailto:jain.ayush09@gmail.com> <jain.ayush09@gmail.com>
Sent: ‎31/‎03/‎2016 09:55
To: Christer Holmberg <mailto:christer.holmberg@ericsson.com>
<christer.holmberg@ericsson.com>;
enrico.marocco@telecomitalia.it
<mailto:enrico.marocco@telecomitalia.it> <enrico.marocco@telecomitalia.it>;
thomass.stach@gmail.com
<mailto:thomass.stach@gmail.com> <thomass.stach@gmail.com>; emcho@jitsi.org
<mailto:emcho@jitsi.org> <emcho@jitsi.org>
Subject: SIP Usage for Trickle ICE -
draft-ietf-mmusic-trickle-ice-sip-03 | Conflict in Figure 10 against
4.1.1 & 4.1.2

Hello,

Myself Ayush Jain, I was going through
'draft-ietf-mmusic-trickle-ice-sip-03' for the support of trickle ice in
SIP Sessions.

In Section - 5.4. Fallback to Half Trickle, figure 10 depicts:

  * Bob initiating INFO after responding with SDP answer to Alice using
    183. But that won't be possible isn't it? Either 183 has to be
    reliable (Prack) or else Bob would have to wait till it receives
    INFO from Alice as per 4.1.1 & 4.1.2.


Section 4.1 seems to say that this usage is invalid. In particular:

   o  The dialog at both sides MUST be in early or confirmed state.

As noted in 4.1.2, after Bob sends the unreliable 183 *he* has an early
dialog, but he doesn't yet know if Alice knows that.

If he does go ahead and send the INFO, and the 183 arrives first, then
probably all will be well. But what if the 183 is lost, or delayed, and the
INFO arrives first? In that case the INFO will have a dialog id that Alice
doesn't know about yet. Alice *could* decide to treat the INFO as an
indication that the dialog exists and go ahead and process it as such. But
Alice isn't obligated to do that.

Paul is spot on.
We had exactly this discussion quite a while ago and it finally lead to the
existing text in 4.1.


So I think Bob should wait for some evidence that Alice knows about the
dialog. And INFO from Alice would do it, but I guess that won't be coming
in the half-trickle case. So the only safe way is to use a reliable 1xx and
await the PRACK. Of course that won't work if Alice or Bob don't both
support 100rel, but it seems reasonable to me to require that as part of
trickle support.

Well, in the half trickle-case Alice _supports_ Trickle, but caters for an
answerer that doesn't. The INVITE includes the 'trickle-ice' option tag.
So, Bob can rely on receiving the INFO.

Regards
Thomas


My apologies if I misunderstood the same. Just curious to know.


No need to apologize. It is a good question. It  seems to identify a bug
 in the spec.

I suggest you repost this to mmusic.

    Thanks,
    Paul

Regards,
_Ayush

[MMUSIC] [mmusic-trickle-ice-sip] : Conflict in F… ayush jain