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

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 2 Nov 2001 09:56:04 -0600

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 2 Nov 2001 13:01:37 -0500

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.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 03 Nov 2001 16:09:11 +0200

Hi,

If we have a forking scenario and none of the UAS get the ACK, ALL of
them could send a re-INVITE. If 481 is replied to each of them we don't
have a problem, though.

Regards,

Christer Holmberg
Ericsson Finland