Looking at this example topology
Q#1 - Where is this 200 OK important in your context (for verifying
Q#2 - Why is this important at this point in the topology?
Q#3 - What do you expect the SIP element to do with any indication
you are creating here?
Little new can be between Alice and the ESRP, as we're attempting to
create a solution with the LEAST amount of changes to SIP --> because
the more changes there are, the more complicated the solution is, the
less likely it will be implemented right --> which is the goal, right?
The ESRP should be a B2BUA or SBC, so changes behind it towards the
PSAP call taker's UA need to highlighted as only being in that part
of the topology.
We cannot expect COTS SIP products to do too much, yet I don't
believe COTS SIP equipment will be used at the ESRP or between it and the PSAP.
At 01:00 PM 7/31/2007, Matt Lepinski wrote:
I'd like to step back (for a moment) from the discussion of whether
there is a way for a third party to verify that a LoST mapping for a
Taiwanese PSAP is authentic (or authoritative).
At a high level Richard proposed that the problem of fruad
prevention (verifying that a call is actually headed to a PSAP) can
be solved more easily if we utilize not just the SIP INVITE but a
response to the SIP INVITE. In particular, if we use Connected
Identity (if PSAPs have appropriate credentials) or Signed LoST
Mappings (if LoST servers have appropriate credentials) or something
else (if someone else has appropriate credentials).
Henning provided the following response:
[Richard Barnes:] Note that this level of state (e.g., keeping
track of all the messages in an INVITE transaction) is useful for
things like accounting and billing as well, so VSPs may be doing it anyway.
Henning seems to be saying that any mechanism for fraud prevention
which relies on a message other than the SIP INVITE is not useful.
[Henning Schulzrinne:] This is not the right forum for this
discussions, but if a VSP relies on such capabilities, they are
likely to be in (financial) trouble. One of the core assumptions
for ECRIT is that we don't mess with SIP call flows or create
emergency-specific call flows.
Am I interpreting Henning's response correctly?
Do others feel that using messages other than the SIP INVITE is not
a useful approach to fraud prevention?
- Matt Lepinski :->
Ecrit mailing list
Ecrit mailing list