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).
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
