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

[[e-mail]]

I intentionally used 1xx and informational interchangeably.  My assumption is even if an implementation doesn't recognize a specific 1xx, they should at least know it was informational and something they would be "free to ignore".  This goes for the subscriber UA as well.

I think your comments are helpful and constructive.  I also agree that STIR as a separate protocol from SIP in the REASON should help prevent lesser implementations from killing calls that are otherwise acceptable.

Thank you again for taking the time to read and engage in the dialogue.

Best regards,

Pierce

-----Original Message-----
From: Paul Kyzivat <[e-mail]> 
Sent: Wednesday, July 27, 2022 5:29 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [stir] sipcore Digest, Vol 158, Issue 1

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