SIP in higher education

[John Todd <>]

  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?


JT


--
John Todd
Networking, Tello Corp.

  +1-650-581-2405