> > 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. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
