Hi, I'm looking at ways to address the problem raised in http://track.sipfoundry.org/browse/XECS-2233 whereby the unexpected caller ID is being presented by the gateway.
I had a look at that issue and I see that the sipXproxy correctly modifies the From: header to show the user-supplied Caller ID information however the message carries a P-Asserted-Identity that is left untouched. So for example, assuming that user 900 is configured with [first|last name]= "V H" and caller ID "QANTOM", the following invite will be sent to the gateway: INVITE sip:[email protected];user=phone SIP/2.0 [...] From: "V H"<sip:[email protected]>;tag=735D31D1-2A20A4E8 [...] P-Asserted-Identity: "VH"<sip:[email protected];signature=499563DE0bc2e77a> [...] The gateway used for the test will show a caller Id of 900 when QANTOM was expected. My guess is that the gateway used prefers P-Asserted-Identity over the >From header for the purposes of obtaining the caller ID information. To get around this problem there are two potential solutions but they each have their drawbacks. Solution #1: Change the Caller-Alias plug-in to apply the caller ID to both the From the P-Asserted-Identity headers. IMO, this option has 2 significant drawbacks: drawback a- as the request spirals inside the proxy, some redirectors may rely on P-Asserted-Identity to make some decisions. If the sipXproxy changes the content of the P-Asserted-Identity when running the auth plug-in chain at the end of the first spiral, this may confuse some redirectors as they will see changing PAI between different passes in the spiral. drawback b- The identity being asserted in the P-Asserted-Identity is the user's real identity - not its caller ID so changing the PAI's user part to be the caller ID is likely not a good idea. Solution #2: strip off the P-Asserted-Identity as the request leaves sipXproxy after is has completed its spiraling. While all the redirectors that rely on PAI as the request spirals will continue to see it, any SIP endpoint that was expecting to get a request with a PAI from the sipXproxy will not find a PAI. The only SIP endpoint that I know is like that is the sipXpage with the pending patch in XECS-2232 which I'm about to modify so that it stops relying on PAI. Any comments? Does anybody know of other endpoints that rely on the presence of PAI? Cheers, bob _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
