Subject: Re: [Sip] Open Issue #207: Handling of session failures

From: Christer Holmberg <[email-masked]>
Date: Tue, 01 Jan 2002 13:21:05 +0200

Hi,

>>However, if the nodes are separated, and eg MGCP/H.248 is used between
>>them, those protocols may define other actions to be taken when media
>>failures occur. For example, MGCP allows the media handler to RELEASE
>>the call if the media "connection" is lost, so to be able to
>>re-establish the session a whole NEW session must be setup.
>>
>I think that is wrong. I don't think the media handler can release the
>call, it can only inform the MGC of errors.

That is true for H.248, but when using MGCP the media handler (ie the
Media Gateway) IS allowed to release the connection and send DLCX
(DeleteConnection) to the call controller (ie the Media Gateway
Controller).

Also, when using an ATM bearer there are some additional H.248 events
indicating bearer failures. Right now I don't remember if any of those
events indicate that the connection has actually been released, but I'll
look into that...

>That would be the "of" event in the MGCP RTP package. As such, the MGC can decide what to do, and in
>this case, the spec would say it SHOULD do a re-INVITE.
>>And, if the node is a gateway it may not be able to set up a new session in the
>>first place, since it's an end-user of either "side" of the gateway
>>which set up the session.
>>
> 
>This makes no sense whatsoever to me. The UA is in the gateway, and the
>RTP session handler is in the gateway. If a gateway detects failure of
>RTP, it can certainly send a re-INVITE.

