I'm having a problem at the moment with incoming calls from our SIP provider. We're able to make outgoing calls with no problem, also internal extensions are able to dial each other with no problem.
When our DDI numbers are dialed from the outside world, the handsets do not ring. The callers hear about 20secs of silence (no rings heard, just silence) before "call failed" appears on their phone.
I think the problem is originating at our SIP provider, the SIP provider is saying the fault lies with us. Could you help me determine where the issue lies?
Our SIP provider points to two problems. They say the following:
- our system is not sending "180" or "183" messages
- "persistent 422 packages" - they've suggested increasing the "Min-SE:" setting to 3600, which I have done without any positive result.
When looking at our logs, we see differences between the SIP headers on these failed incoming calls compared to the successful ones from earlier. Here are examples of headers from a successful call and a failed one:
Successful:
Jul 27 12:28:49.207: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:colormatrix@80.246.200.167:5060 SIP/2.0
Record-Route: <sip:109.235.32.40;lr;ftag=as30272da5;did=e0e.bb71>
Via: SIP/2.0/UDP 109.235.32.40;branch=z9hG4bKedcb.bbf1dab339bb484e06216f9369dd2aff.0
Via: SIP/2.0/UDP 172.19.162.1;branch=pocos-rS4MusXox1l5QHyNxRy6uAXsEOdsEOdSxAktxGZKWgeKCgeS-RrKEAy057Nlzq4pWpefZD6AhGtwWDJjEqeuxRXfEsEJzDZ*
Max-Forwards: 70
From: <sip:+31495581765@109.235.35.42>;tag=as30272da5
To: <sip:+31402916522@sip.pocos.nl>
Contact: <sip:172.19.162.1;line=pcs-mp4KWiTsxRM6ERrdxRmpEry3xGnoxAxtuAxtuAMfWArKEAy*>
Call-ID: !!:xAH4WGnpZ8ZKERZgZDH8Esmdxpx3E8Z6xq76ZR4iZpzyxRy6uAXsEOdsEOdSxAktxGZK
CSeq: 102 INVITE
Date: Thu, 27 Jul 2017 12:49:47 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-external: 1
X-ANI: 0495581765
P-Asserted-Identity: <sip:+31495581765@109.235.35.42;user=phone>
Content-Type: application/sdp
Content-Length: 339
X-rand: 1056802331
X-csum: 0f127184f61106ca35a37a7df5fd7041
v=0
o=root 1485099250 1485099250 IN IP4 109.235.32.40
s=POCOS
c=IN IP4 109.235.32.40
t=0 0
m=audio 18614 RTP/AVP 8 9 111 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=rtcp:18615
Failed:
Jul 29 10:34:14.523: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:colormatrix@80.246.200.167:5060 SIP/2.0
Via: SIP/2.0/UDP 109.235.32.40:5060;branch=z9hG4bK7831212
From: sip:sipping@pocos.nl;tag=uloc-5941b2aa-33e5-fa466-35644cbe-a713d1f4
To: sip:colormatrix@80.246.200.167:5060
Call-ID: bae84624-f87aec13-ccaa1c5@109.235.32.40
CSeq: 1 OPTIONS
Content-Length: 0
Jul 29 10:34:14.523: //2312863/4D2301D5843E/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 109.235.32.40:5060;branch=z9hG4bK7831212
From: sip:sipping@pocos.nl;tag=uloc-5941b2aa-33e5-fa466-35644cbe-a713d1f4
To: sip:colormatrix@80.246.200.167:5060;tag=3E7524C8-1A5D
Date: Sat, 29 Jul 2017 10:34:14 GMT
Call-ID: bae84624-f87aec13-ccaa1c5@109.235.32.40
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 1 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 458
v=0
o=CiscoSystemsSIP-GW-UserAgent 6466 4031 IN IP4 80.246.200.167
s=SIP Call
c=IN IP4 80.246.200.167
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 80.246.200.167
m=image 0 udptl t38
c=IN IP4 80.246.200.167
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy
Jul 29 10:34:18.815: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:sip.pocos.nl:5060 SIP/2.0
Via: SIP/2.0/UDP 80.246.200.167:5060;branch=z9hG4bK21C02A13EE
From: <sip:colormatrix@sip.pocos.nl>;tag=3E75358C-22AE
To: <sip:colormatrix@sip.pocos.nl>
Date: Sat, 29 Jul 2017 10:34:18 GMT
Call-ID: A243ACF8-E9811E4-8002914D-A93CA9D
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1501324458
CSeq: 1989169 REGISTER
Contact: <sip:colormatrix@80.246.200.167:5060>
Expires: 120
Supported: path
Content-Length: 0
Jul 29 10:34:18.819: //2312864/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 80.246.200.167:5060;branch=z9hG4bK21C02A13EE;rport=5060
From: <sip:colormatrix@sip.pocos.nl>;tag=3E75358C-22AE
To: <sip:colormatrix@sip.pocos.nl>;tag=47dc960d0aec89efc47228ca957df0ae.b2b9
Call-ID: A243ACF8-E9811E4-8002914D-A93CA9D
CSeq: 1989169 REGISTER
WWW-Authenticate: Digest realm="sip.pocos.nl", nonce="<redacted>", qop="auth"
Content-Length: 0
Jul 29 10:34:18.819: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:sip.pocos.nl:5060 SIP/2.0
Via: SIP/2.0/UDP 80.246.200.167:5060;branch=z9hG4bK21C02B3DC
From: <sip:colormatrix@sip.pocos.nl>;tag=3E75358C-22AE
To: <sip:colormatrix@sip.pocos.nl>
Date: Sat, 29 Jul 2017 10:34:18 GMT
Call-ID: A243ACF8-E9811E4-8002914D-A93CA9D
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1501324458
CSeq: 1989170 REGISTER
Contact: <sip:colormatrix@80.246.200.167:5060>
Expires: 120
Authorization: Digest username="<redacted>",realm="sip.pocos.nl",uri="sip:sip.pocos.nl:5060",response="<redacted>",nonce="<redacted>",cnonce="<redacted>",qop=auth,algorithm=md5,nc=00000001
Content-Length: 0
Jul 29 10:34:18.827: //2312864/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 80.246.200.167:5060;branch=z9hG4bK21C02B3DC;rport=5060
From: <sip:colormatrix@sip.pocos.nl>;tag=3E75358C-22AE
To: <sip:colormatrix@sip.pocos.nl>;tag=47dc960d0aec89efc47228ca957df0ae.22d5
Call-ID: A243ACF8-E9811E4-8002914D-A93CA9D
CSeq: 1989170 REGISTER
Contact: <sip:colormatrix@80.246.200.167:5060>;expires=120
Content-Length: 0
It seems to me that the SIP provider is sending different headers when trying to initiate these failed calls - starting with OPTIONS rather than an INVITE header.
Am I correct in thinking this?
I will attach recent logs, both having used "debug ccsip messages" and "debug ccsip all". They are logs of multiple failed calls coming in and (afaik) little else.
The voice router I'm getting all of these logs from is a CISCO2901/K9 running IOS 15.1(4)M4.
Many thanks for your help!
