Subject: [Sip] Questions on draft-rosenberg-sip-ua-loose-route-01.txt

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Jan 2008 00:01:23 -0500

If I read the draft correctly, the proposed solution is that rerouting action leaves the req-uri alone, and pushes a Route for the resolved target's URI (contact/whatever).  Whereas a retargeting action replaces the req-uri with the new target, and possibly pushes the previous req-uri into History-Info.  The draft proposes retargeting be defined as when the proxy determines the new target could not claim the previous req-uri as its Identity.  In other words, if the new target were to originate a request using the previous req-uri as its From addr-spec, would its domain sign it using rfc4474 - if so then it's a reroute, if not then it's a retarget.  Correct?

The draft also describes several cases, some of which don't seem to follow the above rules.

For example, Section 5 example 3 says:
   3.  When a proxy receiving a request identifies a next hop server
       that is needed to process the request, that next hop server is a
       route.  A next hop server is not a UA and would never be able to
       claim its identity.  Its URI is pushed into a Route header field
       and the Request-URI is retained.  An important use case for this
       are proxies that select PSTN gateways for call egress to the
       PSTN.  Such selection would place the SIP URI of the gateway into
       the topmost Route header field value and retain the Request-URI.

So this says a PSTN gateway could not claim the identity, yet the behavior is still rerouting?

Another example of this is in Section 2.6 for Emergency Numbers.  It states the SOS URN needs to stay in place in the req-uri all the way to the call-taker.  I'm not sure if such a call-taker could claim Identity to an SOS URN, and furthermore the odds are the call-taker is in another domain, which per this draft would constitute a retargeting and change the req-uri.  No?

This draft should also describe what happens for service invocation, which is a stated problem space in section 2.5.  Again, a voicemail system or IVR or App Server could not claim Identity for the req-uri, and thus it would be a retarget per the draft's definition.

-hadriel

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jan 2008 09:51:17 -0500

I've been busy so I have been only loosely following this discussion.

> If I read the draft correctly, the proposed solution is that rerouting action leaves the req-uri alone, and pushes a Route for the resolved target's URI (contact/whatever).  Whereas a retargeting a…

Given dean's terminology the above statement seems a little imprecise. 
It puts things in only two buckets, not the three or more that Dean 
proposes. I think that impacts the following.

>        the topmost Route header field value and retain the Request-URI.

The above is also less than precise.

> So this says a PSTN gateway could not claim the identity, yet the behavior is still rerouting?

There is a problem here one way or another. A PSTN GW *is* a UA. And if 
the address is a phone number, then it *can* claim identity to it.

> Another example of this is in Section 2.6 for Emergency Numbers.  It states the SOS URN needs to stay in place in the req-uri all the way to the call-taker.  I'm not sure if such a call-taker could…

I see URNs as much like phone numbers, in that they aren't associated 
with domains. There semantics are intended to be known publicly, and 
there may be many different UAs that can claim to be responsible for 
them. In normal emergency processing, the receiving UA *should* be able 
to claim identity for that URN.

Of course there are technical problems for both phone numbers and URNs 
in that we don't know how to apply sip identity to them.

> This draft should also describe what happens for service invocation, which is a stated problem space in section 2.5.  Again, a voicemail system or IVR or App Server could not claim Identity for the…

I think it is debatable whether a VM or IVR system can claim identity 
for the r-uri. It depends on the deployment and the policies of the 
owner of that URI.

(If I have a phone in my home, listed as belonging to me, and I attach 
an answering machine to it, that answering machine gets to assert my 
identity as much as I do. If I contract with a SP to provide my 
answering services, it can still claim my identity if I want to allow it 
to do so.

Its the same with a human secretary. I can give a secretary an extension 
on my own AOR, in which case its possible to claim my identity, or I can 
program my proxy to retarget to the secretary, in which case the 
identity is different.)

	Paul