Subject: [Sipping] Re: dialog event package: event code

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Apr 2003 22:31:06 -0400

responses inline.

Volker Hilt wrote:
> Hi all,
> 
> I don't know if the following issue has already been discussed on the list.
> 
> The dialog event package defines a way of reporting dialog state to
> another user. The dialog information format (the default payload format
> for dialog event NOTIFYs) contains information about the current dialog
> state and it may provide information about the event that has caused the 
> state transition. Here's what the draft says:
> 
> 3.1.2 State
> 
>    The state element indicates the state of the dialog. Its value is an
>    enumerated type describing one of the states in the FSM above. It has
>    an optional event attribute that can be used to indicate the event
>    which caused the transition into the current state, and an optional
>    code attribute that indicates the response code associated with the
>    transition, assuming the event was 1xx-tag, 1xx-notag, or 2xx.
> 
> My question refers to the last sentence of this section: what is the
> reason for restricting the reporting of response codes to 1xx and 2xx
> events? Wouldn't it make sense to also allow the reporting of response
> codes for rejected events and possibly also for error and timeout
> events? (Btw. the schema definition already allows codes between 100 and
> 699.)

I can't think of a particularly good reason, to be honest. I think it 
would be fine to include the response code for any event caused by a 
response. I'll make the change in the next rev (which is probably going 
to be the result of AD comments, as I believe this doc is ready to go to 
IESG).

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Volker Hilt <[email-masked]>
Date: Mon, 14 Apr 2003 16:28:35 -0400

Hi all,

3.1.2 State

This would allow the subscriber (e.g. a call logging application) to
better understand why a call has failed (e.g. differentiate between a
486 Busy Here and a 404 Not Found).

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

---

From: Volker Hilt <[email-masked]>
Date: Tue, 15 Apr 2003 10:31:49 -0400

Jonathan Rosenberg wrote:
>> state and it may provide information about the event that has caused 
>> the state transition. Here's what the draft says:
>>
>> 3.1.2 State
>>

Great!

Thanks,

Volker