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
|