> On Mon, 2009-03-02 at 13:37 -0500, Robert Joly wrote: > > 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? > > What about alternative 3: > > - Configure the gateway to use From and ignore PAI? > > What do we know about how this is done and how configurable it is?
I could not find a way to do this with the AudioCodes gateways that I have to. I also did a bit of googling - this does not appear to be a typical configuration knob of gateways. > We've got this doing the correct thing with our SIP Trunks > through sipXbridge... _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
