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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 01 Nov 2001 22:12:07 +0200

Hello,

Shan Lu wrote:
> 
> 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)

We have decided that the protocol retransmits during that amount of
time, so one cannot say that the transaction has failed after this timer
has expired.

> plus potentially another 31 s for the
> re-invite that it generates.
>
>
> 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.

Regards,

Gonzalo

 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.
> 
> 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.
> BTW, I believe section 14 should describe what happens when re-invite
> does not generate any response -- terminate the call.
> 
> Shan Lu
> sentitO Networks
> 
> _______________________________________________
> 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

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
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: Fri, 02 Nov 2001 08:57:12 +0200

Hi,

Just a couple of clarifications I would like to get.

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

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.

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

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?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 2 Nov 2001 09:22:55 -0500

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

> re-INVITE (it uses the Tags etc received in the initial INVITE from the

It is constructed like any mid-call re-INVITE using the tags.

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

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

> INVITE represent a separate dialog, and are therefor not affected by the

No. This is a re-INVITE of the same dialog. The call-id and tags are the
same.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 02 Nov 2001 22:39:12 +0200

Hi,

>No. This is a re-INVITE of the same dialog. The call-id and tags are the

So, no more overlapping in SIP, right?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Nov 2001 23:20:55 +0200

Hello,

> So, no more overlapping in SIP, right?

There are two things that are called overlapping. Once is that
possibility of creating overlapped SIP transactions, like sending an
INFO before another INFO has been answered with a 200 OK. Whether this
is allowed or not is still an open issue whose number I do not remember
right now.

The other overlapping scenario is the ISUP-SIP overlapping draft. There
the subsequent INVITEs do not use tags and do not belong to the same
dialog, so this rule is not applicable.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 02 Nov 2001 23:36:03 +0200

Hi,

>dialog, so this rule is not applicable.

Sorry, I meant the ISUP-SIP, ie digit overlapping, case.

To my understanding, we once did agree that the INFO overlapping IS
allowed, and that the UAC therefor should receive a 18x with a To tag as
soon as possible. That is also the reason why we (me included) proposed
that a UAS (not proxy) shall always send a 18x with a To tag as soon as
it receives the initial INVITE (unless they send a final response right
away, that is). Otherwise we would eg have to implement buffering also
when we do ISUP transparency...

Regards,

Christer Holmberg
Ericsson Finland