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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
