[asterisk-ss7] libss7 / sip / ast 10 screening issue
Gregory Massel
greg at csurf.co.za
Thu May 17 06:39:06 CDT 2012
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
More information about the asterisk-ss7
mailing list