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

From: Rohan Mahy <[email-masked]>
Date: Thu, 13 Dec 2001 11:33:31 -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: "Mark Watson" <[email-masked]>
Date: Mon, 17 Dec 2001 15:24:55 -0000

So, if I understand correctly, the problem is that using re-INVITE to update
the parameters (specifically the SDP) of an INVITE transaction (before it
completes) involves creating a completely new transaction and removing the
original one.

The new transaction is not seen by a Proxy which did not Record-Route,
whereas this proxy reasonably expected to be involved in the transation
which sets up the session (i.e. it didn't expect this transaction to be
superceeded before completion).

So, any solution has to leave the original INVITE transaction intact - i.e.
we need a request which will 'update' an existing INVITE transaction in the
'Proceeding' state.

Some questions:
1) Is it the parameters of the outstanding INVITE *transaction* that we want
to update, or the *dialog* that it created ?? The SDP would appear to be
associated with the dialog, rather than just the transaction, and the update
is going direct to the UAS, not necessarily through any (transaction)
stateful proxies, so it's more like the dialog we are updating.
2) are there any other parameters associated with a *dialog* that we might
want to update ?? (Could only ones which are of no interested to proxies
which have not Record-Route'ed)

What is the reason why a re-INVITE couldn't work in the way described above,
rather than that below - i.e. the re-INVITE would be responded to with an
immediate 200 OK, and the control of the session progress would remain with
the original INVITE transation ??

Regards...Mark

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: 13 December 2001 19:35
To: [email-masked]
Cc: [email-masked]
Subject: [Sip] Open Issue #113 : Overlapping INVITEs

Hi Folks,

comments welcome.

    |           |           |           |
    |INVITE(1)->|           |           |
    |           |INVITE(1a)>|           |
    |           |           |           |
    |           |<- 18x (1a)|           |
    |<- 18x (1a)|           |           |
    |           |           |           |
    |  ...      |           |           |
    |           |           |           |

         A          Proxy        B           C
         |           |           |           |
         |INVITE(1)->|           |           |
         |           |INVITE(1a)>|           |
         |           |           |           |
         |           |<- 18x (1a)|           |
         |<- 18x (1a)|           |           |
         |           |           |           |
         |  ...      |           |           |
         |           |           |           |

  A             Proxy           B             C
  |              |              |             |
  |-- INVITE --->|              |             |
  |              |-- INVITE --->|             |
  |              |              |             |

thanks,
-rohan