Re: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

["Worley, Dale R (Dale)" <[e-mail]>]

From: [e-mail]
> Question is if we could make the Reason optional instead mandatory
> for cases where the retargeting was based on a SIP Response?
> 
> I cannot see what will break if we do it as a option. (For Call
> forwarding it is important that we can count the real
> forwarding's. It is not really important on which the forwarding's
> are based.)

Since 4244 does not require Reason headers, any implementation should
be able to cope with with the absence of Reason.

However, there is a subtle aspect:  In the current 4244bis, it seems
that the presence of a Reason header on a history-entry documents that
the request carrying that URI has completed (and returned the
specified response).  If I'm correct in this, omitting a Reason header
has an additional meaning and so can't be made optional.

> Next Question is if we could use instead the RFC4458 causes with
> further values. I know I asked already this question but I didn't
> get a clear answer why not to use. RFC4458 does define this causes
> not only for the cases Voicemail and IVR, it says: "such as".
> 
> What are the opinions on that.

If I understand RFC 4458 correctly, the 'cause' URI-parameter is added
to the "new" URI to indicate the reason it was generated or used.
Assuming History-Info shows how and why each request-URI was
generated, the 'cause' URI-parameter is redundant.

However, if we define further 'cause' values, it might provide
additional information.

> Within ISUP the Redirecting reason is within the Redirection
> Information Parameter included which is not bind to any of the
> Numbers. It is a own Parameter. So there are not the problems where
> and how to place the "cause"

It does seem to me that this causes a problem in interworking, but I
might be wrong.

Dale