Subject: RE: [SIP] Killing hung media streams

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 03:05:05 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 18, 2001 12:30 PM
> To: 'Jonathan Rosenberg'; 'Michael Thomas'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg
> >
> > 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. 
> 
> 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.

Having thought about this some more, I am inclined to agree at this point.
If a re-INVITE is always sent, the far end can (1) accept it, potentially
re-establishing the session elsewhere if it can, or (2) reject with a 481,
which will cause the UAC to believe the call is down. Intermediaries (like a
3pcc controller) would see the 481 and also determine that the call is down.

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.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Jun 2001 22:12:18 +0300

Hello,

> 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

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