Subject: [Ecrit] UA Loose Route mechanism as Marking

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Nov 2006 18:44:31 -0500

One thing not handled by UA loose route is to differentiate the case
where an emergency call has been detected, but no route has yet been
determined. 

Consider:

INVITE urn:service:sos
To: [email-masked]
Route: e-cscf.example.com

From
INVITE urn:service:sos
To: [email-masked]
Route: [email-masked]

The first is an example where the (forgive me) P-CSCF did dialstring
recognition for a really dumb UA, but the E-CSCF has not yet routed the
call using LoST.  In the second, it has.  The only difference is the
actual URI in the Route header.  

I'm concerned that the only way to determine if LoST routing has been
done is to do it again and analyze the Route headers.  Not a good plan I
would think.

INVITE urn:service:sos
To: urn:service:sos
Route: p-cscf.example.com
Route: [email-masked]

This is what I would think the UA that does its own dialstring and LoST
routing would put out.

Do we need a "dip indicator"?

Brian

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Nov 2006 16:16:49 -0800

I'm not sure this is a problem. In the first case, the E-CSCF will do  
the LoST dip and is indeed the destination of the route. Thus, it  
clearly has to do *something*. It only has to recognize itself, as  
per normal Route behavior.

On Nov 7, 2006, at 3:44 PM, Rosen, Brian wrote:

> <winmail.dat>

---

From: Shida Schubert <[email-masked]>
Date: Tue, 07 Nov 2006 16:28:55 -0800

I agree with Henning that there is no worries if there is only one 
entity that queries the
LoST on the signaling path, that the indicator is not necessary. But if 
there is more
than one entity including the originator doing the LoST query, not 
having the dip indicator
can impose some issues(delay, in case later dip fails etc.)..

 I really don't know if this is an issue, but may be..

 Regards
  Shida

Henning Schulzrinne wrote:
> clearly has to do *something*. It only has to recognize itself, as per 
> normal Route behavior.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 7 Nov 2006 16:39:52 -0800

I think this recurses: The first LoST-querying proxy inserts a route,  
which directs the request to a second proxy (say, state-level).  
There, that second proxy, the one identified in the Route header,  
repeats the mapping, maybe yielding the county proxy. And so on. As  
long as the general rule is that the destination of the Route does  
the lookup, things should work automatically. (I don't think you want  
some entity in the middle of the route list to do the lookup,  
essentially overriding the existing route, but that's more of a  
policy issue.) Clearly, that last proxy has to do the lookup, since  
it has run out of other indications of where to send the request.

Henning

On Nov 7, 2006, at 4:28 PM, Shida Schubert wrote:

> LoST on the signaling path, that the indicator is not necessary.  
> But if there is more
>> I'm not sure this is a problem. In the first case, the E-CSCF will  
>> do the LoST dip and is indeed the destination of the route. Thus,  
>> it clearly has to do *something*. It only has to recognize itself,  
>> as per normal Route behavior.
>>