On Sun, May 9, 2010 at 5:10 PM, Jeff Gilmore <[email protected]> wrote:
> I am resending this to the list, as I did not see it come back and have > been having some email problems. Forgive me if you have read it already > (but feel free to chime in if you have any insights)! > ============ > > I have been working with my ITSP to resolve problems for my users that > choose to have outbound caller ID (CLID) blocked. We are finding that the > way sipx (4.0.4) handles blocking CLID also interferes with 911 service. > > My ITSP explains it as such: > > According to RFC3325, when sending an invite to a "trusted gateway", the > header field P-asserted-identity should be included and should contain the > actual identity information (in my case, I need it to send the DID) and the > "Privacy" field set to "ID", indicating that the receiving gateway should > not share the identity with any non-trusted gateways. Here is an example > from the RFC: > > From: "Anonymous" <sip:[email protected]>;tag=9802748 > > Call-ID: 245780247857024504 > CSeq: 2 INVITE > Max-Forwards: 69 > P-Asserted-Identity: "Cullen Jennings" <sip:[email protected]> > P-Asserted-Identity: tel:+14085264000 > Privacy: id > > In my case, it appears that I am sending the username with which I > authenticate with the ITSP (this single username is used for all outbound > calls from any of my users, and there is no pre-registration) in the > P-asserted-identity > field, no "Privacy" header, and "sip:[email protected]" in the > from field. > > Since we do not send the real DID anywhere in the header, this means that > the DID is unavailable for 911 service lookup if CLID is disabled. > > Can anyone help me figure out how to get sipx to include the DID (which I > set manually for each user as their Caller-ID string) in the > P-asserted-identity header? > > I also am wondering about trust domains. I don't see any configuration > fields in the SBC or gateway that allows me to indicate whether or not I > consider the gateway part of my trust domain. Is sipx behaving this way > because it considers my ITSP untrusted? If so, how can I indicate trust > status? > > Any insights would be helpful. I can send more config and trace details > privately, if needed. > > Thanks, > Jeff > > Realize that what you are doing is acting as a provider for public services. sipXecs was designed as an enterprise solution, and has "gateway/branch" functions that will act to ensure the proper caller-id and gateway is used when sending 911. In a residential or consumer environment, you probably need to look for a specialty SBC to intercede between sipx and your provider to do what you are trying to do, because, well, it's not designed in the way you decided to employ it is all. While it is neat you decided to do so, I would never have tried to do something without addressing 911 first, because the penalties are severe and I for one am not interested in breaking 911 service or becoming the one someone points my finger to when the local ESOC launches a complaint. Without an interceding device, I do not know how you would address it, really. You "should" advertise it is not desgined for use as a replacement land line nor 911 compatible, and not allow 911 dialling until you resolve it though. > > > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
