sip.edu - Re: [sip.edu] Caller ID questions (re: conference call)
Subject: SIP in higher education
List archive
- From: (Dennis Baron)
- To: John Todd <>
- Cc:
- Subject: Re: [sip.edu] Caller ID questions (re: conference call)
- Date: Wed, 09 Nov 2005 10:55:17 -0500
Thanks for following up with Alan Johnston.
My impression of P-Asserted-Identity in RFC3325 was that it was to be
used inside trusted networks - which certainly isn't our environment.
But I haven't looked at it in a couple years. And that doesn't mean
that we couldn't adapt it for our needs - unless we think that people
will need to use it for its intended purpose.
I think your question about implementations is a good one. MIT is
using Cisco gateways and, as far as I know, they don't support
P-Asserted-Identity. Does anybody know for sure? I do think that
CSPS can manage P-Asserted-Identity headers. Besides gateways are
there any SIP UAs that can utilize P-Asserted-Identity headers?
It looks like P-Asserted-Identity can only transport one SIP address
and an optional tel: URI. I think tel:21232*270;phone-context=isn
would be allowed - but then you have to choose between inserting
tel:21232*270;phone-context=isn and tel:+16172521232 . I too don't
see why they limited this to only two URIs but I'm not sure we should
push for a new type if tel can be used for ISNs.
At this point I'm also not completely convinced that we should be
trying sending ISNs through the gateway. The MIT PBX expects
"national" numbers and our ISDN phones only display national numbers.
And, most importantly, the call may end up being forwarded to the PSTN
where an ISN will never be returnable. I doubt that our PBX can
handle more than one addressing scheme - and the PSTN is what it uses.
Some other thoughts that I've had since the last call.
* I think our recommending anything that breaks the RFCs is a bad idea
- eg. modifying the From address.
* I also think recommending the insertion of B2BUAs is a (slightly
less) bad idea.
Both of these are likely to come back to bite us as campuses want to
deploy end-to-end, intercampus services. B2BUAs have their place - but
I think it is to add non-standard functionality at the edge of a SIP
network - not part of the core.
* I think we should avoid recommending the use of non-SIP.edu
addresses within the SIP network.
Even if I call
using his ISN I think he should still see
sip:
calling him. If I'm calling from the PBX phone
using an ISN then I don't have a problem with the callee seeing
sip:21232*.
But I'd also be agreeable to seeing
sip:,
sip:,
sip:+
- basically anything that is returnable.
I think we should evaluate P-Asserted-Identity but I also think we
should be looking at Remote-Party-ID - even though it isn't a standard
it is implemented by Cisco and Asterisk gateways and Cisco and CSPS
proxies. And I believe Cisco phones support it - does anyone with a
Cisco phone know what you see when I call you? I'd be happy to place
a test call! Are there any other products that support
Remote-Party-ID?
Dennis
========================================================================
Dennis Baron; Information Services & Technology
mailto:
Senior Strategist for Integrated Communications
sip:
Massachusetts Institute of Technology; Room 9-369 tel:+1-617-252-1232
77 Massachusetts Avenue; Cambridge, MA 02139-4307 fax:+1-617-253-8000
========================================================================
- Caller ID questions (re: conference call), John Todd, 11/08/2005
- Re: [sip.edu] Caller ID questions (re: conference call), Dennis Baron, 11/09/2005
Archive powered by MHonArc 2.6.16.