[asterisk-dev] Ast 11 / chan_sip: get_rpid/pai not setting CALLERID(num-pres)

[Pavel Troller]

Hello there,
  I'm trying to solve a problem with calling party data for SIP incoming
calls, where the data are taken from RPID or PAI headers. They are not
properly propagated to the CALLERID() function (especially the presentation).
  The symptoms are looking as follows:

[Feb  6 16:11:43] WARNING[1023][C-0000000b]: chan_sip.c:17374 get_pai: Presentation from PAI: 23, 1, 0
[Feb  6 16:11:43] WARNING[1023][C-0000000b]: chan_sip.c:8097 sip_new: Copying presentation: 23
cliscrn:orig pres=allowed_not_screened

The first line is a result of my added debugging statement to get_pai(),
added to its very end, and written as

ast_log(AST_LOG_WARNING,"Presentation from PAI: %x, %d, %x\n",callingpres, do_update, p->owner);

We can see, that the callingpres value is 0x23, which represents
AST_PRES_PROHIB_NETWORK_NUMBER (yes, it's a result of my former patch,
normally there would be AST_PRES_PROHIB_USER_NUMBER_NOT_SCREENED, brcause
when using PAI/Privacy headers, we cannot get the real screening info, but
I need this value instead). The values are changed, but, as the third
value indicates, p->owner is still zero, i.e. we still don't have a
channel to write these values into.

The second line is still from chan_sip, from sip_new(), and again my added
debug statement shows, that the presentation value is still present and
copied to the newly created channel structure.

However, the third line is my dialplan debugging output showing, that the
value of actual presentation known to Asterisk is allowed_not_screened, i.e.
an initial value of zero. The line reads as
exten => s,n,Verbose(1,cliscrn:orig pres=${CALLERID(num-pres)})

I'm out of ideas, where the value can get lost. The most interesting thing
is, that when the call is bridged to some B-party, the destination channel
is getting correct values! So, maybe an error in CALLERID() function ? But
for example for calls from DAHDI or IAX2, it shows always correct values...

Any hint, where to search for the bug, is appreciated! I'm willing to prepare
a patch, but for now, I'm stuck here.

With regards,
  Pavel