Subject: RE: [SIP] Handling error conditions

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2000 11:22:27 -0400

> -----Original Message-----
> From: Suresh Srinivas [mailto:[email-masked]]
> Sent: Monday, September 25, 2000 7:42 PM
> To: [email-masked]
> Subject: [SIP] Handling error conditions
> 
> 
> Could someone please validate if the following error 
> conditions are handled
> properly or 
> what is the right way to handle them. 
> 
> Regards,
> Suresh
> 
> New call origination:
> ---------------------
> Scenario 1:
>     - Sending INVITE failed at the UAC
>     - UAC did not receive response (or failed to parse 
> response) for INVITE
> Handling:
>    Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.
> 

Probably a good idea to also send BYE. Since no ACK is being sent, the call
will timeout at the UAS, but BYE makes it faster and more robust.

> Scenario 2:
>    - Sending ACK (in response to 200 OK) failed at the UAC

There is no way to detect this case at the UAC.

> Handling:
>    Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.
>                 OR
>    Continue with the call ?

THe UAS will never get the ACK, and thus the call times out at their end.
The UAC will probably think the call is up; session timer + human
interaction ("hello? hello!") will fix that.

> 
> Scenario 3:
>     - Sending response to INVITE failed at the UAS
>     - Did not receive ACK (or failed to parse ACK) for the 
> final response at
> the UAS
> Handling:
>    Disconnect the call and go to Idling state.

Yes.

> 
> Call is established, UAC sends INVITE to change the session params
> -------------------------------------------------------------------
> Scenario 1:
>     - Sending INVITE failed at the UAC
>     - UAC did not receive response (or failed to parse 
> response) for INVITE
>     - Sending ACK (in response to 200 OK) failed at the UAC
> Handling:
>     Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.

No; just the transaction fails.

>                      OR
>     Return failure on the user interface for the action that 
> triggered 
>     the session parameter change and continue with the old session 
>     parameters ?

Yes.

> 
> Scenario 2:
>     - Sending response to INVITE failed at the UAS
>     - Did not receive ACK (or failed to parse ACK) for the final 
>       response at the UAS
> Handling:
>     Give disconnect indication. Go to Idling state when user 
> disconnects the
> call.

No.

>                      OR
>     Continue with the old session parameters ?

Yes. 

> 
> Call disconnection
> -------------------
> Scenario 1:
>     - Sending BYE failed at the UAC
>     - UAC did not receive response (or failed to parse 
> response) for BYE
> Handling:
>     Go to Idling

Yes.

> 
> Scenario 2:
>     - Sending response to BYE failed at the UAS
> Handling:
>     Go to Idling

Yes.

Might be worth documenting this in a little table for the bis draft, as it
does come up every once in a while. I can add a few more cases:

for each of initial invite, re-invite, bye, other requests:

  UAC never receives any response at all
  UAC receives provisional response, but no final response
  
  UAS sends final response, never gets an ACK

  proxy never receives any response at all
  proxy receives provisional response, no final response
  proxy sends final response, never gets an ACK

possible actions are:
  send CANCEL
  send BYE
  ignore transaction
  terminate call

volunteers at a first cut? latex format preferred....

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: [email-masked]
Date: 26 Sep 2000 17:50:03 -0000

Jonathan,

> will timeout at the UAS, but BYE makes it faster and more robust.

I am curious to know why you prefer to send a BYE instead of a
CANCEL. If the 200 OK was not received, the Route is not established
and hence the BYE may be difficult to route properly.

If the UAC receives no response a UAC could timeout and send the CANCEL.

Thoughts?

Shiv

---

From: [email-masked]
Date: 26 Sep 2000 18:32:18 -0000

Just to clarify my question further, my contention is
that the UAC is unaware of the fact that final responses
were generated for it, even though it did not see it for
some reason. Being unaware it may end up sending a CANCEL.

I do agree the proxies want to see a BYE.

So is it fair to say for the sake of
robustness, in general a BYE should be sent for cancelling an
INVITE and allow it to route the way INVITE got routed,
without the luxary of the \'Route\' information.

Shiv