incoming calls to user aliases failing

145 views
Skip to first unread message

gabriel

unread,
Jan 29, 2016, 7:39:45 PM1/29/16
to sipxcom-users
hey guys, 

this problem started happening yesterday and I have no idea what the problem is or how to fix it atm. 

so I have a SIP trunk with a bunch of DIDs. Some are assigned to the auto-attendant via the dial plan some are assigned to the users in the alias field. 

Since yesterday morning, all the users DIDs stopped receiving calls. Only the DIDs specified in the "Attendant Aliases" in the auto-attendant dial plan work. If I move a DID from the user to the AA then it works. 

I did some initial debugging between SIPx and the ITSP and I am seeing 403s being sent out something like this: 


IP 192.168.11.2.5080 > 216.115.69.144.5060: UDP, length 715
E.....@.@.NX.....sE.........SIP/2.0 403 Forbidden
From: <sip:+140...@fl.gg>;tag=gK027baaaa
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK70c8.f6a7bdc3f495e8e45cd9ad2983679862.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK70c8.d6a26b8344658a67b1b4449efde3362a.2
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK70c8.8e6292577a23a9af116295fa222424a5.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B2cd42aba6c32a584
CSeq: 18764 INVITE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Supported: replaces
Contact: <sip:~~id~bri...@61.11.20.207:5080;transport=udp>
Reason: ~~id~bridge;cause=213;text="Relayed Error Response"
Content-Length: 0

--
in the sipxbridge.log I do see:

"2016-01-30T00:30:17.535000Z":35547:OUTGOING:INFO:sipx.yvoice.local:Thread-1414:00000000:sipxbridge:"Sent SIP Message :\n----Remote Host:216.115.69.144---- Port: 5060----\nSIP/2.0 403 Forbidden\r\nTo: <sip:+140...@fl.gg>\r\nFrom: <sip:+140...@fl.gg>;tag=gK020ab33e\r\nVia: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKe542.ecd05c6069a2a85d181db1f3bbaa9266.0\r\nVia: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bKe542.411d02bf7bbc3c931cc6dd194cdb6f68.2\r\nVia: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKe542.0388de0a5fb58a62397e62f41eb6d5d2.0\r\nVia: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B3aa06914c625f231\r\nCall-ID: 1275260098...@216.221.154.11\r\nCSeq: 11542 INVITE\r\nServer: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)\r\nSupported: replaces\r\nContact: <sip:~~id~bri...@61.11.20.207:5080;transport=udp>\r\nReason: ~~id~bridge;cause=213;text=\"Relayed Error Response\"\r\nContent-Length: 0\r\n\r\n--------------------END--------------------\n"

---

before that: 

"2016-01-30T00:29:30.866000Z":34911:OUTGOING:INFO:sipx.yvoice.local:Thread-1405:00000000:sipxbridge:"Sent SIP Message :\n----Remote Host:216.115.69.144---- Port: 5060----\nSIP/2.0 482 Loop detected\r\nTo: <sip:+140...@fl.gg>\r\nFrom: <sip:+140...@fl.gg>;tag=gK0465616a\r\nVia: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK758c.e44c9fe6f2ece0867c93ab974c13b12c.0\r\nVia: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK758c.d5746347e3dd977575d009dbc1107958.2\r\nVia: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK758c.611fff38c0541995670de19782b1850f.0\r\nVia: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04B7d287a29ed67a298\r\nCall-ID: 127534889...@216.221.154.11\r\nCSeq: 1770 INVITE\r\nServer: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)\r\nContent-Length: 0\r\n\r\n--------------------END--------------------\n"



I am not sure why this is happening yet, I hope to figure it out. For now incoming calls go trough the main line then callers dial the extension, call gets transferred, it works fine that way. Phones are all Polycom VVX various models, various firmware - all experience the same issue. 


I just turned on homer and will do some more debugging there, but was wondering where should I be looking next. 

The server is running sipx 15.12 

-gabriel

Todd Hodgen

unread,
Jan 29, 2016, 11:54:00 PM1/29/16
to gabriel, sipxcom-users

What changes happened before this started happening?  


Check the logs in Diagnostics/System Audit around the time it started - you mind find a clue there.


Can you do a stare and compare between a failing call and one that worked prior to yesterday?


Confirm the ITSP is sending the call to you via 5080.  I don't see that in this capture.


Try a trace with TCPDUMP - from CLI - tcpdump -w filename.pcap







