Subject: RE: [SIP] Killing hung media streams

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 27 Jun 2001 03:52:32 -0700

The only problem here is if either
a)	UA does not send the BYE or if more specifically,
b)	a Record-Routed proxy sees the 481 and tears down the call. Further
Record-Routed proxies will then never see the BYE generated by the 481.

So now you need to mandate that a proxy MUST not consider a call torn down
because of a 481 to a re-INVITE - which puts us back at square one. It seems
to very strange (and risky) that one UA can clearly indicate that the call
has been torn down but the proxies MUST ignore this indication. This means
that all record-routing proxies in a call-leg (and UA's) must conform to
bis-04 to avoid zombie call-leg's in this situation! 

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jun 2001 14:59:21 +0300

Hi,

Some small comments.

First, one could argue that this has nothing to with SIP, since SIP is
signalling and media is another thing. For example, a client could have
some kind of internal mechanism to make sure that it doesn't have any
active media streams without a matching call state. However, my comments
are on SIP.

I don't think that a proxy should consider a call torn down if it
receives 481, and especially not then ASSUME that the UA does the same.
In this case one could argue that the proxy should generate BYE
transactions in both directions, to torn down the call at the UAs, and I
don't think we want to go into that discussion... One could also argue
that the UAS(!) should send a BYE after it has sent 481, and I don't
think we want that either...

I think the idea behind the session-timer is for the UA to make sure
that proxies don't loose call-state, by sending re-INVITEs, so why can't
the UAs then also tell the proxies that the call doesn't exist anymore
if 481 is received, by sending BYE?

However, like Gonzalo mentioned, it is not mandatory for a UA to
understand the specific 481 response code, so in any case I think it
could only be a RECOMMENDATION/SHOULD to send BYE.

One option is to simply have it as an implementation issue. Some clients
may then even have it as a configuration variable, depending on what the
user/network provider/whoever wants.

Another option is to add a Supported/Require option-tag (I use 'relBYE'
as an example...), to indicate the sending of BYE when 481 is received
as a FEATURE.

example:

UA1                   UA2

-----INVITE------------->	
     Supported: relBYE
<----200-----------------
     Require: relBYE

//UA1 is required by UA2 to send BYE if UA1 at any stage receives 481

..or..

-----INVITE------------->	
     Supported: relBYE
<----200-----------------
     Supported: relBYE

//Both UAs will now send BYE if any of them at any stage receive 481
     
..or..

-----INVITE------------->	
     Require: relBYE
<----200-----------------
     Supported: relBYE

//UA1 requires UA2 to send BYE if it at any stage receive 481

..or..

-----INVITE------------->	
     Supported: relBYE
     Require: relBYE
<----200-----------------
     Supported: relBYE

//UA2 is required to send BYE, and UA1 indicate that it will also send
BYE, if
//at any stage 481 is recieved

The use of the 32 seconds, mentioned by Robert, is also an option, but
again I don't think it shall be a MUST. Maybe it could also be a
feature, indicated by some Proxy-Require option-tag...

Comments?

Regards,

Christer Holmberg
Ericsson Finland

"Fairlie-Cuninghame, Robert" wrote:
>   a. UA does not send the BYE or if more specifically,
>   b. a Record-Routed proxy sees the 481 and tears down the call.
>      Further Record-Routed proxies will then never see the BYE
>      generated by the 481.
> 
> So now you need to mandate that a proxy MUST not consider a call torn
> down because of a 481 to a re-INVITE - which puts us back at square
> one. It seems to very strange (and risky) that one UA can clearly
> indicate that the call has been torn down but the proxies MUST ignore
> this indication. This means that all record-routing proxies in a
> call-leg (and UA's) must conform to bis-04 to avoid zombie call-leg's
> in this situation!
> 
> 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.
> 
> Robert.
> 
> Cc:     [email-masked]'; 'Michael Thomas';
> [email-masked]; [email-masked]
> > it should consider the call down, and does not mandate that a BYE
> should be
> > sending a BYE is for call-stateful boxes in the middle. It gives us
> the nice
> > So, I would propose that text be added to bis-03 which further
> mandates that
> > problem if one of its media streams has failed. How it knows this
> depends on
> > presumably the MGC can detect this, and therefore do something about
> it when
> > the re-INVITE arrives.
> >
> > 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Jun 2001 18:10:38 +0300

Hello,

> 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