Subject: SIP in higher education
- From: John Todd <>
- Subject: Caller ID questions (re: conference call)
- Date: Tue, 8 Nov 2005 12:54:59 -0800
On the SIP.edu conference call the other day, there had been discussion on various Caller-ID issues surrounding the transfer of SIP URI-based Caller-ID for sessions that were being terminated on telephony gateway devices (i.e.: PBX or PSTN mappings.) As many SIP.edu participants at some point will be forwarding calls for sip: destinations to non-native SIP devices (telephones) it probably is worthwhile examining how caller identity is transported to those destinations if full SIP headers are not available to that end device. In other words, "" is not able to be displayed on a 1990-vintage Nortel phone that may be the eventual end destination that rings when I call "" from my SIP client. That Nortel phone can only display "16505812405" which is my E.164 telephone number.
I had mentioned that there was probably some RFC that already covered this. I was correct in assuming that somewhere in the RFC swamp was a creature that fit the bill. Alan Johnston gave me the nudge towards RFC 3325, which might solve some of these problems.
Please take a look at http://www.zvon.org/tmRFC/RFC3325/Output/chapter9.html#sub1 which refers to the ability for the P-Asserted-Identity header to contain BOTH a sip: (or sips:) URI and a tel: style identity.
I'm somewhat confused as to why the authors limited that header field to just those three method types (and not "im:" or "http:" or other method types from http://www.iana.org/assignments/uri-schemes ) but that's the way it is. I've asked Alan if he knows why it was limited to just those two method types. I'm glumly surveying the issues surrounding getting "isn:" as a new method type, but that is a long shot at best though the more I think about it the more it does probably deserve a new method type.
The use of P-Asserted-Identity: in INVITEs with multiple originating identity pointers (sip: and tel:) will be useful if the originator doesn't know what the other end will do with the call (send it to a SIP device, or send it to a telephony gateway?) However, the end gateway needs to be able to do "the right thing" with the request in a pure proxy transaction. I don't know anything about this header field and it's compatibility with modern gateway software. I guess you could ask various vendors "Is your PSTN gateway hardware compliant with RFC3325, and how exactly do you handle those headers?"
If the gateway is too "dumb" to use the P-Asserted-Identity field and only uses the "From:" header, the other way of setting the correct value is to let the smart call director (B2BUA) in the middle mangle the From: line and replace it with the appropriate P-Asserted-Identity: header value if the call is being passed to a device that only takes (for example) tel: style From: headers. It would be trivial to get Asterisk to do this, as Asterisk is a B2BUA and can easily re-write the full headers on both "sides" of itself. SER probably can't do this at all since it is not a B2BUA (though a B2BUA can be placed in the flow between SER and the telephony gateway devices fairly easily.)
The last point is that after further examination of this issue, it may be desirable to come up with some best common practice for SIP.edu participants as to how to set their identities for outbound sessions to other participants. Using the P-Asserted-Identity: in well-understood ways, and inclusion of both alphanumeric sip: identity as well as a (somewhat) useful tel: identity perhaps would allow other members to correctly display some relevant caller pointer data on devices no matter what the destination type.
Summary Question: How many of you are using gateway devices that are RFC3325-compliant so that the correct caller ID will be presented if both a sip: and tel: identity are in the SIP INVITE?
Networking, Tello Corp.
- 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.