Subject: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls

From: "Karihaloo, Ujjval" <[email-masked]>
Date: Mon, 18 Sep 2006 14:37:19 -0600

Hi All,

   I had a question about how to identify 911 calls (via some specific
SIP Header in the INVITE msg. any RFCs?) so that SIP Proxies that
implement congestion do not drop 911 calls and treat them with highest
priority when they reach their congestion threasholds.

  Any pointers in this direction would help.

Thx,

Ujjval.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Sep 2006 16:40:37 -0400

Here is the document:

http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt

The document passed WGLC already.

Ciao
Hannes

Karihaloo, Ujjval schrieb:
> ------------------------------------------------------------------------
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 16:45:45 -0400

We have not yet decided how to do this.  We need to.  There are several
related problems, because a call back from a PSAP to a caller should have
the same characteristics.

Brian

  _____  

From: Karihaloo, Ujjval [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 4:37 PM
To: [email-masked]
Subject: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls

Hi All,

   I had a question about how to identify 911 calls (via some specific SIP
Header in the INVITE msg. any RFCs?) so that SIP Proxies that implement
congestion do not drop 911 calls and treat them with highest priority when
they reach their congestion threasholds.

Thx,

Ujjval.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 16:47:36 -0400

This not the answer.  The URN is dropped as soon as the mapping is
completed.  There was some discussion of putting a route header in with the
URN which remained on the call all the way to the PSAP.  That would not be
sufficient, see my previous email.

I think in the end we will create a namespace for the Resource Priority
header for this purpose.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, September 18, 2006 4:41 PM
> To: Karihaloo, Ujjval
> Cc: [email-masked]
> Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911
> calls
> 
> Here is the document:
>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 18 Sep 2006 16:55:43 -0400

On Sep 18, 2006, at 4:47 PM, Brian Rosen wrote:

> completed.

When did we decide this?  And why?

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 17:05:30 -0400

Remembering that there was a suggestion to put the URN in the route rather
than, or in addition to, the Request URI, it seems obvious that once you
map, you are sending to the mapped URI and not the sos URN.  

Let's say that the originating device did not map.  Then the To: field would
(typically) be the dial string, and likely the initial Request URI.  The
element that does dialstring to URN mapping would substitute the URN for the
dialstring.  The element that does the mapping would substitute the PSAP URI
for the URN in the Request URI.  Of course, these steps could be combined.
The result is still that the sos URN would be gone, unless, as I said, we
put the sos URN in a Route header in addition to the Request URI.

Brian

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 4:56 PM
To: Brian Rosen
Cc: 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; [email-masked]
Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911
calls

completed.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Sep 2006 17:29:02 -0400

The idea was slightly different: put the URN in the request URI and keep 
it there, using the translated destination as (loose) Route headers. 
(Obviously, if the URN was inserted into the To header, it stays there 
as well.)

Brian Rosen wrote:
> Remembering that there was a suggestion to put the URN in the route 
> rather than, or in addition to, the Request URI, it seems obvious that 
> once you map, you are sending to the mapped URI and not the sos URN. 
> 
>  
> 
> Let’s say that the originating device did not map.  Then the To: field 
> would (typically) be the dial string, and likely the initial Request 
> URI.  The element that does dialstring to URN mapping would substitute 
> the URN for the dialstring.  The element that does the mapping would 
> substitute the PSAP URI for the URN in the Request URI.  Of course, 
> these steps could be combined.  The result is still that the sos URN 
> would be gone, unless, as I said, we put the sos URN in a Route header 
> in addition to the Request URI.
> 
>  
> 
> Brian
> 
>  
> 
> *From:* Andrew Newton [mailto:[email-masked]]
> *Sent:* Monday, September 18, 2006 4:56 PM
> *To:* Brian Rosen
> *Cc:* 'Hannes Tschofenig'; 'Karihaloo, Ujjval'; [email-masked]
> *Subject:* Re: [Ecrit] Identifying 911 calls and avoid congestion for 
> 911 calls
> 
>  
> 
>  
>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 18 Sep 2006 21:22:03 -0400

Which draft is this in?

-andy

On Sep 18, 2006, at 5:29 PM, Henning Schulzrinne wrote:

> The idea was slightly different: put the URN in the request URI and  
> keep it there, using the translated destination as (loose) Route  
> headers. (Obviously, if the URN was inserted into the To header, it  
> stays there as well.)
>
> Brian Rosen wrote:
>> Remembering that there was a suggestion to put the URN in the  
>> route rather than, or in addition to, the Request URI, it seems  
>> obvious that once you map, you are sending to the mapped URI and  
>> not the sos URN.  Let’s say that the originating device did not  
>> map.  Then the To: field would (typically) be the dial string, and  
>> likely the initial Request URI.  The element that does dialstring  
>> to URN mapping would substitute the URN for the dialstring.  The  
>> element that does the mapping would substitute the PSAP URI for  
>> the URN in the Request URI.  Of course, these steps could be  
>> combined.  The result is still that the sos URN would be gone,  
>> unless, as I said, we put the sos URN in a Route header in  
>> addition to the Request URI.
>>  Brian
>>   
>> *Subject:* Re: [Ecrit] Identifying 911 calls and avoid congestion  
>> for 911 calls

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Sep 2006 21:41:29 -0400

I seem to recall that we agreed that this type of information should  
be in the phone-bcp. I haven't checked whether it made it there.

On Sep 18, 2006, at 9:22 PM, Andrew Newton wrote:

>> The idea was slightly different: put the URN in the request URI  
>> and keep it there, using the translated destination as (loose)  
>> Route headers. (Obviously, if the URN was inserted into the To  
>> header, it stays there as well.)
>>
>> Brian Rosen wrote:
>>> map.  Then the To: field would (typically) be the dial string,  
>>> and likely the initial Request URI.  The element that does  
>>> dialstring to URN mapping would substitute the URN for the  
>>> dialstring.  The element that does the mapping would substitute  
>>> the PSAP URI for the URN in the Request URI.  Of course, these  
>>> steps could be combined.  The result is still that the sos URN  
>>> would be gone, unless, as I said, we put the sos URN in a Route  
>>> header in addition to the Request URI.
>>>  Brian
>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Sep 2006 09:10:02 -0400

Having thought through this, I think it's a lousy idea.

The reason is that EVERY element between the endpoint and the PSAP must be
upgraded to have new behavior = recognize the service URN, "ignore" it, and
route based on the route header.  It really violates the spirit of 3261
where you can safely ignore things you don't understand, recognizing that
proxies have to be able to deal with the URN in the Request URI for as long
as it's there.

I think a Resource Priority header would have the right characteristics.  It
could also serve for a call back placed by a PSAP towards an endpoint.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, September 18, 2006 9:41 PM
> To: Andrew Newton
> Cc: Brian Rosen; [email-masked]
> >>> not the sos URN.  Let's say that the originating device did not

---

From: John Rosenberg <[email-masked]>
Date: Tue, 19 Sep 2006 08:26:58 -0500

Using Resource-Priority is and interesting suggestion. RPH does have an 
element of call-type identification based on the namespace value. However, 
RPH's main goal is to communicate a priority level to be used in 
conjunction with resource allocation, especially during congestion or in 
the face of resource contention - not quite what we're doing here.

I know that at least one service provider is suggesting the use of a 
mode=emergency tag in the R-URI.

John Rosenberg

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Sep 2006 09:43:52 -0400

That is precisely the behavior we want.  The only reason most elements need
to know that a particular call is an emergency call is to give it priority
on resource allocation.  It MAY also be used in some "unitialized device"
circumstances where otherwise the call would not be allowed at all.

That service provider should make the proposal here, as this is where such
behavior would be decided I think.

Brian

> From: John Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2006 9:27 AM
> To: Brian Rosen; 'Henning Schulzrinne'; 'Andrew Newton'
> Cc: [email-masked]'
> Subject: RE: [Ecrit] Identifying 911 calls and avoid congestion for 911
> calls
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Sep 2006 10:58:25 -0400

I think we should distinguish several aspects, i.e., what's the purpose 
of marking?

- indicate routing requests (applies to any service URN, not just 
emergency); in particular, whether a new, more specific, next hop needs 
to be computed

- indicate priority handling (applies only to emergency, but maybe not 
test calls)

The Route/Request-URI behavior I suggested is standard SIP RFC 3261 
behavior, not anything new.

John Rosenberg wrote:
> element of call-type identification based on the namespace value. 
> However, RPH's main goal is to communicate a priority level to be used 
> in conjunction with resource allocation, especially during congestion or 
> in the face of resource contention - not quite what we're doing here.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Sep 2006 11:54:02 -0400

If you leave the service URN in the Request URI, how do you know whether any
LoST mapping has been performed?  That is, how do you know whether a new,
more specific next hop needs to be computed?  Presence of a Route header
doesn't seem to be a good indication.

I do agree on your separation of marking aspects.

Brian

> Sent: Tuesday, September 19, 2006 10:58 AM
> To: John Rosenberg
> Cc: Brian Rosen; 'Andrew Newton'; [email-masked]'

---

From: Shida Schubert <[email-masked]>
Date: Tue, 19 Sep 2006 13:27:17 -0700

AFAIK as we allow usage of cached PSAP URI or even PSAP URI
that was given by some non LoST server, I don't think we can
indicate that Request URI or URI in the Route header is the PSAP URI
derived as a result of LoST mapping/query...

I think any marking that will prioritize the call should be traceable to
who had marked the call in case it was used to DoS or used maliciously.

I like the idea of putting the Service URN in the To header which then
can be signed with SIP-identity by the proxy serving the UA making the
emergency call. With the proxy conducting the LoST query, it could make
sure that the destination set as a value in Route header is indeed a PSAP
URI(In case UA has queried the LoST prior to making the call) and sign
the message only when it confirms that the call is indeed an emergency
call.

Regards
Shida

Brian Rosen wrote:
>>>  >route based on the route header.  It really violates the spirit of
>>>       
>> 3261
>>     
>>>  >where you can safely ignore things you don't understand, recognizing
>>>       
>> that
>>

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 20 Sep 2006 05:43:36 -0400

> I think we should distinguish several aspects, i.e., what's the purpose of marking?
> ...
> - indicate priority handling (applies only to emergency, but maybe not test calls)
 
I don't think I'd really be in favor of using this to indicate priority handling in any of the network elements we operate. It certainly makes no sense in IP routers that handle general data or Internet traffic. That is, I wouldn't want to impact the performance of these high capacity routers by making them become SIP-aware and have to look inside the SIP to determine prioritization. For these devices, DSCP is where it's at.
 
The only devices where it might make sense, would be the ones that are currently SIP-aware, like the Session/Border Controllers (SBC) and the proxies. I think I'd still prefer to use DSCP. I've heard rumors of discussions around maybe, possibly creating a new EF-like DSCP for emergency services? 
 
Also (and please, correct me if I'm wrong, because I'm a bit out of my element here), it seems that this would only be useful for the SIP messages from the user to the PSAP, but not the return messages?
 
With that said, I know that our SBCs have firewall capabilities and DSCP marking/remarking capabilities. If this were used as something that SBCs looked at when checking whether the DSCP marking was proper (and then remark if not), that might be ok. But these rules on what the SBC looks at and does with the things it sees are very flexible and constantly changing. So I wouldn't expect such a usage to be written in concrete.
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Francois Menard <[email-masked]>
Date: Wed, 20 Sep 2006 06:46:17 -0500 (EST)

That would not be too different from the HPC (High-Probability of Call 
Completion) implemented on the 1-710-NXX-XXXX PSTN network (that we never 
got around to agree how to implement in Canada).  The Government of Canada 
even bought two Class 5 switches in the CRC labs in Ottawa to attempt to 
figure out how it should subsidize this (I hear).

F.

--
Francois D. Menard
Project Manager/Charge de projet
Xit telecom inc.
1350 Royale # 800
Trois-Rivieres, QC, G9A 4J4
Tel: +1 819 374 2556 x 268
Cell: +1 819 692 1383
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Sep 2006 08:35:29 -0400

On Sep 20, 2006, at 5:43 AM, Stark, Barbara wrote:

> I don't think I'd really be in favor of using this to indicate  
> priority handling in any of the network elements we operate. It  
> certainly makes no sense in IP routers that handle general data or  
> Internet traffic. That is, I wouldn't want to impact the  
> performance of these high capacity routers by making them become  
> SIP-aware and have to look inside the SIP to determine  
> prioritization. For these devices, DSCP is where it's at.

I don't think anybody is proposing this, but maybe I'm biased by the  
discussion in the Resource-Priority RFC (RFC 4412), which explicitly  
rules out any attempt to use R-P for DiffServ-like behaviors.

>
> The only devices where it might make sense, would be the ones that  
> are currently SIP-aware, like the Session/Border Controllers (SBC)  
> and the proxies. I think I'd still prefer to use DSCP. I've heard  
> rumors of discussions around maybe, possibly creating a new EF-like  
> DSCP for emergency services?

These are completely different issues. Any R-P would affect SIP  
processing only; the only connection to packet-level prioritization  
would be that the proxy could mark outgoing signaling packets with a  
"better" DSCP. Saying "just use DSCP" doesn't quite work since the  
marking of the inbound INVITE packet would be lost as soon as that  
packet hits the first proxy.

The IEPREP WG has been working on this topic, but is currently in  
hiatus.

>
> Also (and please, correct me if I'm wrong, because I'm a bit out of  
> my element here), it seems that this would only be useful for the  
> SIP messages from the user to the PSAP, but not the return messages?

Please see the discussion in RFC 4412 on this topic.

>
> With that said, I know that our SBCs have firewall capabilities and  
> DSCP marking/remarking capabilities. If this were used as something  
> that SBCs looked at when checking whether the DSCP marking was  
> proper (and then remark if not), that might be ok. But these rules  
> on what the SBC looks at and does with the things it sees are very  
> flexible and constantly changing. So I wouldn't expect such a usage  
> to be written in concrete.
> Barbara
> *****
>
> The information transmitted is intended only for the person or  
> entity to which it is addressed and may contain confidential,  
> proprietary, and/or privileged material. Any review,  
> retransmission, dissemination or other use of, or taking of any  
> action in reliance upon this information by persons or entities  
> other than the intended recipient is prohibited. If you received  
> this in error, please contact the sender and delete the material  
> from all computers. GA622

---

From: John Rosenberg <[email-masked]>
Date: Wed, 20 Sep 2006 08:53:12 -0500

>"better" DSCP.

An important related issue here is how a call controller might instruct an 
endpoint regarding what DSCP value the endpoint should for the bearer 
packets that it generates. We're running into that issue with MLPP (a user 
of RPH).

