On Mon, 2009-03-02 at 15:20 -0500, Robert Joly wrote: > > > > On Mon, 02 Mar 2009 14:08:51 -0500, Joly, Robert (CAR:9D30) > > <[email protected]> wrote: > > > > > > > > > > >> -----Original Message----- > > >> From: Spitzer, Andy (BL60:9D30) > > >> Sent: Monday, March 02, 2009 2:00 PM > > >> To: Joly, Robert (CAR:9D30); [email protected] > > >> Subject: Re: [sipX-dev] Fixing 2233 - Caller ID is not > > displayed on > > >> the Gateway. > > >> > > >> Woof! > > >> > > >> On Mon, 02 Mar 2009 13:37:09 -0500, Robert Joly <[email protected]> > > >> wrote: > > >> > > >> > Solution #2: strip off the P-Asserted-Identity as the > > >> request leaves > > >> > sipXproxy after is has completed its spiraling. > > >> > > >> Instead of striping it as it leaves sipXproxy, set it to the > > >> From: header so they match? > > > > > > That would still leave you with drawback 'b' of solution #1. The > > > identity that was asserted by sipXproxy is the user's > > actual identity > > > - not its caller ID alias. As an example, consider 100 and 200 two > > > valid users on SIP server 'example.com'. User 100 configures its > > > caller ID to be '200'. With this proposal, the sipXproxy > > will assert > > > that the identity of the requester is [email protected] when > > in fact it > > > is [email protected]. > > > > > > > Well, perhaps I'm being obtuse here, but isn't the reason we > > "fake" the outbound caller ID is so that it looks as if you > > are someone you are not? > > > > In the real world, jamming the "from" field is to tell the > > gateway to set the calling line ID to a known DID number > > (either the caller's individual one, or the pilot number of > > the hunt group). It isn't really meant to mascarade one > > registered user as another. But so what? That's what the > > admin wants to do, so why would it be "wrong" to change PAI? > > It's just as "wrong" to change "from" but we allow that (now). > > I understand what you are describing and you may well be right. I was > approaching it from the point of view that the semantics of PAI is to > 'assert' the actual identity of the request originator within a trust > domain. Given the intent of the PAI, my natural reflex is not fudge it > with admin-definable data as it could denature its purpose but I realize > that is all very debatable. Scott, I would like to hear your take on > this.
I'd rather strip it than change it. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
