libss7 / sip / ast 10 screening issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux