RE: [Ecrit] call marking

["Brian Rosen" <br at brianrosen.net>]

I think the current proposal is to leave the sos URN in the Request URI and
change the top of the Route stack as the call is routed, in line with
Jonathan's mechanism for a similar problem with GRUUs.

I think your reasoning is specious because you are talking about an upgraded
phone or network, that understands the sos URI, and uses it, and you want to
have backwards compatibility with the existing systems while keeping the new
marking.  That won't work.  

If you take a new (in NENA we would call that an "i3" call) and you want to
put it in the existing ("i2") system, then the sos URI is meaningless within
that system, and like a current i2 call, you don't need or want special
marking.

This would mean that a call enters a proxy with urn:service:sos in the
Request URI, and some meaningful thing in a Route header.  The proxy
determines that the call has to be routed on the i2 network.  It pops the
Route header and replaces the Request URI with what it needs to do to get it
to route in the i2 network.  It would then look just like any other i2 call.
If you attempt to send the call with any marking, the i2 system may well be
unhappy, but even if it was okay (as it really should be), the marking,
however you do it, is meaningless.

Now, I do want to use the RP header, because we really do want resource
priority in the signaling.  Similarly, I'd like to mark the media, because
I'd like some priority there also (but only packet level stuff, so I mean a
DSCP).  The former COULD be implied by whatever marking we end up with, but
I don't like implications.  I'd rather be explicit.

But that doesn't affect the issue of sos in the RequestURI.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:andy at hxr.us]
> Sent: Thursday, January 04, 2007 2:42 PM
> To: ECRIT
> Subject: [Ecrit] call marking
> 
> I'm not sure where we left off with this issue, but it needs to be
> resolved.
> 
> Previously, I leaned toward the sos URN in the request URI (I believe
> this was Henning's suggestion).  I no longer think this is a good
> idea, because the request URI is actively used in emergency calls
> today, many times containing psuedo-codes relevant to call routing.
> Admittedly, this is an artifact of gatewaying to the PSTN, but
> picking another method that would remain compatible with this
> practice seems to offer easier transition.
> 
> For the clueless, why is the Priority header with the "emergency"
> value not useable here?
> 
> -andy
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit