Re: [stir] New draft draft-rosenberg-stir-callback-00

["David Frankel" <[e-mail]>]

Hi Jonathan and Cullen –

 

I read the draft with interest and wonder if you can clarify a few things for me. My understanding of SIP nuances is limited, so I may be overlooking some obvious things here. At the same time, I’m trying to be pragmatic about how things work in the “real world” vs. the world as defined by the specs.

 

So my questions / comments are:

 

A) I see in section 3 references to SUPPORTED and REQUIRE header fields that include “stir-callback”. Then in sub-part 1 of section 3, in the call diagram I see references to SUPPORTED and REQUIRE headers that say “stir-verify”.  (Note, btw, that there are two sub-parts 1 in section 3; I think they are supposed to be numbered 1, 2, 3 instead of 1, 1, 2.) There are further references in the document to “stir-verify”. Then in section 8.1, there are references to a “sip-verify” Option Tag. 

 

So my question is: are “stir-callback”, “stir-verify” and “sip-verify” all meant to be the same string, and perhaps the exact value evolved during development of the document? Or are there really two or three different option-tags involved here? Or am I missing how these three different values are actually applied?

 

B) In the “real world”, a PSTN call from Bob (tel:1, served by Provider B), to Alice (tel:2 <tel:1> , served by Provider A) is often completed by B sending the call to transit provider X, which, even in an end-to-end SIP connection, will re-initiate the call and send it to provider Y, which then re-initiates it and sends it to terminating Provider A. (Note that the call path from B to A typically does not necessarily follow the reverse path of a call from A to B.)

 

So in order to propagate properly from origination to termination, the “verifying INVITE” proposed in section 3, containing the REQUIRE: stir-callback header, will need to first be processed by Provider X. As I understand it, X will need to be capable of recognizing the new REQUIRE header and knowing that it needs to propagate the call onward (NOT reject it due to lack of support for stir-callback), and will need to send the call to Y with the new REQUIRE header included. AND it will also need to know that it needs to propagate the VERIFY-CALL header as well.

 

Y will receive this INVITE, and it too will need to know that it needs to accept this invite and propagate it onward with the REQUIRE and VERIFY-CALL headers.

 

Since stir-callback is not today a defined option, if X and Y were conforming to the SIP RFC, they would today reject this INVITE. So does this mean that your STIR-Callback approach will necessitate updates of currently-conforming UA’s acting in the transit role to now provide support for this new type of INVITE?

 

Finally, if and when the verification INVITE gets to A, and as your document explains, A will have to be smart enough to process the verify request and send the appropriate response. That support is noted in your document; I’m wondering if you also need to document the kind of support that will be required from intermediate providers, and note the importance of A being RFC-compliant with respect to REQUIRE headers it does not understand.

 

C) At the end of section 3 you note: “The presence of the Require header field in the verifying INVITE is critical to the operation of the solution.  It prevents the verifying INVITE from actually ringing a real phone, which would be quite annoying.” This is my biggest concern.

 

If the new REQUIRE header gets dropped somewhere along the way, the INVITE will look “normal”, so won’t Provider A ring Alice’s phone? Or, if A is not RFC-compliant and ignores the REQUIRE header, Alice’s phone will ring. (And of course if the call originator was spoofing the number, and in fact Bob’s verification INVITE went to the real owner of the number, served by provider C, C would have to be RFC-compliant in this regard or the real number owner’s phone would ring.)

 

I am nervous that in today’s real world deployments, your approach is fragile because it is dependent on the various UA’s in the call path diligently following the SIP RFC.

 

I made a few test calls acting like I was Bob’s UA, having received an INVITE from A that I want to verify. So I sent an INVITE back towards A, inserting the REQUIRE: stir-callback header in my mock “verification” INVITE; I sent these calls through various real-world termination providers. 

 

In a couple of cases, I got back 420 Bad Extension responses. That’s good and bad; the good news is that it tells me that those particular UA’s ARE RFC compliant in this respect. They don’t understand a REQUIREd option so they are necessarily rejecting the call. On the other hand, it points out that if these UA’s are acting as intermediate providers (which, in these cases, they are), they will need to be updated to accept and pass the stir-callback related headers even though they are just providing a transit function and even though they are not assuming any responsibility for verification.

 

In my other test cases, the destination phone rang even though this was supposed to be a “verification” INVITE. This tells me, I think, that at least the first UA (X, in my explanation above) in the verification call path is non-RFC-complaint, and that downstream UA’s are either also non-compliant, or that the REQUIRE header got dropped along the way.

 

I am nervous about the extent to which deployed UA’s are non-RFC-compliant with respect to the REQUIRE header, and how that could undermine deployability of this solution. Maybe you intended that the solution only apply when A and B are directly connected and there are no intermediate providers. But I’m concerned that’s only a small fraction of “real world” calls today.

 

I am interested in your thoughts on these items, and on getting me back on track if I’ve misunderstood aspects of the proposal.

 

David

 

David Frankel

ZipDX® LLC

Monte Sereno, CA USA

Tel: 1-800-FRANKEL (1-800-372-6535)

 

From: stir <[e-mail]> On Behalf Of Jonathan Rosenberg
Sent: Thursday, March 1, 2018 6:15 PM
To: [e-mail]
Subject: [stir] New draft draft-rosenberg-stir-callback-00

 

Hey all - been a while :)

Cullen and I wrote up a concept for using STIR with self-signed or domain based certs, and then handling number validation with an in-band callback. We think its a promising approach to accelerate STIR deployments, since it allows them to happen without the cert infrastructure being in place. 

https://www.ietf.org/id/draft-rosenberg-stir-callback-00.txt

Comments welcome. 

-Jonathan R.



-- 

Jonathan Rosenberg, Ph.D.
[e-mail] <mailto:[e-mail]> 
http://www.jdrosen.net