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

[Pavel Troller]

Hello again,
  please discard this noise. It seems I'm on the track now, som call 
redirecton is involved in the process and it seems the incorrect 
presentation comes from there.
  With regards,
    Pavel

> 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
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev