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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Dec 2001 15:32:59 -0500

Mark Watson wrote:

 > 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.

I think this is important for services, yes.

 >
 > 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.

For the pure early media case, its the neither - its the session 
parameters. But, we have the need in other cases to update parameters 
associated with the dialog, as a possible way to solve the 
heteroegeneous error response forking problem (HERFP).

As an example, lets say A sends an INVITE through proxy P that forks to 
UAS's B and C. That INVITE had an isup attachment. B doesn't understand 
that, so it rejects with 415. C understands it and rings (180). But, the 
user is not actually at C, they are at B, and B will never ring. This is 
the HERFP.

An alternative solution for HERFP is for B to return a 1xx that contains 
the error status. This is propagated to A, and A sends some kind of 
update to B without the ISUP. This then allows the dialog to proceed, 
and B's phone rings.

There are many landmines here, for certain...

 >
 > 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 ??

The reason is that INVITE has too many meanings. A 200 OK response to 
INVITE implies an active dialog and session, but thats not the case 
necessarily. A proxy that sees this re-INVITE will possibly be extremely 
confused about call state (indeed, the UAC may be confused). For 
example, if the second INVITE is responded to with 2xx as you suggest, 
and then the first is responded with 486, is the call up or not? If the 
two INVITEs did not overlap, the answer would be yes. But,  suspect its 
not in this case. That means call state is determined based on the 
relative timing of the two INVITEs, and that is dangerous, dangerous ground.

An explicit UPDATE or OFFER which updates the INVITE without having any 
impact on the dialog state would alleviate this problem, but will need 
to be understood by intermediaries like midcom agents, and this may 
introduce some complexities.

-Jonathan R.

 > -----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,
 >
 > 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
 >
 >

-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com

 >   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
 >
 >

-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com

 >   |              |              |             |  |------------------
 >  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
 >
 >

-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Wed, 19 Dec 2001 13:33:21 +0200

Hi,

>There are many landmines here, for certain...

I think the 1xx proposal is interesting. It's is true, however, that
there are a number of issues involved (not only to the 1xx proposal, but
to the whole update issue), which must be discussed, and here are two
"landmines" I think are worth mentioning:

1. 'A' may not want to (for whatever reason) send an update to 'C', so
in that case A would have to send a BYE to terminate that leg (A can't
send CANCEL, because that could terminate other possible legs too.

2. IF C sends 1xx, and does NOT receive an update (or BYE), how long
would
it wait for an update before it sends a final response? Or - should it
ASSUME that someone always terminates the leg (eg a proxy should send
CANCEL when the wait-for-a-final-response timer expires, or a UAC that
will send a CANCEL when the user hangs up).

Regards,

Christer Holmberg
Ericsson Finland