Subject: [SIP] Handling error conditions

From: "Suresh Srinivas" <[email-masked]>
Date: Mon, 25 Sep 2000 16:42:16 -0700

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.

Scenario 2:
   - Sending ACK (in response to 200 OK) failed at the UAC
Handling:
   Give disconnect indication. Go to Idling state when user disconnects the
call.
                OR
   Continue with the call ?

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.

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.
                     OR
    Return failure on the user interface for the action that triggered 
    the session parameter change and continue with the old session 
    parameters ?

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.
                     OR
    Continue with the old session parameters ?

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

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

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

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 26, 2000 1:50 PM
> To: Jonathan Rosenberg
> Cc: 'Suresh Srinivas'; "\"[email-masked]'\""
> Subject: RE: [SIP] Handling error conditions
> 
> 
> 
> Jonathan,
> 
> > >
> > > New call origination:
> > > ---------------------
> > > Scenario 1:
> > 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.
> >
> 
> I am curious to know why you prefer to send a BYE instead of a
> CANCEL.

Because in my caffeine deprived state somehow the "not" did not pass through
my brain correctly.

> If the 200 OK was not received, the Route is not established
> and hence the BYE may be difficult to route properly.

Yes. It should be CANCEL.

-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