From: sipxco...@googlegroups.com <sipxco...@googlegroups.com> on behalf of gabriel <gab...@gmail.com>
Sent: Friday, January 29, 2016 4:39 PM
To: sipxcom-users
Subject: [sipxcom-users] incoming calls to user aliases failing
 
--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/ae9b9777-9813-4d27-9f57-93ac91dfa2de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tony Graziano

unread,
Jan 30, 2016, 5:16:46 AM1/30/16
to sipxcom-users
Check the configuration of your gateway against the logs you have and make sure the sending gateway/s are identical. Insee several IP addresses there which means the itsp may be an aggregator and the calls coming in are from several different IP addresses.

Relayed error means they are coming from an address that isn't trusted. Test thisbby creating unmanaged gateways with those same ip addresses and try again.

It's likely an upstream itsp routing change caused this.

Roger Northrop

unread,
Feb 1, 2016, 9:35:22 AM2/1/16
to sipxcom-users
Check your Firewall to see if the ip address has been Blacklisted.  You will want to check this in Command line via ssh.  if you find the iPAddress you could whitelist it


On Friday, January 29, 2016 at 6:39:45 PM UTC-6, gabriel wrote:
hey guys, 

this problem started happening yesterday and I have no idea what the problem is or how to fix it atm. 

so I have a SIP trunk with a bunch of DIDs. Some are assigned to the auto-attendant via the dial plan some are assigned to the users in the alias field. 

Since yesterday morning, all the users DIDs stopped receiving calls. Only the DIDs specified in the "Attendant Aliases" in the auto-attendant dial plan work. If I move a DID from the user to the AA then it works. 

I did some initial debugging between SIPx and the ITSP and I am seeing 403s being sent out something like this: 


IP 192.168.11.2.5080 > 216.115.69.144.5060: UDP, length 715
E.....@.@.NX.....sE.........SIP/2.0 403 Forbidden
From: <sip:+1...@fl.gg>;tag=gK027baaaa
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK70c8.f6a7bdc3f495e8e45cd9ad2983679862.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK70c8.d6a26b8344658a67b1b4449efde3362a.2
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK70c8.8e6292577a23a9af116295fa222424a5.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B2cd42aba6c32a584
CSeq: 18764 INVITE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Supported: replaces
Contact: <sip:~~id~bri...@61.11.20.207:5080;transport=udp>
Reason: ~~id~bridge;cause=213;text="Relayed Error Response"
Content-Length: 0

--
in the sipxbridge.log I do see:

"2016-01-30T00:30:17.535000Z":35547:OUTGOING:INFO:sipx.yvoice.local:Thread-1414:00000000:sipxbridge:"Sent SIP Message :\n----Remote Host:216.115.69.144---- Port: 5060----\nSIP/2.0 403 Forbidden\r\nTo: <sip:+1...@fl.gg>\r\nFrom: <sip:+1...@fl.gg>;tag=gK020ab33e\r\nVia: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKe542.ecd05c6069a2a85d181db1f3bbaa9266.0\r\nVia: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bKe542.411d02bf7bbc3c931cc6dd194cdb6f68.2\r\nVia: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bKe542.0388de0a5fb58a62397e62f41eb6d5d2.0\r\nVia: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B3aa06914c625f231\r\nCall-ID: 1275260098...@216.221.154.11\r\nCSeq: 11542 INVITE\r\nServer: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)\r\nSupported: replaces\r\nContact: <sip:~~id~bri...@61.11.20.207:5080;transport=udp>\r\nReason: ~~id~bridge;cause=213;text=\"Relayed Error Response\"\r\nContent-Length: 0\r\n\r\n--------------------END--------------------\n"

---

before that: 

"2016-01-30T00:29:30.866000Z":34911:OUTGOING:INFO:sipx.yvoice.local:Thread-1405:00000000:sipxbridge:"Sent SIP Message :\n----Remote Host:216.115.69.144---- Port: 5060----\nSIP/2.0 482 Loop detected\r\nTo: <sip:+1...@fl.gg>\r\nFrom: <sip:+1...@fl.gg>;tag=gK0465616a\r\nVia: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK758c.e44c9fe6f2ece0867c93ab974c13b12c.0\r\nVia: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK758c.d5746347e3dd977575d009dbc1107958.2\r\nVia: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK758c.611fff38c0541995670de19782b1850f.0\r\nVia: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04B7d287a29ed67a298\r\nCall-ID: 127534889...@216.221.154.11\r\nCSeq: 1770 INVITE\r\nServer: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)\r\nContent-Length: 0\r\n\r\n--------------------END--------------------\n"

