> Hendrik Scholz wrote: > > Hi! > > > > How would the TDM interworking work? > > There are some limitations indeed -- if a gateway calls a SIP phone, > and supports DERIVE, DERIVE actually asserts "can I reach *a gateway > you are momentarily using*" (as opposed to say "I can reach you via > your address"). Still I think that's meeting the "better-than-nothing" > expectation offered by DERIVE. If we wanted to get closer to > the caller, > we would have to dig in the PSTN protocols. > > There is a practical and IMO worse concern: a telephone > number can resolve > to way too many places: SIP routing is not symmetric in this case and > pstn-2-sip request can take a different path than sip-2-pstn > request. Thus > a verifier can very likely end up with a different GW than the one > which initated the call in question. (If the phone number is offered > in From as tel URI, one could for example try to perform an ENUM > query with non-e164 result but I'm not sure it make sense -- > in the end, > if there is such URI it could have been put in From straight).
This isn't a concern, though. Even if the return routing worked perfectly and you got back to the very same PSTN gateway, the best you can achieve is trusting the caller-id asserted by the PSTN. Which can be spoofed, as we all know. So, DERIVE to an E.164 that terminates on a PSTN gateway can't tell you too much; DERIVE to an E.164 that terminates on a SIP UA can be pretty worthwhile. I admit that a PSTN gateway could lie and pretend to be a normal SIP UA; thus, a DERIVE validation of an E.164 isn't as trustworthy as a DERIVE validation of an email-style SIP URI because the PSTN gateway could lie. If we had a way to determine who 'owns' an E.164, we could make that owner prove they received the DERIVE query (by asking them to encrypt something with their private key), which prevents a PSTN gateway from lying. This is something that could be bolted on later, if/when we figure out how to map an E.164 to certificate that 'owns' it. -d > > > > > Look at 'Figure 1: Overview of Operation' and assume this: > > > > - Call SIP->PSTN > > > > The callee is in the PSTN/TDM world and proxy 2 acts as > > a gateway. > > In this case the callee would never send a SUBSCRIBE. > > If there is no authentication/authorization for the call > > the gateway may opt to subscribe to the user? > > that's the best we can get, without PSTN interaction the > gateway has to act on the party's behalf. > > > > > - Call PSTN->SIP > > > > The caller is on the TDM side and proxy 1 acts as a PSTN to SIP > > gateway. The callee sends the SUBSCRIBE which ends up at > > the edge on proxy 1. > > What should the proxy do? > > a) Respond on behalf of the caller > > b) do not support the Dialog event package and respond > > with 489 to the SUBSCRIBE > > c) do some magic based on information conveyed on the > > TDM side? > > It does not have to be the proxy, it can be the gateway but the > real problem is IMO if the SUBSCRIBE gets there at all. If it > gets there, I think a) is the appropriate answer. (or b) if > it does not support DERIVE). c) is apparently a difficult one. > > -jiri > > > > > Cheers, > > Hendrik > > > _______________________________________________ > Sip mailing list https://www.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 _______________________________________________ Sip mailing list https://www.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
