Subject: RE: [SIP] Killing hung media streams

From: [email-masked]
Date: Fri, 10 Aug 2001 14:51:35 -0600

Sorry to dredge up this thread again, but in reading through it, I didn't
get the impression there was consensus on what to do, and didn't notice
anything in bis-04 that addressed it.  Getting back to the original issue
that prompted it (though many varied needs were voiced), say we have a UA
that gets media it is not expecting as it has no corresponding session.  The
early consensus seemed to be to send ICMPs.

 The desire of that UA is to get the sender to stop the stream.  This is my
main concern with this thread.  The sender of the stream may desire to
attempt to re-establish the session, or may desire to kill the session it
believes was active and associated with the stream.  This seems to be an
implementation specific decision, though communicating that desire may be
something that is a protocol issue.  What should the UA sending the media do
when it gets ICMPs in either case?

 In my envirenment, I could live with either action taken by the UA, but
need some action(s) standardized, rather than the current inaction.  In the
first case (re-Invite), I would establish a new session which would likely
be to a different media address/port, and expect the UAC to stop sending to
the first port.  In the second case, I would send a 481 if a BYE for a
non-existent session was received.

 Note that there was discussion in the thread of sending a 481 response to a
re-Invite.  At least in my environment, we would send the ICMPs because we
have no session associated with the received stream.  Hence we may not have
state for that session, and would recognize the Invite as a new session and
not a re-Invite, so could not be expected to send a 481.

John Hearty
Level 3 Communications, Inc.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 9:11 AM
To: Fairlie-Cuninghame, Robert
Cc: Jonathan Rosenberg; [email-masked]
Subject: Re: [SIP] Killing hung media streams

Hello,

> Perhaps something along the lines that a proxy MAY use a 481
> inidication to remove a call from a active call-state; however, call
> state must be retained for at least 32 seconds so that BYE requests
> may be propagated to all record-routed proxy.

If a proxy considers the call down when the 481 is received, it will
just have to route the BYE that will be received later as an
out-of-the-blue BYE. Since the BYE will have record-route, I do not
think this is a major problem.

Regards,

Gonzalo

> 
> Robert.
> 
> -----Original Message-----
> From:   Gonzalo Camarillo [mailto:[email-masked]]
> Sent:   Tuesday, June 26, 2001 8:12 PM
> To:     Jonathan Rosenberg
> Cc:     [email-masked]'; 'Michael Thomas';
> [email-masked]; [email-masked]
> Subject:        Re: [SIP] Killing hung media streams
> 
> Hello,
> 
> > So, this begs a related question, which Pauls email introduces. If
> we say
> > that a 481 to the INVITE means the call is down, does that mean the
> UAC
> > should issue a BYE, or just destroy the call state? Right now,
> bis-03 says
> > it should consider the call down, and does not mandate that a BYE
> should be
> > sent (since, in any case, it will also result in a 481). The
> advantage of
> > sending a BYE is for call-stateful boxes in the middle. It gives us
> the nice
> > property that a call is always terminated by a BYE, even if
> triggered as a
> > result of some other event in the SIP signaling path. This reduces
> the
> > number of cases that devices need to worry about.
> 
> With this addition we basically recover the nice feature of treating
> unknown 4xx reponses as 400. SIP entities that do not understand 481
> will be able to treat a 481 received as a 400. That is, 481 indicates
> that the request failed (as any other 4xx response), but it does not
> indicate that the session has been terminated. This will still be
> indicated by a BYE.
> 
> Best regards,
> 
> Gonzalo
> 
> >
> > So, I would propose that text be added to bis-03 which further
> mandates that
> > a BYE be sent upon receiving a 481 to a mid-call request. Any
> objections?
> >
> > Paul also wrote:
> > > But there are some issues with the re-INVITE that I don't
> understand:
> > >
> > > If I believe the problem is with my end, and there is something
> > > I can change (e.g. in my SDP) that would help solve the problem,
> > > then of course I can offer that.
> > >
> > > But it seems like either I will believe the problem is with the
> > > other end, or else I will have no idea where it is and have no
> > > idea what kind of change might help. Suppose I have received ICMP
> > > errors on my sends, and suspect the port I am sending to, or the
> > > path to it, are down. When I send a reinvite, there is nothing
> > > obvious for me to change in *my* SDP - I want the other end to
> > > offer me something that will work better. So perhaps I send
> > > unchanged SDP. When the other end receives this, it may have no
> > > idea that anything is wrong. How does it decide that it should do
> > > anything other than send unchanged SDP back?
> >
> > Well, its the job of the user at the other end to know that there is
> a
> > problem if one of its media streams has failed. How it knows this
> depends on
> > the device. In the case of a decomposed gateway, if the gateway
> fails,
> > presumably the MGC can detect this, and therefore do something about
> it when
> > the re-INVITE arrives.
> >
> > The interesting case is when the failure in the media stream is not
> due to
> > either endpoint, but rather something in the network. In this case,
> a
> > re-INVITE won't help, as it will change nothing (both sides offer
> the same
> > SDP as before). In this case, you UA has to know to stop re-INVITing
> after a
> > while, if the re-INVITEs don't eventually solve the problem. I
> suspect this
> > will be a rare case, since if the media fails due to a network
> failure, the
> > signaling will probably fail as well.
> >
> > -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
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/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://www.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://www.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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 15:29:24 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 4:52 PM
> To: [email-masked]
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> 

