Re: [stir] sipcore Digest, Vol 158, Issue 1

[Paul Kyzivat <[e-mail]>]

On 7/27/22 5:23 PM, [e-mail] wrote:
> Just a hunch, but I will speculate the phone companies will not want error messages going to the subscribers who didn't cause the error.  You can guess what actions they might take to prevent that.

While I think there are some voip apps that will render the Reason 
headers in a response to the users, I agree that for a typical user that 
would be confusing and so a provider wouldn't do it. But it could be 
quite helpful, and not bothersome, to capture that info in the phone's 
call history and provide a way for the user to query for it.

> Because STIR/SHAKEN errors in REASON headers should not be a possible cause of call failures (poorly defined rules for, or poorly considered implementation of, when to ignore the messages notwithstanding), STIR error messages in REASON headers should be informational only.

"Informational" is a name for a class of SIP response codes. There is 
guidance in SIP for how to handle particular response codes that you 
don't understand, based on their class.

In Reason headers, when the 'protocol' is SIP then the reason cause 
reuses the SIP response code values. But that does not mean that a 
reason cause is to be handled the same way as the same value received as 
a response code. (The proper handling is poorly specified and largely 
discretionary. Your examples show that this should be improved.)

There is nothing I'm aware of that says cause values that are in the 1xx 
range should be handled differently from cause values that are 4xx, 5xx, 
or 6xx.

And this gets even more problematic when you change the reason protocol 
from SIP to STIR.  I see *nothing* that says

   Reason: SIP ;cause=436 ;text="Bad Identity Info"
and
   Reason: STIR ;cause=436 ;text="Bad Identity Info"

should be treated the same way. IMO it would be *bad* for a provider to 
automatically fail a call when it receives provisional or successful 
response containing:

   Reason: STIR ;cause=4xx ;text="..."

Perhaps this needs to be clarified somewhere.

	Thanks,
	Paul