gabriel

unread,
Feb 1, 2016, 12:45:44 PM2/1/16
to sipxcom-users
@Todd. 

I don't have the exact moment of when it stopped working but the only change I did that morning was to change the dial plan of one of the Unmanaged Gateways from 4 digit dialing to 3 digit dialing. I have removed all the extra gateways ever since to help with sorting this out. 

@Roger, yes, I did check the blacklisted IPs - not there. Like I said, if I take the numbers off the internal users aliases and move them to the 'auto-attendant dial plan aliases' everything works. 

@Tony: here's another capture on the wire where we can see the the communication with the itsp. 

---

dig _sip._udp.sip.flowroute.com SRV  +short



tcpdump -nnqt -s 0 -A  host sip-ca1.flowroute.com or host sip-nv1.flowroute.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 192.168.11.2.5080 > 216.115.69.144.5060: UDP, length 4
E.. ..@.@.Q......sE.........


IP 216.115.69.144.5060 > 192.168.11.2.5080: UDP, length 993
E...C...7.Rg.sE...........a.INVITE sip:1408...@61.11.20.207:5080 SIP/2.0
Record-Route: <sip:216.115.69.144;lr>
Max-Forwards: 66
Record-Route: <sip:216.115.69.132;lr>
From: <sip:+1408...@fl.gg>;tag=gK0e643d73
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK471c.2dd3e8fe5dfacce70b0817aac87b4a18.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK471c.376e0154f9600921ff300a8e2e35c35a.2
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK471c.7f9b86ee199085d2b52a43dbece1e471.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK0eBbbfa7092782ee01d
CSeq: 28907 INVITE
Content-Length:  221
Content-Type: application/sdp
P-Asserted-Identity: <sip:+1408...@fl.gg>

v=0
o=- 19777 16274 IN IP4 216.221.154.14
s=-
c=IN IP4 216.221.154.14
t=0 0
m=audio 14128 RTP/AVP 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

IP 192.168.11.2.5080 > 216.115.69.144.5060: UDP, length 715
E.....@.@.NX.....sE.........SIP/2.0 403 Forbidden
From: <sip:+1408...@fl.gg>;tag=gK0e643d73
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK471c.2dd3e8fe5dfacce70b0817aac87b4a18.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK471c.376e0154f9600921ff300a8e2e35c35a.2
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK471c.7f9b86ee199085d2b52a43dbece1e471.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK0eBbbfa7092782ee01d
CSeq: 28907 INVITE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Supported: replaces
Contact: <sip:~~id~bri...@61.11.20.207:5080;transport=udp>
Reason: ~~id~bridge;cause=213;text="Relayed Error Response"
Content-Length: 0


IP 216.115.69.144.5060 > 192.168.11.2.5080: UDP, length 312
E..TC...7.U..sE..........@..ACK sip:1408...@61.11.20.207:5080 SIP/2.0
Max-Forwards: 66
From: <sip:+1408...@fl.gg>;tag=gK0e643d73
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK471c.2dd3e8fe5dfacce70b0817aac87b4a18.0
CSeq: 28907 ACK
Content-Length: 0


IP 216.115.69.144.5060 > 192.168.11.2.5080: UDP, length 991
E...C...7.Rg.sE.............INVITE sip:1408...@61.11.20.207:5080 SIP/2.0
Record-Route: <sip:216.115.69.144;lr>
Max-Forwards: 66
Record-Route: <sip:216.115.69.132;lr>
From: <sip:+1408...@fl.gg>;tag=gK047a16e8
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK9ec1.78111462200a8ad4b25084072f499651.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK9ec1.2c9d5bbae660a24862debf3c0c19d2fd.2
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK9ec1.b9e5af31eda68036459bfba5f9596a1a.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04B5f2e246b12a73f6a
CSeq: 2005 INVITE
Content-Length:  221
Content-Type: application/sdp
P-Asserted-Identity: <sip:+1408...@fl.gg>

v=0
o=- 23839 20715 IN IP4 216.221.154.14
s=-
c=IN IP4 216.221.154.14
t=0 0
m=audio 27108 RTP/AVP 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

