Well, it's the A side anyways, in the box2. It seems chan_sip reads
trustrpid=yes in the wrong way, instead of ss7 channels.
On May 20, 2012, at 9:01 AM, Gregory Massel wrote:
>
>
> 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
--
_____________________________________________________________________
-- 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