That has little to do with SIP, and will just happen in the OS since no one
is listening on that port anyway.

> when it gets ICMPs in either case?

My recommendation is this. If a UA is in a call, and begins getting ICMP
errors on a media stream, and wishes to continue with the call, it SHOULD
send a re-INVITE on that leg. 

As an orthogonal issue, if a UAC receives a 481 to a mid-call re-INVITE, it
SHOULD tear down the call by sending a BYE.

For your case, the re-INVITE will trigger a 481 since the call is not known
and not wanted at this server (the Tag indicates its a re-invite), and thus
the call is torn down and the media stops.

> non-existent session was received.

Well, as I mentioned above, the call is not likely to be established in the
general case (although it can if recovery is what is desired).

> not a re-Invite, so could not be expected to send a 481.

Tag in the To field = re-INVITE. The process is described in section 15.5 of
bis-04 (although it says nothing yet about sending a BYE after getting the
481. Thats the proposal.)

-Jonathan R.

---

---

From: Doug Hurtig <[email-masked]>
Date: Wed, 22 Aug 2001 16:43:48 -0500

Hi,

  Why must the UAC send a bye when a 481 is received? I thought that the
  481 implies that the call leg is terminated. Section 15.5 states that
  "A UAC receiving a 481 response for any mid-call request (INVITE or otherwise)
  MUST consider the call terminated."

Doug

---

From: [email-masked]
Date: Thu, 23 Aug 2001 14:32:24 -0600

> SHOULD tear down the call by sending a BYE.

This sounds great.  In addition, a recommedation for the case where a UA
begins getting ICMP errors and does not wish to continue the call should
also be noted.  Sending a BYE in this case as well seems consistent with
your position below.  If there is no objection, can we get modified language
in the bis indicating these behaviors?

John Hearty

> From: Doug Hurtig [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 5:44 PM
> To: [email-masked]

Thats the problem. I think this text is wrong. It should send a BYE, and
then consider the call terminated as a result.

Why? Well, we have a general rule that a non-2xx response to a re-INVITE
does not mean the call is dead. Only BYE terminates a call. I'd like to keep
that rule, since it provides a single, consistent way for everyone to
say/know whether the call is up or down.

I feel very strongly about this one. Having multiple ways of signaling that
a call is down is very bad, IMHO.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Aug 2001 03:14:39 -0400

> Sent: Thursday, August 23, 2001 4:32 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > As an orthogonal issue, if a UAC receives a 481 to a 
> mid-call re-INVITE,
> it
> your position below. 

Yes, thats fine. But, I want the text to be clear that this is only if you
really have some other reason for not continuing. A triggered re-INVITE on
ICMP errors does wonders for reconstituting state and providing fault
tolerance. Most of the times, that is what you want.

> If there is no objection, can we get 
> modified language

Fine by me. Speak up folks, or the text is going in....

-Jonathan R.
---

---

From: [email-masked]
Date: Fri, 31 Aug 2001 08:41:21 -0600

Agreed.  Most of the intelligence belongs at the edge.  Hummm.

-----Original Message-----
From: Anders Kristensen [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 10:08 PM
To: Jonathan Rosenberg
Cc: [email-masked]'; [email-masked]
Subject: Re: [SIP] Killing hung media streams

Jonathan Rosenberg wrote:
> 
> Well, someone needs to change. Either UA's change to send BYE, or proxies
> and other elements change to support 481 indicated call termination. I
> generall prefer pushing intelligence out towards the edge.
> 
> Let us definitely resolve this quickly. Please, if you have an opinion,
> POST!

Seems more regular to insist on having UACs always send BYE. Consider
this a HUM in favor of that approach. Hummmm.

Anders