[Spce-user] [SOLVE] Re: inbound peer forbidden

pushakk pushakk at limbo.deathwing.net
Wed Jan 10 07:15:41 EST 2018


Hello,

finally I solved the issue. Cisco was sending calls from port 49507 not 
from 5060 and here are a check in kamailio

         avp_db_query("select vpg.id from provisioning.voip_peer_groups 
vpg left join provisioning.voip_peer_hosts vph on vph.group_id = vpg.id 
where vpg.has_inbound_rules = 1 and vph.ip = '$avp(s:ip)' and 
(('$avp(s:protoid)' = '1' and vph.port = $avp(s:port)) or 
('$avp(s:protoid)' != '1')) and vph.transport = $avp(s:protoid) order by 
vpg.priority asc", "$avp(s:peer_group_ids)");

Thank you.


El 10/01/18 a las 11:23, pushakk escribió:
>
> Hello Daniel.
>
> I have one inbound peering rule, in fact it is working with digium epigy.
>
> Thank you.
>
>
> El 10/01/18 a las 11:20, Daniel Grotti escribió:
>> Hi,
>> you have to add, at leas, 1 entry (empty rule, if you don't need 
>> inbound rules) in your INBOUND PEERING RULES, otherwise the calls 
>> will be rejected with 403.
>>
>> Daniel
>>
>>
>>
>> On 01/10/2018 10:58 AM, pushakk wrote:
>>>
>>> Hello everyone,
>>>
>>> I'm testing SPCE with two diferents MGW devs (CISCO and DIGIUM EPIGY).
>>>
>>>
>>>         T1 ----------------  GW (Cisco or epygi) ---------------- 
>>> spce -------------------------- asterisk
>>>
>>>
>>> Cisco 10.0.1.13
>>> epygi 10.0.1.21
>>>
>>> spce 10.0.1.25
>>> asterisk 10.0.1.20
>>>
>>> I have configured a peering test group with two peering servers and 
>>> I can enable or disable each one in convenience. I have configured 
>>> an outbound peering rule and an inbound peergin rule matching 'To 
>>> domain: 10.0.1.25' (it's working with epygi so i don't think it 
>>> could be the problem on CISCO).
>>>
>>> With epigy, I can register my spce against a sip_tunnel epygi 
>>> configuration using the register in 
>>> /etc/ngcp-config/templates/etc/ngcp-sems/etc/reg_agent.conf.tt2. 
>>> Once registered, I can both receive and make calls without any problem.
>>>
>>> However with CISCO I can't find the way to register the peer. Even 
>>> so, I can make outbound calls but the inbound calls are being 
>>> rejected by spce with 403 Forbidden error message. Is it mandatory 
>>> to register against the peer server? In the spce doc don't talk 
>>> anything about that.
>>>
>>> The log in lb and proxy are
>>>
>>> First in lb the invite arrive and it is redirect to proxy
>>>
>>> Jan 10 02:16:21 sip lb[26841]: NOTICE: <script>: New request on lb - 
>>> M=INVITE R=sip:951******@10.0.1.25:5060 F=sip:620******@10.0.1.13 
>>> T=sip:951******@10.0.1.25 IP=udp:10.0.1.13:58574 
>>> ID=F54750FA-F4DA11E7-836FD6B1-F6498286 at 10.0.1.13 
>>> UA='Cisco-SIPGateway/IOS-12.x'
>>>
>>> Jan 10 02:16:21 sip lb[26841]: NOTICE: <script>: *Relaying request, 
>>> du='sip:127.0.0.1:5062'*, fs='udp:127.0.0.1:5060' - 
>>> R=sip:95******@10.0.1.25:5060 
>>> ID=F54750FA-F4DA11E7-836FD6B1-F6498286 at 10.0.1.13 
>>> UA='Cisco-SIPGateway/IOS-12.x'
>>>
>>> In proxy I have the error
>>>
>>> Jan 10 09:44:31 sip proxy[21316]: NOTICE: <script>: Call from PSTN - 
>>> R=sip:951******@10.0.1.25:5060 
>>> ID=90A0BD28-F51911E7-85C1D6B1-F6498286 at 10.0.1.13 
>>> UA='Cisco-SIPGateway/IOS-12.x'
>>>
>>> Jan 10 09:44:31 sip proxy[21316]: NOTICE: <script>: *No matching 
>>> inbound peer rule in any peering group, rejecting call* - 
>>> R=sip:951******@10.0.1.25:5060 
>>> ID=90A0BD28-F51911E7-85C1D6B1-F6498286 at 10.0.1.13 
>>> UA='Cisco-SIPGateway/IOS-12.x'
>>>
>>> And finally the lb return 403 Forbidden to Cisco
>>>
>>> Jan 10 02:16:22 sip lb[26862]: NOTICE: <script>: Reply from Inbound 
>>> - S=100 - Trying M=INVITE IP=udp:127.0.0.1:5062 
>>> ID=F58C4827-F4DA11E7-8376D6B1-F6498286 at 10.0.1.13 UA='<null>'
>>>
>>> Jan 10 02:16:22 sip lb[26862]: NOTICE: <script>: Sending reply, 
>>> fs='udp:10.0.1.25:5060' - 
>>> ID=F58C4827-F4DA11E7-8376D6B1-F6498286 at 10.0.1.13 UA='<null>'
>>>
>>> Jan 10 02:16:22 sip lb[26858]: NOTICE: <script>: Reply from Inbound 
>>> - *S=403 - Forbidden* M=INVITE IP=udp:127.0.0.1:5062 
>>> ID=F58C4827-F4DA11E7-8376D6B1-F6498286 at 10.0.1.13 UA='<null>'
>>>
>>> I have readed a few times the spce doc about peering but it is poor. 
>>> I don't know if the "no matching inbound peer rule" is causing the 
>>> 403 forbidden or if the forbidden is causing the "not matching 
>>> inbound peer rule".
>>>
>>> The traffic betwen Cisco GW and spce:
>>>
>>> U 10.0.1.13:52734 -> 10.0.1.25:5060
>>>   INVITE sip:951******@10.0.1.25:5060 SIP/2.0..Via: SIP/2.0/UDP 
>>> 10.0.1.13:5060;branch=z9hG4bKB76177B..From: 
>>> <sip:951******@10.0.1.13>;tag
>>>   =1E6E2EA8-1F07..To: <sip:951******@10.0.1.25>..Date: Wed, 10 Jan 
>>> 2018 09:48:50 GMT..Call-ID: 4BD97EEF-F52211E7-86FCD6B1-F6498286 at 10.0.1
>>>   .13..Supported: 
>>> 100rel,timer,resource-priority,replaces,sdp-anat..Min-SE: 
>>> 1800..Cisco-Guid: 1272505031-4112650727-2225602586-380178028
>>>   8..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, 
>>> BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGI
>>>   STER..CSeq: 101 INVITE..Max-Forwards: 70..Timestamp: 
>>> 1515577730..Contact: <sip:951******@10.0.1.13:5060>..Expires: 
>>> 180..Allow-Events: t
>>>   elephone-event..Supported: precondition..Content-Type: 
>>> multipart/mixed;boundary=uniqueBoundary..Mime-Version: 
>>> 1.0..Content-Length: 778.
>>>   ...--uniqueBoundary..Content-Type: 
>>> application/sdp..Content-Disposition: 
>>> session;handling=required....v=0..o=CiscoSystemsSIP-GW-UserAge
>>>   nt 2348 2527 IN IP4 10.0.1.13..s=SIP Call..c=IN IP4 10.0.1.13..t=0 
>>> 0..a=rtr..m=audio 18014 RTP/AVP 8 19..c=IN IP4 10.0.1.13..a=rtpmap:8
>>>    PCMA/8000..a=rtpmap:19 
>>> CN/8000..a=ptime:20....--uniqueBoundary..Content-Type: 
>>> application/x-q931..Content-Disposition: signal;handling
>>>   =optional..Content-Length: 
>>> 47........................l.!.951******p..951******....--uniqueBoundary..Content-Type: 
>>> application/gtd..Cont
>>>   ent-Disposition: 
>>> signal;handling=optional....IAM,..PRN,isdn*,,NET5*,..USI,rate,c,3,c,1..USI,lay1,alaw..TMR,02..CPN,00,,1,9
>>> #
>>> U 10.0.1.13 -> 10.0.1.25 +60 at 1480:119
>>> 51771525..CGN,04,,1,y,4,951******..CPC,09..FCI,,,,,,,y,..GCI,4bd8e2c7f52211e784a8001ae29a9040......--uniqueBoundary--..
>>> #
>>> U 10.0.1.25:5060 -> 10.0.1.13:52734
>>>   SIP/2.0 100 Trying..Via: SIP/2.0/UDP 
>>> 10.0.1.13:5060;rport=52734;branch=z9hG4bKB76177B..From: 
>>> <sip:951******@10.0.1.13>;tag=1E6E2EA8-1F0
>>>   7..To: <sip:951******@10.0.1.25>..Call-ID: 
>>> 4BD97EEF-F52211E7-86FCD6B1-F6498286 at 10.0.1.13..CSeq: 101 
>>> INVITE..Server: Sipwise NGCP Proxy
>>>   5.X..Content-Length: 0....
>>> #
>>> U 10.0.1.25:5060 -> 10.0.1.13:52734
>>>   SIP/2.0 *403 Forbidden*..Via: SIP/2.0/UDP 
>>> 10.0.1.13:5060;rport=52734;branch=z9hG4bKB76177B..From: 
>>> <sip:951******@10.0.1.13>;tag=1E6E2EA8-
>>>   1F07..To: 
>>> <sip:951******@10.0.1.25>;tag=1d24a28a0bded6c40d31e6db8aab9ac6.a227..Call-ID: 
>>> 4BD97EEF-F52211E7-86FCD6B1-F6498286 at 10.0.1.13..
>>>   CSeq: 101 INVITE..Server: Sipwise NGCP Proxy 5.X..Content-Length: 
>>> 0....
>>>
>>> It is an 403 error directly, no auth challenge for the invite 407 is 
>>> sent previously.
>>>
>>> Thank you very much.
>>>
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> https://lists.sipwise.com/listinfo/spce-user
>>
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> https://lists.sipwise.com/listinfo/spce-user
>
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20180110/bf3f974a/attachment-0001.html>


More information about the Spce-user mailing list