> On Feb 27, 2009 2:25pm, Robert Joly <[email protected]> wrote: > > > I draw your attention to XECS-2283 (reported by Chaitra Sharma). > > > > > > > > > > http://track.sipfoundry.org/browse/XECS-2283 > > > > > > > > > > It appears that the proxy server is not constructing the From > > > > > header correctly. It is apparently using the same From header > > > > > ( caller-ID ) for both dial plans. I have verified that this > > > > > is not a configuration problem and I have also verified that > > > > > this is not a problem with sipxbridge. This appears to be a > > > > > bug in the proxy server ( i.e. the part that re-writes the > > > > > From header based upon the caller-ID in the dial plan ). > > > > > > > > > > Any comments? > > > > > > > > > > Thanks > > > > > > > > > > Ranga > > > > > > > > > > Note: The issue is currently un-assigned. > > > > > > > > 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. > > > > > > > > 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: "V > > > > > H"sip:[email protected];signature=499563DE%3A1011cb57ca794c4364100f5 > > 0 > > > > 0bc2e77a> > > > > [...] > > > > > > > > The gateway will show a caller Id of 900 when QANTOM was expected. > > > > > > > > > > > > My guess is that the gateway prefers P-Asserted-Identity > over the From > > > > header for the purposes of obtaining the caller ID information. I > > know > > > > that Scott has been looking at caller Id simplifications. > > > > > > > > Scott: Were you contemplating to also apply the caller ID > preferences > > to > > > > the P-Asserted-Identity as well or would that break something in > > > > sipXbridge? > > > SipXbridge manages its own P-Asserted-Identity and hence it > will be unaffected by any changes in the Proxy Server.
Editing the P-Asserted-Identify so that it contains the configured caller Id is probably not the way to go to fix this problem for a couple of reasons: 1- 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 on the first spiral, this could lead to erratic behaviors in redirectors that rely on it. 2- The identity being asserted in the P-Asserted-Identity is the user's real identity - not its caller ID. The conclusion I am reaching is that the best approach to address the problem would be to strip off the P-Asserted-Identity as the request leaves sipXproxy after is has completed its spiraling. Comments? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
