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

From: "Chiou, Mark" <[email-masked]>
Date: Mon, 10 Dec 2001 10:35:02 -0600

Hi,

Since SIP is a SIGNALLING protocol, It MUST have a well-defined error
handling procedure regarding media failure. Yes, I agree each media has
it own way to handle the media failure, but SIP shall specify a generic
behavior regarding the media failure and have a proper status code to
respond to the far end. SIP shall define the action to take when
receiving the status code.

Regards,

Mark Chiou

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Sunday, December 09, 2001 6:22 PM
To: [email-masked]
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:
> 
> > 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.
> 
> 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
> > 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
> >
> 
> _______________________________________________
> 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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Dec 2001 05:40:30 +0200

Hi,

I do agree that we must be able to handle media failures. And, yes, no
matter what we receive from MGCP/H.248/whatever it WILL most likely
trigger a SIP transaction. 

My point was that in many cases we may not always be able to send a
re-INVITE. It depends very much on the type of UA, the type of media
bearer, and if the nodes are separated also the protocol used between
them.

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.

Regards,

Christer Holmberg
Ericsson Finland