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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 11:41:25 -0500

Issue:

The spec is silent on what a UA should do if failures in the media sessions 
occur (ICMP, timeouts, or media specific errors). I think something should
be 
said. draft-rosenberg-sip-reconstitute-00.txt talks a lot about this
problem; 
nearly all of that is local implementation logic, but one piece that
requires a 
normative change to the spec - if you detect a failure in media stream, send
a 
re-invite to see if that repairs it. 

The re-invite will help if the failure is due to a end system failure. In
that case, the re-INVITE will reconstitute the dialog and session state at
an alternate, which is helpful and useful in many cases. It won't do much at
all if there was a network failure.

If the re-INVITE fails, or nothing changes in the media stream, you SHOULD
then send a BYE.

I'd like to incoroporate this piece of logic into bis.

Proposal:

UAC SHOULD re-INVITE with same SDP when it detects failures in the media
session.
If re-INVITE doesn't help, SHOULD send a BYE

-Jonathan R.

---
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: [email-masked]
Date: Mon, 10 Dec 2001 09:21:05 -0700

I originally brought this issue up in the Killing Hung Media Streams
thread, and it was in fact separated MGs and MGCs that caused the problem
(MGC thought the call was over, MG happily continued sending RTP).  My main
goal was to have the end receiving ICMPs do something to figure out if there
was a valid session, and either reconstitute it or stop sending RTP.
Anything would be better than no action at all.

 If there are already mechanisms in protocols between MGs and MGCs that take
some action, great.  Otherwise I am agreeable to softening the language to
MAYs and including a little example or explanative text.

John Hearty
Level3

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Sunday, December 09, 2001 5:22 PM
To: Hearty, John
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Open Issue #207: Handling of session failures

Hi,

If the same node is handling both media and signalling I guess the
proposal is ok.

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

So, since SIP is a SIGNALLING protocol I don't think there shall be any
SHOULDS or MUSTS on how to handling failures on the media level. Of
course, it may be mentioned as an example on a case where a re-INVITE
may be used.

Regards,

Christer Holmberg
Ericsson Finland

[email-masked] wrote:
> > an alternate, which is helpful and useful in many cases.
> 
> Assuming that end system is capable of reconstituting state from a
> re-Invite.
> That said, I agree with this proposal.
> 
> John Hearty
> Level3
> 
>  It
> > won't do much at

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 11 Dec 2001 19:35:08 -0000

Why is this not a SDP level requirement, rather than a SIP level
requirement. The requirement you are writing is to send a new UDP (which
just happens to be sent in an INVITE) rather than a INVITE itself.

As a result, this becomes out of scope of the bis-draft.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Christer Holmberg[SMTP:[email-masked]]
> Sent: 	10 December 2001 0:22
> To: 	[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 02:02:06 -0500

Responses inline:

> That said, I agree with this proposal.

No, its not the side that reconstitutes that sends the re-INVITE. Its 
the other side, and it would need to do this even if it can't spell 
reconstitute.

Here's the scenario. A and B are in a call. B fails. ICMP errors go back 
to A for the media packets. A can't reconstitute anything, but sends a 
re-INVITE on the hopes that the other side possibly can (and the ICMP 
are due to a failure of this sort). B' (B's backup) gets the re-INVITE, 
knows how to reconstitute state, and does.

See, thats the rub. For an element to reconstitute state, the OTHER 
element has to send the re-INVITE. Thats why it needs to be in bis.

Christer Holmberg wrote:

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

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.

> As a result, this becomes out of scope of the bis-draft.

Actually, there is SIP state too. If the goal is to allow reconstitution 
of state at a backup, that would include BOTH the session level state 
AND the SIP state (cseq numbers, route sets, etc.). Thus, it is an issue 
for SIP.

Christer also wrote:

> My proposal is that we write that the node MUST take action(s) to
> prevent the signaling- and media handler to have different "session
> state". If possible it MAY send a re-INVITE trying to re-establish the
> session, otherwise send a BYE to terminate it.
> 

Let me say a few words on whether or not we need to give a specific 
recommendation, or allow the UA to do anything it wants. The issue here 
is interoperability. If someone wants to build a conference server, they 
need to know - do they HAVE to replicate sip and session state in the 
event of a failure, or can they rely on a peer UA to help reconstitute 
the state at a backup. If the text says "SHOULD" send a re-INVITE, then 
they know they can count on the peer UA. Otherwise, if its just MAY send 
re-INVITE, or MAY BYE, they need to handle failures of a conference 
server, and hide such failures completely, so that they don't manifest 
themselves as any kind of ICMP errors (which might cause the peer to BYE).

-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: [email-masked]
Date: Thu, 27 Dec 2001 10:11:05 -0700

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, December 27, 2001 12:02 AM
> To: Hearty, John
> Cc: [email-masked]

 I understand and agree with this.  My one liner with "that end system"
apparently was not clear which end system is doing the reconstitution and
which end is obligated to send the re-Invite.  I only mentioned this line to
clarify that reconstition might not happen, after seeing "In that case, the
re-INVITE will reconstitute..." in the original thread.  The word WILL
bothered me.

 I'd also like to comment on your few words at the end.  I think it is
important that we avoid strengths like MAY and stick with SHOULD, mainly so
BOTH ends clearly know what state the session is in.  Your proposal does
this nicely, resulting in either a reconstituted session or a 481 from the
peer the re-Invite was sent to.  I strongly support the proposal as it
stands.