Subject: [Ecrit] Phone BCP: Testing

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 30 Mar 2008 22:56:09 +0300

You write:

"
   ED-78 INVITE requests to a service URN ending in ".test" indicates a
   request for an automated test.  For example,
   "urn:service.sos.fire.test".
"

I am not sure whether one can actually add a .test to the defined URNs
without registering a new set of URNs. Have you checked that?

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 30 Mar 2008 16:22:26 -0400

Henning, your call.  Should we register them?

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Sunday, March 30, 2008 3:56 PM
To: [email-masked]
Subject: [Ecrit] Phone BCP: Testing

You write:

"

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Mar 2008 12:06:56 -0400

This is one of the topics that requires more discussion. There are  
several possibilities:

(1) Register a .test for every service. That seems inelegant if we  
assume that just about every service will need this. This also doesn't  
quite fit when we want to subset services, such as

urn:service:sos.police.postal
and
urn:service.sos.police.transport

since police.test is not parallel to police.postal.

(2) Have an orthogonal mechanism that indicates "this is a test".  
Presumably, this would have to be in LoST, since the SIP URL may  
differ between test and operational destinations.

(2a) A flag in the query.
(2b) An additional entry in the response, returning a separate service  
URL.

My preference would be (2b), as it minimizes the number of queries  
compared to (1) and (2a) and avoids the labeling issues. This can  
easily be added as a trivial extension draft to LoST if we don't want  
to do this at this late stage.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 31 Mar 2008 12:17:39 -0400

Henning

Please recall that the first idea was a urn parameter.  Then it was the
.test idea.  Now we're looking at another return value.

I don't really care, but I want to pick a mechanism and finish the
discussion.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 12:07 PM
To: Brian Rosen
Cc: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Testing

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Mar 2008 12:59:30 -0400

I'm happy to draft the LoST extension if there's no objection. I think  
we now have explored the option space reasonably well, so it's time to  
move ahead, as you say.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Mar 2008 20:46:29 +0300

What was wrong with the URN parameter idea?
It was in former versions of draft-ietf-ecrit-phonebcp?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Mar 2008 13:50:32 -0400

It has two disadvantages:

- It requires roughly twice the number of queries to the LoST  
infrastructure since every end system will need both the non-test and  
test services.

- It requires a non-backwards-compatible update of RFC 5031.

I'm less concerned about the second issue, but before doing this, I'd  
rather know that this is the right outcome.

Henning

On Mar 31, 2008, at 1:46 PM, Hannes Tschofenig wrote:

>> I'm happy to draft the LoST extension if there's no objection. I  
>> think we now have explored the option space reasonably well, so  
>> it's time to move ahead, as you say.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Mar 2008 20:59:52 +0300

Hi Henning,

I thought that the "test" parameter would be used in a different way, 
namely:

* A LoST client issues a query for urn:service.sos.fire
* A LoST server provides an answer.
* The client creates an INVITE with the Service URN parameter and 
appends the "test" parameter
In this example: urn:service.sos.fire;test

I understand the problem with RFC 5031.

Ciao
Hannes

Henning Schulzrinne wrote:
>>> think we now have explored the option space reasonably well, so it's 
>>> time to move ahead, as you say.
>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 31 Mar 2008 14:07:15 -0400

Yeah, that's what I thought.

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 2:00 PM
To: Henning Schulzrinne
Cc: Brian Rosen; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Testing

Hi Henning,

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Mar 2008 14:07:13 -0400

I don't see how this can work unless the service URL is the same for  
both test and operational systems. I thought our requirement was that  
a PSAP could designate another system as a test system (e.g., a  
statewide center), so that any tests would not interfere with "real"  
calls. Thus, we want to be able to convey test URLs in LoST. Once you  
do that, it's presumably trivial to have two SIP URLs:

sip:[email-masked]
sip:[email-masked]

even if you want to direct both calls to the same proxy. This isn't a  
major concern if we assume that all calls, test and real, go to a  
statewide ESRP. I'm not sure that we want to *require* that.

Henning

On Mar 31, 2008, at 1:59 PM, Hannes Tschofenig wrote:

> Hi Henning,
>
> I thought that the "test" parameter would be used in a different  
> way, namely:
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 31 Mar 2008 14:12:38 -0400

A proxy is allowed to route on any information it has, including what is in
a parameter.  For best results, you want the route to be as close as
possible to the same, so I think that the notion that you have to get to a
proxy in the domain of the PSAP URI before the route can diverge is no
problem.

I think that having a bunch of mechanism just so the domain of the test URL
and the real URL can be different is not worth the effort.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 2:07 PM
To: Hannes Tschofenig
Cc: Brian Rosen; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Testing

sip:[email-masked]
sip:[email-masked]

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 31 Mar 2008 21:14:47 +0300

Hi Henning,

Henning Schulzrinne wrote:
> calls.

I thought that this was the idea to have test calls treated in the same 
way as real emergency calls.

> Thus, we want to be able to convey test URLs in LoST. Once you do 
> that, it's presumably trivial to have two SIP URLs:
>
> sip:[email-masked]
> sip:[email-masked]
>

Maybe we should ask PSAP operators what type of depoloyment mode they want.

Another way forward would be to go ahead with the solution you proposed, 
i.e., introducing flexibility. When a PSAP operator wants to use the 
"real" system also for test calls then they would return the same URIs 
twice, one for the test and another one for the "real" emergency call. 
If they don't want this behavior then they would return different URIs.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Mar 2008 22:59:58 -0400

On Mar 31, 2008, at 2:14 PM, Hannes Tschofenig wrote:
>> I don't see how this can work unless the service URL is the same  
>> for both test and operational systems. I thought our requirement  
>> was that a PSAP could designate another system as a test system  
>> (e.g., a statewide center), so that any tests would not interfere  
>> with "real" calls.
>
> I thought that this was the idea to have test calls treated in the  
> same way as real emergency calls.

We only do a certain extent. For example, we probably don't want a  
real PSAP call taker to answer the call and we may not want to route  
the call all the way to the PSAP, given their somewhat more limited  
bandwidth.

>> even if you want to direct both calls to the same proxy. This isn't  
>> a major concern if we assume that all calls, test and real, go to a  
> Another way forward would be to go ahead with the solution you  
> proposed, i.e., introducing flexibility. When a PSAP operator wants  
> to use the "real" system also for test calls then they would return  
> the same URIs twice, one for the test and another one for the "real"  
> emergency call. If they don't want this behavior then they would  
> return different URIs.
>

I suspect PSAP operators don't know yet what they want - they have no  
operational experience to guide them. Thus, I'd rather have a solution  
that makes it less likely we guess wrong. In addition, these types of  
details are likely to depend strongly on national differences, so that  
just asking, say, somebody from a highly distributed or highly  
centralized arrangement isn't likely to be helpful.

Henning