Subject: [Sip] Open Issue #113 : Overlapping INVITEs

From: Rohan Mahy <[email-masked]>
Date: Thu, 13 Dec 2001 11:35:20 -0800

Hi Folks,

As I said in the meeting yesterday, I think overlapping INVITE transactions 
are VERY BAD.  This is a non-backwards compatible change to SIP that breaks 
existing behavior.

Only two justifications exist for making the change.  The first is early 
media, and the second is "that it might be useful in future."       The 
second argument does not justify breaking existing services that have been 
compliant with SIP all along.  I will also remind everyone of the IETF 
maxim that a protocol is perfect "not when there is nothing more to add, 
but when there is nothing to take away."

In terms of early media, Using an OFFER method for EARLY media offers in 
the forward direction is easy and does not break any existing 
services/behavior.  Thinking about multiple early reINVITEs in a forking 
scenario not only makes my head hurt, but I haven't seen an existance proof 
of a working flow.  I INVITE folks to put up or shut up on this one.

As an example of what goes wrong with reusing INVITE, take a forking proxy 
that does not Record-Route.  From RFC2543 all the way through bis-05, it is 
completely reasonable for a proxy to offer a service like Forward No Answer 
without needing to use Record-Route.  The flows below demonstrate some of 
the problems.

An INVITE (1) gets forked to B (1a).  If A sends a "early reINVITE" (2), it 
will go directly to B because the proxy did not record-route.  Other forks 
generated by that proxy don't do what they did in the past.  Specifically 
the proxy can't cancel its own branch because the CSeq for the CANCEL is 
stale.

comments welcome.

[i removed PRACKs for brevity, but nothing really changes.]

    |           |           |           |
    |INVITE(1)->|           |           |
    |           |INVITE(1a)>|           |
    |           |           |           |
    |           |<- 18x (1a)|           |
    |<- 18x (1a)|           |           |
    |           |           |           |
    |  ...      |           |           |
    |           |           |           |
    |- INVITE (2)---------->|           |
    |           |           |           |
    |           |<- 489 (1a)|           |
    |<- 489 (1a)|           |           |
    |           |           |           |
    |<------------- 18x (2)-|           |
    |           |           |           |
    |           |CANCEL(1a)>X  Stale    |
    |           |           |  CSeq     |
    |           |           |           |

Other potential scenarios

         A          Proxy        B           C
         |           |           |           |
         |INVITE(1)->|           |           |
         |           |INVITE(1a)>|           |
         |           |           |           |
         |           |<- 18x (1a)|           |
         |<- 18x (1a)|           |           |
         |           |           |           |
         |  ...      |           |           |
         |           |           |           |
         |- INVITE (2)---------->|           |
         |           |           |           |
         |           |<- 489 (1)-|           |
         |<- 489 (1)-|           |           |
         |           |-- INVITE (1b) ------->|
         |           |           |           |
         |           |<- 18x (1b)------------|
  Stale  X<- 18x (1b)|           |           |
  CSeq   |           |           |           |
         |<------------- 18x (2)-|           |
         |           |           |           |
         |           |           |           |

here is a working flow for early media using OFFER.

  A             Proxy           B             C
  |              |              |             |
  |-- INVITE --->|              |             |
  |              |-- INVITE --->|             |
  |              |              |             |
  |              |----------------- INVITE -->|
  |              |              |             |
  |              |<-- 18x ------|             |
  |<-- 18x ------|              |             |
  |              |<---------------- 18x ------|
  |<-- 18x ------|              |             |
  |              |              |             |
  |------------------ PRACK --->|             |
  |              |              |             |
  |-------------------------------- PRACK --->|
  |              |              |             |
  |<----------------- 200(PRACK)|             |
  |              |              |             |
  |<------------------------------- 200(PRACK)|
  |              |              |             |
  |<============================|             |
  |<==========================================|
  |              |              |             |
  |              |              |             |
  |              |              |             |
  |              |              |             |
  |------------------ OFFER --->|             |
  |<----------------- 200(OFFER)|             |
  |------------------------------- OFFER  --->|
  |<------------------------------ 200(OFFER)-|
  |              |              |             |
  |              |              |             |

thanks,
-rohan

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 13 Dec 2001 18:16:11 -0500

> are VERY BAD.  This is a non-backwards compatible change to SIP that breaks

Does 2543 actually disallow overlapping INVITE transactions or do you
mean non-backwards compatible with bis-xx?

> media, and the second is "that it might be useful in future."

It also makes for simpler code in some cases and allows for more
expedient operations.  INVITEs are now used for at least three different
purposes: modifying media setup, refreshing session timers, and checking
the status of a peer UA (eg because a media stream is failing). Allowing
overlapping INVITEs means it's not necessary to queue up, say, a mute
operation because a session refresh is in progress.

  The
> but when there is nothing to take away."

Well, this is removing a restriction so that should be OK :)

Anders