I'm struggling with what appears to be a bug in libss7... Asterisk 10.4.0, libss7 1.0.2, dahdi-linux-complete-2.6.1+2.6.1 When a call comes into the box using SIP (sendrpid=yes, trustrpid=yes), caller ID is not presented on the SS7 channel. A debug shows that libss7 thinks the call is supposed to be screened: [1] --OPTIONAL PARMS-- [1] Calling Party Number: [1] Nature of address: 3 [1] NI: 0 [1] Numbering plan: 1 [1] Presentation: 0 [1] Screening: 1 [1] Address signals: 875500000 [1] [ 0a 07 83 11 78 55 00 00 00 ] Yet, the dialplan clearly shows otherwise: Output of a: NoOp(${CALLERID(num-pres)}) results in: NoOp("SIP/switch_rba2-00005c9b", "allowed_not_screened") So my question is why is it screening the number when the screening status is allowed_not_screened ? If the call comes in via IAX2, this problem does NOT occur, however, something is different: Output of a: NoOp(${CALLERID(num-pres)}) results in: NoOp("SIP/switch_rba2-00005f5d", "allowed_passed_screen") and ss7 debug shows: [1] --OPTIONAL PARMS-- [1] Calling Party Number: [1] Nature of address: 3 [1] NI: 0 [1] Numbering plan: 1 [1] Presentation: 0 [1] Screening: 0 [1] Address signals: 875500098 [1] [ 0a 07 83 10 78 55 00 90 08 ] I have provisionally worked around this by adding the following to my dialplan: ExecIf($[${CALLERID(num-pres)}=allowed_not_screened]?Set(CALLERID(num-pres)=allowed)) Interestingly, the problem does not occur if the incoming SIP call terminated on the same box as the outgoing SS7 call yet a NoOp(${CALLERID(num-pres)}) still results in "allowed_not_screened". It's only when the call goes phone --SIP--> box 1 --SIP--> box2 that it starts screening incorrectly. I'm at a complete loss as to how to diagnose it. Instinctually I believe that this must be a bug in the SS7 code (libss7 or chan_dahdi) because the dialplan clearly shows that the presentation status in being passed accross via the SIP rpid mechanism and because it works if the call originates via IAX2 and then hops over the SIP hop with rpid. But what that cannot explain is why, on the other box (same setup) where the call comes into, it doesn't exhibit the same behaviour. I didn't have this problem when running Asterisk 1.8 with Chan_ss7 2.1.0 and dahdi-linux-complete-2.5.0.2+2.5.0.2. It's been since upgrading to Ast 10 with libss7 and dahdi-linux-complete-2.6.1+2.6.1 that it has occurred. Any suggestions would be appreciated! Thanks Greg