Subject: RE: [Sip] Bis-05 question: re-invite

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 23:42:11 -0500

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, November 02, 2001 1:02 PM
> To: Sriram Parameswar
> Cc: IETF SIP Mailing List
> Subject: Re: [Sip] Bis-05 question: re-invite
> 
> 
> Sriram,
> 
> If the session does not exist at the calling UA, it sends 
> back a 481. That
> is the only way the calling UA can tell the called UA that there is no
> session. This would be the case if the calling UA gave up 
> because it did not
> get the 200-OK response to the initial INVITE.
> 
> Maybe this section needs to point that out.

Section 12.2.1.2, on dialogs, does point out that a 481 should cause the UA
to terminate the dialog. However, it is worth referencing that in 14.1.

To answer Sriram's question - the 481 itself doesn't termiante the dialog or
the session. However, it triggers the UA to send the only message which does
terminate the dialog or session - the BYE. This distinction is subtle but
important, and worth clarifying in 14.1 as well.

-Jonathan R.

> ----- Original Message -----
> From: "Sriram Parameswar" <[email-masked]>
> To: "'Bob Penfield'" <[email-masked]>; "Christer Holmberg"
> <[email-masked]>
> Cc: "IETF SIP Mailing List" <[email-masked]>
> Sent: Friday, November 02, 2001 10:56 AM
> Subject: RE: [Sip] Bis-05 question: re-invite
> 
> 
> > Bob:
> >
> > I quote section 14.1
> > <quote>
> >   If a re-INVITE is responded with a non-2xx final response 
> the session
> >    parameters MUST remain unchanged, as if no re-INVITE had 
> been issued.
> > </quote>
> >
> > So I think receiving a 481 cannot mean that the session has 
> come to an
> end.
> >
> > Sriram
> > __________________________________________
> > Sriram Parameswar              Phone: 972-685-8540
> > Interactive Multimedia Server (IMS) Fax: 972-685-3563
> > Nortel Networks, Richardson USA  Email: [email-masked]
> >
> >
> > -----Original Message-----
> > From: Bob Penfield [mailto:[email-masked]]
> > Sent: Friday, November 02, 2001 8:23 AM
> > To: Christer Holmberg
> > Cc: IETF SIP Mailing List
> > Subject: Re: [Sip] Bis-05 question: re-invite
> >
> >
> >
> > ----- Original Message -----
> > From: "Christer Holmberg" <[email-masked]>
> > To: "Gonzalo Camarillo" <[email-masked]>
> > Cc: "Shan Lu" <[email-masked]>; "IETF SIP Mailing List" 
> <[email-masked]>
> > Sent: Friday, November 02, 2001 1:57 AM
> > Subject: Re: [Sip] Bis-05 question: re-invite
> >
> >
> > >
> > > Hi,
> > >
> > > Just a couple of clarifications I would like to get.
> > >
> > > Q1:
> > >
> > > >>If you have any confidence in the
> > > >>invite-200-ack retransmission scheme, the UAS should 
> consider the UAC
> > > >>down upon seven 200 oks and no ACK.
> > > >
> > > >It will re-INVITE, and if no answer for the re-INVITE is 
> received, the
> > > >session will be considered down.
> > >
> > > I would like to clarify how this re-INVITE is constructed.
> > >
> > > Is it a completely "new" INVITE, or is it constructed 
> like any mid-call
> > > re-INVITE (it uses the Tags etc received in the initial 
> INVITE from the
> > > other party)?
> >
> > It is constructed like any mid-call re-INVITE using the tags.
> >
> > >
> > > IF that is the case, the UAS (the previous UAC) MAY of 
> course return
> > > 481, becuase the reason it didn't send ACK in the first 
> place could be
> > > because it lost state of the call (since the INVITE has a 
> To header tag
> > > it assumes it is a re-INVITE for an existing call). Or, 
> it may still
> > > have state for the initial INVITE, but it simply never 
> received the 200.
> >
> > If the called party gets a 481 to its re-INVITE, it simple 
> considers the
> > session terminated. I think it is still recommended that it 
> send a BYE
> just
> > to make sure all the state is cleaned up in any intervening proxies
> (someone
> > please correct me if I am wrong).
> >
> > If the calling party never got the 200-OK, by this point 
> shouldn't it have
> > timed out and considered the session terminated? In that 
> case it would
> send
> > a 481.
> >
> >
> > >
> > >
> > > Q2.
> > >
> > > Chapter 14.1 says: "Note that a UAC MUST NOT initiate a new INVITE
> > > transaction within a dialog while another transaction (INVITE or
> > > non-INVITE) is in progress."
> >
> > The original INVITE is no longer in progress because it has 
> timed out or
> we
> > consider it complete because we are assuming the ACK from 
> the calling
> party
> > was lost.
> >
> > >
> > > I would just like to clarify how this affects overlapping. Since
> > > overlapping uses different Request-URIs in each INVITE, I 
> assume each
> > > INVITE represent a separate dialog, and are therefor not 
> affected by the
> > > rule in 14.1, right?
> >
> > No. This is a re-INVITE of the same dialog. The call-id and 
> tags are the
> > same.
> >
> > >
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > > _______________________________________________
> > > 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
> > >
> >
> >
> > _______________________________________________
> > 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
> >
> 
> 
> _______________________________________________
> 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 D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 8 Nov 2001 00:04:12 -0500

> From: Shan Lu [mailto:[email-masked]]
> Sent: Monday, October 29, 2001 6:15 PM
> To: IETF SIP Mailing List
> Subject: [Sip] Bis-05 question: re-invite
> 
> 
> Hi all,
> 
> Section 14.1, line 1937, "If a UAS generates a 2xx and never 
> receives an
> ACK, it SHOULD generate a re-invite with an offer equal to 
> last session
> description sent to peer."
> 
> I think this creates unnecessary burden on the UA and doesn't achieve
> much. If the re-invite is to change codecs, then the UAS would have to
> reserve DSP resources before it sends 200 ok. Now with this 
> requirement,
> the UAS has to keep the resource reserved for the duration of currect
> invite transaction (31 s) plus potentially another 31 s for the
> re-invite that it generates.

As we are talking about a rare and pretty much catastrophic kind of failure
case, optimizing DSP resources for it seems not that important. What we do
want to provide is robustness as much as possible, and that is the aim of
the re-INVITE. 

> invite-200-ack retransmission scheme, the UAS should consider the UAC

WHat you're proposing is not unreasonable (a BYE would still need to be sent
to clean up state anywhere that can see the BYE). I guess the question is
the likelihood of success of this re-invite given the previous invite
failed. THe idea is that a new transaction may successfully navigate through
some element that failed in the middle of a previous transaction. If people
feel its not likely than I would be amenable to simplifying by removing this
re-invite.

Interestingly, if a 2xx to an initial INVITE never generates an ACK, then a
BYE is sent. I must admit it seems odd that the behavior is different in the
two cases. This has been in there since bis-04. I've marked this one as
reopened in my tracking system.

Let's consider the case where the
> connection from UA1 to UA2 goes down after the intitial re-invite. UA2
> does not receive ACK for this re-invite. So UA2 generates its own
> re-invite. UA1 responds with 200 OK but never received by UA2. So next
> UA1 would re-invite. It's just a mess.

I don't think there is infinite recursion here, just one re-invite. If that
fails too then send a BYE.

> 
> Furthermore, if the initial re-invite has no sdp, what is the 
> benefit of
> having UAS resend its sdp offer? That is equivalent to having the UAC
> resend the re-invite upon no response.

New transaction.

> BTW, I believe section 14 should describe what happens when re-invite
> does not generate any response -- terminate the call.

Yup.

-Jonathan R.
---