Alex,
RFC 3323, 3325 pertain to the privacy mechanism and RFC 3324 for network asserted identity using SIP
Ajay
Alex Bligh <[EMAIL PROTECTED]> wrote:
I am trying to get my head around SIP & CLI.
It seems to be an oft-made point that SIP has no concept of a CLIP "service"
(i.e. presenting CLI on demand) because in order for SIP to work, the
UA at either end has to know the other UA's contact details.
However, within various regulatory environments, including the EU, and
certainly the UK there appear to be various rules on CLI. Those that
I am familiar with:
a) mandate the ability to present CLI (CLIP)
b) mandate the ability for the user to withhold CLI (CLIR)
c) mandate the passing of data identifying the call originator network
to network [I'll ignore this one]
Now whilst it may be true that the regulations were written with POTS/PSTN
in mind, it is also the case that there is demonstrable user demand both
for CLIP & CLIR.
Therefore, I'm trying to work out h! ow they might work in a SIP context.
For background, in a PSTN environment (in the UK at least, but I believe
everywhere), the originating local exchange inserts the CLI DN (or,
under some circumstances the originating equipment inserts the CLI DN
and the originating local exchange checks it is in a valid range), together
with and indication (based on, for instance, number prefix dialed),
and this is passed, possible between networks, to the terminating exchange
which will set the presentation CLI to the CLI DN passed to it, unless
the CLIR flag is set (in which case it will indicate "withheld"). Various
terminating DNs can be passed CLI even if CLIR is set, for instance
emergency services.
So let us suppose that you are providing a telephony service over SIP,
gatewayed to the PSTN. There are three types of call you see
1. PSTN->SIP calls
2. SIP->PSTN calls
3. SIP->SIP calls
Case 1 is easy - the media gateway puts! the CLI in the From: field unless
the call has CLIR set as received from the PSTN. For extra marks, the
originating CLI can be put in a SIP header on INVITE that the SIP
server can see, record, and strip before passing to the UA.
Case 2 is also easy - the UA can flag the requirement to withhold CLI
in a header field, the From: field can be checked against the
user in the digest authentication, and the from can in turn be to
CLI on the media gateway, with the relevant header flag being used
to control CLIR.
Case 3 seems to me to be difficult. The problem is that the From: field
needs to be transmitted to UA in order for dialog to succeed. Rewriting
the From: field (dumbly) is going to break the dialog.
I have two possible approaches
Approach A
==========
Implement an anonymizer service using a B2BUA. If the media layer
isn't otherwise being proxied, this needs to proxy the media layer too
else the IP address of t! he calling UA is going to be evident, which
in practice is the same thing as revealing the CLI. Configure the
proxy to route via the anonymizer if the calling UA expresses a
preference to.
This is in essence what Sinnreich & Johnston propose at p122 of
"Internet Communications using SIP".
Advantage: Clearly will work
Disadvantage: Media proxying causes undesired CPU burn and possibly
routes traffic in a suboptimal manner, in the extreme case hairpinning
it.
Approach B
==========
Cryptographically lock down all UAs, ensure all communication between
UAs, proxy servers etc. is encrypted. Control presentation of CLI on
the UA.
Disadvantage: Impractical, only works in a model where the UAs are
managed by the SIP provider, still requires media proxying (for
anonymity of RTP session).
Given approach B is probably not workable, are there other approaches?
Are there standard header valu! es for doing this - internet drafts I
should be reading?
Alex
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
