On 2012/05/20 04:02 AM, Gustavo Mársico wrote:
results in: NoOp("SIP/switch_rba2-00005c9b", "allowed_not_screened")
Is this a NoOp in your A side? If that so, chan_sip treats sendrpid=yes, trustrpid=yes as
00 ("user provided, not verified"), according to Q.764e page 24. That can
explain why ss7 side is sending the IAM with CPN with this indication.
No, it's as follows:
<sip phone> ---SIP(sendrpid=no,trustrpid=no,callerid=xxx)--- <box 1>
---SIP(sendrpid=yes,trustrpid=yes)--- <box 2> ---SS7--- PSTN
The NoOp is on box 2, the same one that receives the call with
trustrpid=yes and dials it out via chan_dahdi/libss7.
This is why:
ExecIf($[${CALLERID(num-pres)}=allowed_not_screened]?Set(CALLERID(num-pres)=allowed))
Works around the problem.
On May 17, 2012, at 8:39 AM, Gregory Massel wrote:
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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7
