You didn't answer why step 3 exists. Why is A sending OPTIONS upon INVITE's 100 instead of waiting for an INVITE response that establishes a dialog?
Your call flow to send OPTIONS upon INVITE's 100 instead of waiting for an INVITE response that establishes a dialog is abnormal. Yes; per rfc4320, the 408 MUST NOT be sent. However some vendors are not yet compliant to rfc4320; and other vendors may interpret the rfc4320 restriction to only be applicable to the Timer F expiration type situation instead of other reasons to trigger a 408. From: Ayesha Shahab [mailto:[email protected]] Sent: Thursday, April 01, 2010 8:17 AM To: Brett Tate Cc: [email protected] Subject: Re: [Sip-implementors] Processing a 4xx, 5xx, 6xx response Hi Brett, Thanks for the info! At Step3, though 'A' sends out the OPTIONS to 'B'. It is not received at 'B'.. When 400 Bad Request response is received for the INVITE, the INVITE transaction is terminated and the dialog state is in 'Terminating' But then, because the TimerE fires , the OPTIONS is resent and this time, it is received at 'B'. B does not respond to this OPTIONS (As it wants it to timeout) Now when Timer F fires, because the dialog state is 'Terminating', the 408 Response is not sent by the stack.. I looked into RFC 4320 which you suggested and here is what I found - 4.2. Action 2 A transaction-stateful SIP element MUST NOT send a response with Status-Code of 408 to a non-INVITE request. As a consequence, an element that cannot respond before the transaction expires will not send a final response at all. So I guess the call flow to have 408 for the OPTIONS is incorrect? /Ayesha On Thu, Apr 1, 2010 at 4:59 PM, Brett Tate <[email protected]<mailto:[email protected]>> wrote: Concerning step 2, a 100 response does not create a dialog; thus step 3 is basically considered abnormal. What are you attempting to accomplish with step 3? Concerning step 7, send ACK. Concerning the expectation of 408 response to OPTIONS, see rfc4320. > -----Original Message----- > From: > [email protected]<mailto:[email protected]> > [mailto:sip-<mailto:sip-> > [email protected]<mailto:[email protected]>] > On Behalf Of Ayesha Shahab > Sent: Thursday, April 01, 2010 2:02 AM > To: > [email protected]<mailto:[email protected]> > Subject: [Sip-implementors] Processing a 4xx, 5xx, 6xx response > > Hi, > > For a non-established dialogs how do we have a 400 Bad Request response > ? > > The scenario is as follows > 1. A sends an INVITE to B > 2. A gets 100 trying response > 3. A sends lot many OPTIONS towards B > 4. B does not respond to the OPTIONS > 5. B responds with 400 Bad Request for the INVITE > 6. A receives a 400 terminate indication > 7. ??? > > What should happen at Step7? Do we terminate all the transactions > (INVITE > and OPTIONS) and bring down the dialog? > If we terminate all the transactions and bring down the dialog, we will > then > not receive a 408 Request Timeout response for the OPTIONS.. > > How should we handle a 4xx, 5xx , 6xx response for a non-established > dialog? > > /Ayesha > _______________________________________________ > Sip-implementors mailing list > [email protected]<mailto:[email protected]> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