IP 192.168.11.2.5080 > 216.115.69.144.5060: UDP, length 713
E.....@.@.NZ.....sE.........SIP/2.0 403 Forbidden
From: <sip:+1408...@fl.gg>;tag=gK047a16e8
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK9ec1.78111462200a8ad4b25084072f499651.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK9ec1.2c9d5bbae660a24862debf3c0c19d2fd.2
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK9ec1.b9e5af31eda68036459bfba5f9596a1a.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04B5f2e246b12a73f6a
CSeq: 2005 INVITE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Supported: replaces
Contact: <sip:~~id~bri...@61.11.20.207:5080;transport=udp>
Reason: ~~id~bridge;cause=213;text="Relayed Error Response"
Content-Length: 0


IP 216.115.69.144.5060 > 192.168.11.2.5080: UDP, length 310
E..RC...7.U..sE..........>.$ACK sip:1408...@61.11.20.207:5080 SIP/2.0
Max-Forwards: 66
From: <sip:+1408...@fl.gg>;tag=gK047a16e8
Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK9ec1.78111462200a8ad4b25084072f499651.0
CSeq: 2005 ACK
Content-Length: 0


^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

---


this for reference is a call that does work (this is when calling a # associated with the AA dial plan) 

--
[root@sipx ~]# tcpdump -nnqt -s 0 -A  host sip-ca1.flowroute.com or host sip-nv1.flowroute.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
IP 192.168.11.2.5080 > 216.115.69.144.5060: UDP, length 4
E.. ..@.@.Q......sE.........


IP 70.167.153.130.5060 > 192.168.11.2.5080: UDP, length 605
E..y....7...F............e..BYE sip:~~id~bri...@64.81.70.107:5080;transport=udp SIP/2.0
Record-Route: <sip:70.167.153.130;lr>
Max-Forwards: 67
Record-Route: <sip:216.115.69.132;lr>
From: "Unavailable" <sip:+19493...@fl.gg;isup-oli=00>;tag=gK044cd70d
To: <sip:+1408D...@fl.gg>;tag=1095755647
Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK207a.7628ca06c08fbe110022197ffd0a6518.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK207a.12a1b639dbc067a7a097e9cbc5ec8731.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04Baa5360652c8222e8
CSeq: 3772 BYE
Content-Length:  0


IP 192.168.11.2.5080 > 70.167.153.130.5060: UDP, length 573
E..Y..@.@.......F........E.*SIP/2.0 100 Trying
From: "Unavailable" <sip:+19493...@fl.gg;isup-oli=00>;tag=gK044cd70d
Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK207a.7628ca06c08fbe110022197ffd0a6518.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK207a.12a1b639dbc067a7a097e9cbc5ec8731.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04Baa5360652c8222e8
CSeq: 3772 BYE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Contact: <sip:~~id~bri...@192.168.11.2:5080>
Supported: replaces
Content-Length: 0


IP 192.168.11.2.5080 > 70.167.153.130.5060: UDP, length 584
E..d..@.@.......F........P.5SIP/2.0 200 OK
From: "Unavailable" <sip:+19493...@fl.gg;isup-oli=00>;tag=gK044cd70d
To: <sip:+1408D...@fl.gg>;tag=1095755647
Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK207a.7628ca06c08fbe110022197ffd0a6518.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK207a.12a1b639dbc067a7a097e9cbc5ec8731.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK04Baa5360652c8222e8
CSeq: 3772 BYE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Contact: <sip:~~id~bri...@192.168.11.2:5080>
Supported: replaces
Content-Length: 0


IP 70.167.153.130.5060 > 192.168.11.2.5080: UDP, length 1130
E.......7...F............r.2INVITE sip:1408D...@64.81.70.107:5080 SIP/2.0
Record-Route: <sip:70.167.153.130;lr>
From: "ASSOC" <sip:+1408...@fl.gg>;tag=gK02229fa0
Max-Forwards: 66
Record-Route: <sip:216.115.69.132;lr>
Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK83cc.8ce6746c150a57d131af3faa8e161e06.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK83cc.441886819086474bc38126d404709071.1
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK83cc.80fb251524110d0dc0beafaad5aa69a6.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B586228326a69d426
CSeq: 1208 INVITE
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,  multipart/mixed
Content-Length:  220
Content-Type: application/sdp
P-Asserted-Identity: "ASSOC" <sip:+1408...@fl.gg>

v=0
o=- 27135 9416 IN IP4 216.221.154.12
s=-
c=IN IP4 216.221.154.12
t=0 0
m=audio 12058 RTP/AVP 0 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

IP 192.168.11.2.5080 > 70.167.153.130.5060: UDP, length 989
E.....@.@.. ....F...........SIP/2.0 200 OK
Record-Route: <sip:70.167.153.130;lr>
Record-Route: <sip:216.115.69.132;lr>
From: "ASSOC" <sip:+1408...@fl.gg>;tag=gK02229fa0
To: <sip:+1408D...@fl.gg>;tag=1837567768
Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK83cc.8ce6746c150a57d131af3faa8e161e06.0
Via: SIP/2.0/UDP 216.115.69.131;branch=z9hG4bK83cc.441886819086474bc38126d404709071.1
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK83cc.80fb251524110d0dc0beafaad5aa69a6.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B586228326a69d426
CSeq: 1208 INVITE
Server: sipXecs/xxxx.yyyy sipXecs/sipxbridge (Linux)
Contact: <sip:~~id~bri...@64.81.70.107:5080;transport=udp>
Content-Type: application/sdp
Content-Length: 220

v=0
o=sipxbridge 7819793749558994217 1 IN IP4 64.81.70.107
s=FreeSWITCH
c=IN IP4 64.81.70.107
t=0 0
m=audio 30504 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

IP 70.167.153.130.5060 > 192.168.11.2.5080: UDP, length 595
E..o....7...F............[..ACK sip:~~id~bri...@64.81.70.107:5080;transport=udp SIP/2.0
Record-Route: <sip:70.167.153.130;lr>
Max-Forwards: 67
Record-Route: <sip:216.115.69.132;lr>
From: "ASSOC" <sip:+1408...@fl.gg>;tag=gK02229fa0
To: <sip:+1408D...@fl.gg>;tag=1837567768
Via: SIP/2.0/UDP 70.167.153.130;branch=z9hG4bK83cc.63b9443f18f019cda711394c2a4d3b96.0
Via: SIP/2.0/UDP 216.115.69.132;branch=z9hG4bK83cc.e0d03a650059fdca63bf94d6868028c6.0
Via: SIP/2.0/UDP 216.221.154.11:5060;branch=z9hG4bK02B586c7429c415a7cc
CSeq: 1208 ACK
Content-Length: 0


^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel
---

Todd Hodgen

unread,
Feb 1, 2016, 1:11:47 PM2/1/16
to gabriel, sipxcom-users

What type of Gateway is that?  Is it PRI?  Can you try putting the alias in as 10 digit and 4 digit to see if it makes a difference.

 

You know the call is getting to the system, since it is being answered by your AA.  When you move it to the user alias, do you get an error message, or does it go to voicemail?

 

Have you tried a tcpdump at the interface to see what the to and from address looks like on the call?

 

Todd R. Hodgen

President / Founder

Sound IP Telecom

http://SIPTelecom.systems

206-432-4344 - Direct

206-390-4689 - Cell

 

SIP Telecom Logo1 copy

Your Puget Sound Telcom Partner

 

Do you Like Snow, Rain, Sleet, Hail, Thunder, Lightning?

If you do, then you will love the Cloud!

 

We appreciate your business referrals!

A Division of Misiu Systems LLC

--

You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

gabriel

unread,
Feb 4, 2016, 11:43:00 AM2/4/16
to sipxcom-users
thanks everyone for helping with this, I was able to fix it. It turned out that when I changed a dial plan that was going to an 'unmanaged gateway' from 4 to 3 digits, DIDs going to individual users stopped working. Even tough I got rid of the gateways in an effort to clean things up, I never deleted the dial plan(s). When I did, it immediately started working. 

I learned a few things debugging this issue, one thing concerning is that I tried to restore the backups from a day before this has happened and failed. Tried to restore 15.10 configs, vms and CDRs over a 15.12 system. It failed complaining about missing some elasticsearch directory.

Restoring 15.12 backups over 15.12 new system worked fine. I'll need to play more with the restore functionality but at this point I'm tempted to stop running this on bare metal and just use the KVM so I can take advantage of the VM snapshot/restore features...

Michael Picher

unread,
Feb 4, 2016, 7:35:13 PM2/4/16
to gabriel, sipxcom-users

I almost always recommend VM for the snapshot reason alone.  Plus in general people take their VM infrastructure pretty seriously.  Proper storage, host to host migration, etc.

We had a customer last week have both of their redundant hardware SBC's keel over.  Hardware sux.

Mike


--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/29c66be5-e7db-4f71-923d-83870512be26%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--

Michael Picher, VP of Product Innovation
eZuce, Inc.

300 Brickstone Square

Suite 104

Andover, MA. 01810


Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee(s) named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. FMS
Reply all
Reply to author
Forward
0 new messages