Yes, IF all the resources on the PSTN (or whatever gateway we're using)
are still reserved, and the session has been "lost" only from a SIP
point of view. But, if some of the PSTN resources has also been
lost/released, sending a re-INVITE won't help, since the session would
have to be re-established also on the PSTN side.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 07:56:56 +0200

Hi,

Some more issues on this.

First, if the UAS has NOT (maybe because of media direction reasons etc)
noticed the media failure the re-INVITE will be treated like a any
re-INVITE, and if the SDP hasn't changed it will simply trigger a
response...

Second, IF the UAS has noticed the media failure it would also send a
re-INVITE (possible with new SDP parameters, if new resources must be
reserved) and we may get a re-INVITE race condition (see Open Issue
#139).

Third, if a intermediate SIP node (eg a SIP proxy controlling a media
server) detects the failure, it won't be able to do anything. Should it
then simply wait for the re-INVITE?

Fourth, I think that in many (most?) cases the failure will be in the
network, on a IP-or-lower level, and not in the SIP end nodes, in which
cases a re-INVITE won't help anyway...

Just my thoughts...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 12:19:58 +0200

Hi,

Just my thoughts...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 15:59:51 -0500

> re-INVITE, and if the SDP hasn't changed it will simply trigger a

Sure. In this case, the re-invite may not help, and then the call is BYEd.

> reserved) and we may get a re-INVITE race condition (see Open Issue

True, but it will get resolved, and if the re-invites don't help, a BYE 
would be sent (possibly by both as well).

> then simply wait for the re-INVITE?

What choice would it have? It can't tell there is a problem.

> cases a re-INVITE won't help anyway...

True, the re-INVITE only helps when the failure is in the sip nodes. 
But, it provides a fairly nice way to do e2e recovery for endpoint 
failures, and the cost is low, I believe (may not help, but won't hurt, 
and is not hard to implement).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 15:54:54 -0500

> (DeleteConnection) to the call controller (ie the Media Gateway

This does not release any calls, it merely informs the MGC of a failed 
connection. The MGC can still re-invite and then re-create the connection.

> have to be re-established also on the PSTN side.

In this case, it wouldn't reinvite, since there is also a local failure 
that cannot be repaired. The case we are talking about here is when a UA 
notices a media failure, but things are fine on its side, and so it 
attempts to help the other side reconstitute state with a re-invite.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 04 Jan 2002 08:30:43 +0200

Hi,

So, to summarize, the only times this will work is when: 

1. BOTH endpoints are aware of the media failure, and BOTH send a
re-INVITE.

2. One endpoint and one media aware proxy are aware of the media
failure, and the endpoint sends a re-INVITE.

In both cases the reason for the media failure must be in the SIP nodes,
on such a level that the re-INVITE will do any good.

I DO agree that it is easy to implement the re-INVITE, but I still think
the real-life situations where it will actually do any good are so few
so the text should say "MAY send a re-INVITE". 

Also, if the failure in the SIP nodes which caused the media failure
also caused lost of the SIP call state the re-INVITE won't help, since a
tagged re-INVITE will trigger 481.

>would be sent (possibly by both as well).

We should also remember that the re-INVITE race condition in this case
doesn't only affect the end-nodes. Assume that BOTH endpoints notice the
media failure, BOTH send re-INVITE, AND there is a media-aware proxy in
the middle. If that proxy is also aware of the media failure it must be
able to handle the re-INVITEs from both directions - or at least know
that there will be two re-INVITEs, so it can "wait" for the end-nodes to
solve the race condition... A normal proxy, which don't care about the
SDP, will of course not be affected by this.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 12:40:46 -0500

> failure, and the endpoint sends a re-INVITE.

I have no idea what a media aware proxy is or why it matters.

The mechanism handles the case where one of the two UAs in a dialog has 
failed, and a backup is to take its place. Rather than have state 
replication, the state at the backup is reconsituted via a re-invite 
from the far side. This works for a large class of UA, including 
conferencing servers and dialog servers. It would also work for any 
phone or PC app that could quickly recover after a failure.

> on such a level that the re-INVITE will do any good.

Yes.

> so the text should say "MAY send a re-INVITE". 

You miss the point.

The strength of the requirement is not related to the probability of its 
efficacy. Strengths are determined based on whether something won't work 
as expected if its not followed. If I am building a vxml server or a 
conference server, and I want to take advantage of this feature of sip 
to recover calls, I can only do so if the strength is SHOULD or MUST. If 
its MAY, I cannot count on it, and thus must engineer the ability to 
replicate dialog and session state to backups.

> tagged re-INVITE will trigger 481.

No, the re-invite can also re-establish dialog state in the backup. You 
should read 
http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt
if you have not alraedy.

> SDP, will of course not be affected by this.

Any media-aware intermediarty, such as a firewall proxy, must already be 
able to worry about the glare scenario. There is nothing it needs to do, 
since the endpoints will resolve the problem for it. In fact, so long as 
the firewall proxy handles the case where a re-invite fails, it will 
properly handle glare resolution.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 05 Jan 2002 03:37:49 +0200

Hi,

>should read http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt
>if you have not alraedy.

I don't have anything against what you propose in the draft. So, let's
continue the discussion based on that, because the issues I have are
pretty much the same.

Q1:

The draft does also, however, say that the re-INVITE may not work for
all nodes (eg PSTN gateways), so that's why I don't think it should be
general behaviour. Also, there may be some nodes (maybe the media
server) which from a functional point of view does not want to send a
re-INVITE. For example, if I call a media server from my SIP phone, and
the media server detects a media failure, it may not make such sense for
it to generate a re-INVITE, which may end up in my other phone...

Q2:

Chapter 5 says that the re-INVITE must arrive at UA3, ie the backup,
since UA2 generated ICMP. However, shouldn't the first re-INVITE be sent
by UA1 to UA2 (where the initial INVITE was sent) in any case, in case
the media failure was temporary, or UA2 did a quick reboot? Then, it
that fails the UA1 will try UA3 etc.

Also, if UA2 recovers by itself, and UA1 has contacted UA3 there is a
chance that UA2 will start sending media again, which may get messed up
with the media from UA3. UA2 may even detect a media failure itself (eg
if new ports were allocated by UA1 for UA3), so it may generate a
re-INVITE. AND, that re-INVITE may not even reach UA1 - at least not if
it's routed according to Chapter 5.

Q3:

Also, the draft doesn't say anything about the case where BOTH nodes
detect the media failure. Assume that both UA1 and UA2 detects the media
failure. The re-INVITE sent by UA1 may end up at UA3, and the re-INVITE
sent by UA2 may end up at UA4, in which case things may get messy. One
of my phones may send the re-INVITE, and suddenly my other phone starts
ringing... or something like that...

Q4:

About the "server group ID":

First, if it's only used only in the To tag, will it work if the CALLED
party generates the re-INVITE? 
Shouldn't the ID also be in the From tag, so that the re-INVITE works in
both directions of the call?

Also, does an empty ID value mean that no backup node exist?

I also think we should investigate if the "server group ID" you propose
affects issues like REFER, 3pcc etc. 
I am not saying it does affect, but IF... :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jan 2002 17:50:35 -0500

Christer Holmberg wrote:

> general behaviour. 

As I've pointed out, if its not at least SHOULD strength, it cannot be 
counted on, and it needs to be.

> Also, there may be some nodes (maybe the media

Your phone would normally 481 this because it contains tags. There is no 
risk of accidentally getting a call setup elsewhere.

> that fails the UA1 will try UA3 etc.

The assumption is of some kind of proxy which will definitively know 
about the failure of UA2 and route the request to UA3 instead.

> it's routed according to Chapter 5.

All of which can happen for any reliable system that maintains backups. 
This mechanism merely provides a nice distributed way to replicate the 
state. You still need to ensure consistent views of which element is 
actually up/down.

> ringing... or something like that...

See above. Requests are not generally routed to alternates gratuitously. 
  The above case would only happen if both ends actually fail 
simultaneously. I am not that concerned about this situation.

> both directions of the call?

It needs to be included in From/To, as appropriate, by any element that 
wishes to recover. However, since it is an implementation decision, it 
need not be standardized. Nothing about this concept needs to, or 
should, go into bis.

> I am not saying it does affect, but IF... :)

No, it does not. Please do not make issues where there are none. I am 
trying to resolve what I believe is a fairly minor issue, and I feel you 
are taking it farther and farther astray.

The issue is simple - on detection of a media failure, do we specify 
that a UA SHOULD generate a re-INVITE, in order to allow the far end to 
reconsistute session and dialog state in the event the media failure was 
due to a failed endpoint? The cost is low, the potential benefits are 
high. I say yes.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 08 Jan 2002 08:04:26 +0200

Hi,

>simultaneously. I am not that concerned about this situation.

NONE of the end nodes have to fail. BOTH may, however, detect the media
failure simuntaneously, due to an error in the IP network, in which case
BOTH would generate re-INVITE - and what I described above may happend.

>need not be standardized. Nothing about this concept needs to, or

I agree. And, since that's the case, I also wonder if using the tags is
the right way to go. A UA may not know to which "server group" it
belongs, or the group may change due to whatever reasons, so if we would
use a new header instead some administration proxy could insert that
header.

However, since this is NOT one of the major issues you listed in another
mail we should probably not spend too much time on it now, but let's
keep it in mind...

>due to a failed endpoint? The cost is low, the potential benefits are

What do you mean by "failed endpoint"? A SIP endpoint? Does this mean
that the node have to check that the ICMP message actually came from the
remote SIP user (and not, for example, from an intermediate router)
before it decides if to send a re-INVITE or not?

I do NOT have anything against adding what you propose as a SHOULD to
bis, but I would like the text to say that it should be done only when
the client is pretty sure that the remote SIP endpoint really has
failed, and that a re-INVITE would do any good. Otherwise the network
could be overloaded with "useless" re-INVITEs when there is a major
failure in the IP network, but the SIP nodes are working just fine... In
this case I think we would even avoid many of the issues above (Q3, for
example).

Also, the UA MUST have UAC capabilities (a media server MAY only have
UAS capabilities, for example) to be able to send the re-INVITE.

Also, we shall remember that the re-INVITE race condition case is still
an open issue. YES, we WILL (I hope :) solve it, but we do NOT yet know
HOW it will be solved.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jan 2002 14:03:44 -0500

CHANGE IN DIRECTION OF THIS ISSUE - read below!! (I suspect most have 
not been following this thread)

>>>detect the media failure. Assume that both UA1 and UA2 detects the
>>>media failure. The re-INVITE sent by UA1 may end up at UA3, and the
>>>re-INVITE
>>>of my phones may send the re-INVITE, and suddenly my other phone
>>>starts ringing... or something like that... 
>>>

True, but you are asusming above that those re-invites are routed to 
different servers. They are regular in-dialog requests, and unless there 
has been an element failure that invokes srv or failure processing at a 
proxy, it will be delivered to the proper UA.

> before it decides if to send a re-INVITE or not?

No, you are reading too much into the statement.

> this case I think we would even avoid many of the issues above (Q3, for

Now, THIS is a good point.

A network failure, could trigger a storm of INVITEs which might only 
make the situation worse.

OK, I am willing to concede that use of the mecahnism when you don't 
know that it is the endpoint that failed, could be quite bad.

So, since:

(1) it could actually hurt alot
(2) it is possible to add this later through an extension (Supported: 
reconstitute in INVITE, Require: reconstitute in 2xx)
(3) you can't COUNT on it being there anyway, since its not in rfc2543 
or many versions of bis

I will back off and we will punt this to an extension if people still 
feel it is valuable, but we do need to do some work to make sure that it 
works properly, and I don't want to hold up bis on it.

In place of this, I would propose that the proper endpoint behavior on 
detection of media failure is a matter of local policy; however, 
automated generation of BYE or re-INVITE is not recommended to avoid 
flooding the network with traffic (the user will likely hang up 
themselves). If these messages do need to be sent automatically, they 
should be sent after some randomized interval.

Thanks,
Jonathan R.