[Spce-user] Under what scenario could sipwise silently drop an invite?

Sat May 28 15:48:04 EDT 2016

Hi,

Last time i had issues with cisco gateways it had to do with UDP
fragmentation. Try to find out if those missed invite packets are arriving
in more then one frame. The following will allow you to check for
fragmented packets. Other then that, i'm out of ideas...

tcpdump -nq -i eth0:0 "ip[6:2] & 0x3fff != 0x0000"

---
Marc
o

---

On Sat, May 28, 2016 at 5:23 PM, Abel Alejandro <
aalejandro at alliedtechnologygrouppr.com> wrote:

> Actually this is my fault since I didn't explain properly, sorry for that
> guys.
>
> The voipmonitor detected 11 calls from this endpoint like this, however
> this very same endpoint made and received hundreds of calls yesterday alone
> successfully, this is a Cisco UC PBX.
>
> This is what the INVITE looks like with a couple details anomized. I do
> think everything looks good on this INVITE, port is okay and the domain is
> okay.
>
> INVITE sip:19727612465 at sip.fusetelecom.com:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.30.28.1:5060;branch=z9hG4bKE5DB37D
> From: "XXXX" <sip:787200xxxx at sip.fusetelecom.com>;tag=DB6B8ADC-17FC
> To: <sip:1972761xxxx at sip.fusetelecom.com>
> Date: Fri, 27 May 2016 14:10:16 GMT
> Call-ID: 924D11CC-234B11E6-BB27E6D2-8EBB5E3A at sip.fusetelecom.com
> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
> Min-SE:  600
> Cisco-Guid: 2376044366-0592122342-3139626706-2394644026
> User-Agent: Cisco-SIPGateway/IOS-12.x
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
> NOTIFY, INFO, REGISTER
> CSeq: 101 INVITE
> Max-Forwards: 70
> Timestamp: 1464358216
> Contact: <sip:787200xxxx at 10.30.28.1:5060>
> Call-Info: <sip:10.30.28.1:5060
> >;method="NOTIFY;Event=telephone-event;Duration=2000"
> Expires: 300
> Allow-Events: telephone-event
> Content-Type: application/sdp
> Content-Disposition: session;handling=required
> Content-Length: 324
>
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 6165 9658 IN IP4 10.30.28.1
> s=SIP Call
> c=IN IP4 10.30.28.1
> t=0 0
> m=audio 17106 RTP/AVP 18 0 8 101 19
> c=IN IP4 10.30.28.1
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=rtpmap:19 CN/8000
>
>
> On Sat, May 28, 2016 at 12:05 PM, Marco Teixeira <admin at marcoteixeira.com>
> wrote:
>
>> It was an example.
>> What i meant was that, usually, sniffers set the NIC to promiscuous,
>> meaning that they will catch whatever garbage arrives at the IP stack. The
>> iptables was an example. Others have pointed before, maybe your config is
>> not binding to the correct port ? maybe you don't have the correct domain
>> configured in sipwise ?
>>
>>
>> ---
>> Best regards
>> Marco
>> ---
>>
>>
>> On Sat, May 28, 2016 at 1:18 PM, Abel Alejandro <
>> aalejandro at alliedtechnologygrouppr.com> wrote:
>>
>>> Hey Marco,
>>>
>>> I do not mean the server iptables, I do not run anything other than
>>> sipwise + sniffer, I mean the anti DDoS of the sipwise itself.
>>>
>>>
>>>
>>> On Sat, May 28, 2016 at 8:04 AM, Marco Teixeira <admin at marcoteixeira.com
>>> > wrote:
>>>
>>>> Hi Abel,
>>>> Carefull with your assumptions. As an example, if i run sip-ngrep on
>>>> the server, it will see all the traffic even before iptables drops it...
>>>> Em 27/05/2016 20:12, "Abel Alejandro" <
>>>> aalejandro at alliedtechnologygrouppr.com> escreveu:
>>>>
>>>>> Well, the network capture is a network application that runs on the
>>>>> same sipwise server, its from the voipmonitor.org guys, I dont see
>>>>> how the network sniffer could capture the data and at the same time the
>>>>> server not deliver it to the kamalio process.
>>>>>
>>>>> I sent you the pcap capture privately, but yes the domain looks
>>>>> correct. Is there no chance the endpoint was banned during this time? Would
>>>>> that skip the logs?
>>>>>
>>>>>
>>>>> On Fri, May 27, 2016 at 2:59 PM, Daniel Grotti <dgrotti at sipwise.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Well if no request are on Kamailio-lb, then invites never reached the
>>>>>> server.
>>>>>> Are you sure the invite was heading to the right sip domain?
>>>>>>
>>>>>> Daniel
>>>>>> On May 27, 2016 8:51 PM, Abel Alejandro <
>>>>>> aalejandro at alliedtechnologygrouppr.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am testing a voipmonitor and just saw an interesting call where an
>>>>>> endpoint sent to sipwise 3 invites and it never got answered. Mind you I am
>>>>>> doing the voipmonitor capture at the sipwise server itself so there is no
>>>>>> chance of network packet loss here.
>>>>>>
>>>>>> When I take a look at the logs I dont even see the request
>>>>>> in kamailio-lb.log or kamailio-proxy.log , is there any other place I could
>>>>>> check?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Abel Alejandro*
>>>>>>
>>>>>> 787 586 8313 | 787 705 0555
>>>>>> <joquendo at alliedtechnologygrouppr.com>
>>>>>>
>>>>>> 400 Calle Calaf 477
>>>>>> San Juan, PR 00918
>>>>>> aalejandro at alliedtechnologygrouppr.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Abel Alejandro*
>>>>>
>>>>> 787 586 8313 | 787 705 0555
>>>>> <joquendo at alliedtechnologygrouppr.com>
>>>>>
>>>>> 400 Calle Calaf 477
>>>>> San Juan, PR 00918
>>>>> aalejandro at alliedtechnologygrouppr.com
>>>>>
>>>>> _______________________________________________
>>>>> Spce-user mailing list
>>>>> Spce-user at lists.sipwise.com
>>>>> https://lists.sipwise.com/listinfo/spce-user
>>>>>
>>>>>
>>>
>>>
>>> --
>>> *Abel Alejandro*
>>>
>>> 787 586 8313 | 787 705 0555
>>> <joquendo at alliedtechnologygrouppr.com>
>>>
>>> 400 Calle Calaf 477
>>> San Juan, PR 00918
>>> aalejandro at alliedtechnologygrouppr.com
>>>
>>
>>
>
>
> --
> *Abel Alejandro*
>
> 787 586 8313 | 787 705 0555
> <joquendo at alliedtechnologygrouppr.com>
>
> 400 Calle Calaf 477
> San Juan, PR 00918
> aalejandro at alliedtechnologygrouppr.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20160528/a53baec0/attachment-0001.html>