RPH is great for doing good things to the signaling at the application 
layer, but really has no impact on the lower layers and no impact on the 
bearer stream.

Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP value 
51 in your bearer packets"?

This would be needed for emergency service calling, GETS/ETS (ieprep), and 
MLPP.

Thanks,

John Rosenberg

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Sep 2006 10:17:21 -0400

I believe you do both:
You mark the SIP signaling for priority handling within the sip processing
elements

You mark the SIP and media packets for priority handling within the packet
processing elements.

It's not a good idea to infer one from the other, and it's not hard to have
both markings.

I don't think we should have a protocol mechanism to tell elements how to
mark packets.  We should choose a marking, and write it into the
specification.  The PHB for the marking would have to be a local matter.

Brian

> Sent: Wednesday, September 20, 2006 9:53 AM
> To: Henning Schulzrinne; Stark, Barbara
> Cc: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Sep 2006 10:39:22 -0400

> Anyone know of a good mechanism in SIP to tell an endpoint "use DSCP 
> value 51 in your bearer packets"?
> 
> This would be needed for emergency service calling, GETS/ETS (ieprep), 
> and MLPP.

This isn't really a SIP function; at best, this is the territory of SDP.

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 20 Sep 2006 10:46:49 -0400

Is there an expectation that the DSCP value will change from region to region?
If not, and given that the endpoint is responsible for identifying emergency calls, I'd rather it just be pre-configured with the correct DSCP to use for emergency calls (SIP and RTP).
If it will different, then that will cause undesirable behavior, because many of the network elements processing the call may not be in the same region as the call originator and call taker.
Barbara

________________________________

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wed 9/20/2006 10:39 AM
To: John Rosenberg
Cc: Stark, Barbara; [email-masked]
Subject: Re: [Ecrit] Identifying 911 calls and avoid congestion for 911 calls

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621