Subject: RE: [SIP] Killing hung media streams

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 02:45:43 -0400

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 11:19 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; [email-masked]; [email-masked]'
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> Jonathan Rosenberg writes:
>  > Lets say A and B are in a call, and B is a type of device 
> that if it fails,
>  > the call is over. When A detects this, through ICMP 
> errors, it should not
>  > bother with a re-INVITE, but rather, consider the call 
> over. On the other
>  > hand, if B is a type of device that, if it fails, a simple 
> re-INVITE will
>  > allow the call to be recovered at an alternate device (the 
> alternate would
>  > be figured out through downstream SRV or other routing 
> approaches), then A
>  > should send that re-INVITE immediately.
>  > 
>  > So, how does A know which to do?
>  > 
>  > I suppose we could mandate that a re-INVITE is always 
> done, and then, if a
>  > 481 is generated, the call is considered terminated. That 
> would generally
>  > work, I think, but would often be a waste. I suppose for 
> simplicities sake
>  > we could just specify that, although I could have sworn I 
> had come up with a
>  > reason you really needed to know....
> 
>    Unless there's some other reason, I would think that
>    this is just an implementation detail, and up to the
>    UA. The reason is that there are probably more reasons
>    to do a re-invite than just this. For example, I may
>    as a matter of course want my UA to reinvite if it's
>    on a flakey network (like, oh say, cellular) to help
>    smooth out bumps.

Things are implementation details when the result has no impact on other
systems. That doesn't seem to be the case here. Lets say I build a
conferencing server, and if it crashes, I can recover state by having the
far side send a re-INVITE to rebuild the call legs at a backup. Now, the
implementation detail at the far end dictates the service offered overall.
The conferencing server wants to tell the other side that a re-INVITE on
ICMP is the right thing to do.

Here is a third thing one might do upon an ICMP error - send a BYE. I can
construct cases where you really, REALLY want this. Specifically, third
party call control. Consider the case of a controller in a call with A and
B. A dies. A stops sending media. B detects this. B considers its call
terminated, but sends no messages. Now, A and B have destroyed call state,
but the controller is left hanging. The controller would prefer to get a BYE
in these cases. 

So, we have three things one might do upon detecting a failed media stream:

1. re-INVITE
2. send BYE
3. do nothing and consider the call down

My argument is that the right thing depends on the entity at the other end
of the call. To me, this means some kind of signaling is desirable to
communicate which mode is preferred. Of course, it can be refused or not
obeyed, but in the cooperating or non-conflicting cases, I'd like to be able
to do the right thing.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jun 2001 11:35:24 -0400

Snippet from Jonathan Rosenberg:

> communicate which mode is preferred.

In what situation would (3) be the right thing to do?
The only case I can see is when sip signaling is no longer possible.

It also seems like the re-INVITE *is* the signaling mechanism.
Then the overall recovery process is:

- reach conclusion there is a problem
- send re-INVITE, to test the state of the other end and to 
  request actions to recover from the problem
- if re-INVITE succeeds, continue with (hopefully fixed) session
- if re-INVITE fails, try to send BYE
- if BYE succeeds consider the call down
- if BYE fails, also consider the call down

This seems to cover all of the three things one might do that you 
mentioned. Sending the re-INVITE is optional if you know that it
will fail. Seems like this would only be if the problem is at this
end and there is no alternative to offer. Attempting to send the 
BYE shouldn't be optional.

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?

I don't see any headers that could be used in the reinvite to
signal this. Further, I don't think that the right level of
detail can be communicated via sip headers. It is possible that
the call involves several media, and that all are functioning
ok except for one. In this case, I need some way to indicate
what media need fixing. This seems to require some involvement
of SDP.

This isn't an implementation detail because it requires coordinated
actions by the two endpoints. So it really needs to be standardized.
Am I missing some existing explanation of how to do this?

	Paul Kyzivat
	Cisco Systems

---

From: [email-masked]
Date: Mon, 18 Jun 2001 11:29:53 -0500

> From: Jonathan Rosenberg

I'd argue that anyone implementing a 3pcc without using session-timer
is just asking for buckets of trouble.

I still feel quite strongly that negotiating this behavior at call
setup time adds too much complexity for the gain. If you always send
out a re-INVITE upon media failure, the systems can be made to do the
right thing.

/a