There is something wrong going on with the SRST testing.   almost all events i see the phone sending the REGISTER message with expires value as 0. This will make the SRST router not register the phone. as soon as the REGISTER message arrives from the phone with expires value 3600, we can clearly see the SRST router registering the phone by sending a 200 ok which is how it should work.   Received: REGISTER sip:172.16.11.1 SIP/2.0 Via: SIP/2.0/UDP 172.16.11.11:5060;branch=z9hG4bK4e89d0b5 From: <sip:+48220001001@172.16.11.1>;tag=00235e17ed4c01c749b8174c-df41091f To: <sip:+48220001001@172.16.11.1> Call-ID: 00235e17-ed4c015d-9d8e196b-cfa847fc@172.16.11.11 Max-Forwards: 70 Date: Wed, 03 Jul 2019 19:52:54 GMT CSeq: 205 REGISTER User-Agent: Cisco-CP7975G/9.4.2 Contact: <sip:519c34d5-c179-6ed3-85b3-6ded98a8d35a@172.16.11.11:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00235e17ed4c>";+u.sip!devicename.ccm.cisco.com="SEP00235E17ED4C";+u.sip!model.ccm.cisco.com="437" Supported: extended-refer,norefersub,X-cisco-srtp-fallback,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1 Content-Length: 0 Reason: SIP;cause=200;text="cisco-alarm:10 Name=SEP00235E17ED4C Load=SIP75.9-4-2SR3-1S Last=tcp_timeout" Expires: 3600   //SRST router sends 200 ok for this//   Jul 3 21:53:11: //1049/FC263CA18420/SIP/Msg/ccsipDisplayMsg: Sent: LAB-HQ-RTRV-01#SIP/2.0 200 OK Via: SIP/2.0/UDP 172.16.11.11:5060;branch=z9hG4bK4e89d0b5 From: <sip:+48220001001@172.16.11.1>;tag=00235e17ed4c01c749b8174c-df41091f To: <sip:+48220001001@172.16.11.1>;tag=C6D1A8-2026 Date: Wed, 03 Jul 2019 19:53:11 GMT Call-ID: 00235e17-ed4c015d-9d8e196b-cfa847fc@172.16.11.11 Server: Cisco-SIPGateway/IOS-15.7.3.M4b CSeq: 205 REGISTER Supported: X-cisco-srst-sis-1.0.0 Supported: X-cisco-srtp-fallback Contact: <sip:+48220001001@172.16.11.11:5060>;expires=1200;x-cisco-newreg Expires: 1200 Content-Length: 0   the only thing that is noticeable here is the difference in expires value which you can probably correct by doing   voice service voip sip registrar server expires max 3600 min 300   however the weird part is that we receive the REGISTER message from the phone all over again which is not right from the PCAPs i see that there is a small window during which the phone does register fine however after a few minutes, i start to see the same REGISTER/200 ok transaction happening again and again as if the phone never received the 200 ok from the SRST router. are the packet captures from the back of the phone or the SRST router? is the srst router and the phone in the same location or different locations?   a few things that you can try is by defaulting the configs to simplify things   voice register global default mode allow-hash-in-dn timeouts interdigit 4 system message SRST Mode max-dn 5 max-pool 5 timezone 28 ! voice register pool 1 id network 0.0.0.0 0.0.0.0 ! voice service voip sip registrar server expires !     ... View more

collect : debug ccsip verbose and the "show tech voice" of the router packet captures you can run a monitor session on the switch port where the phones are connected. ... View more

if you look at your REGISTER messages closely, you will see that they have expires value as 0. If this was a legit REGISTER request from a phone who is actually trying to register with SRST, i would see expires value as 3600. Value 0 means that it is not a register request but a keepalive message that phones usually send to their SRST router while being registered to the CUCM. for one case i see the expires value come in as 3600 and the SRST router sends 200 ok for the register and does register it. check SIP callid c8f9f968-6da215b5-23a5574c-a5a2c363@172.16.11.12. However eventually i see REGISTER requests coming to the SRST router all over again. your config seems OK. it is less about config and more about the stability of your connection between phone and CUCM and the phone and SRST router i would check and make sure that the phones have completely lost IP connectivity with the CUCM because it seems they are toggling between CUCM and SRST router. for testing just shut down the CCM service on your CUCM servers and then test. ... View more

just to understand correctly, when you call from an internal phone to another phone and forward the call to the pstn, the call works. however when someone from pstn network calls your internal phone and then you forward all to another pstn number the call fails? if this is the case, then you need to check your SIP trunk/h323 gateway for Calling Party Selection and use "last redirect number external" to send the internal DID of your phone to the pstn provider who might be rejecting the call. ... View more

your voip dial peer 43731 is going to act as an outgoing dial peer only because it has destination pattern configured you need to add "incoming called-number XXX" so that your voip dial peer gets matched as inbound dial peer. something like this: ! dial-peer voice 43731 voip incoming called-number . ! ... View more

Can you share the output of "debug ccsip all" when the phone tries to register? also the "show voice register pool all brief" MAC/IP address of the phone. ... View more

not an Apple/macbook user myself but if you have wireshark installed on the windows VM fusion, you can just run it on the ethernet interface and see if you have 2 way UDP/RTP traffic. else you could double click on the ? mark button on the CIPC to check for sent/receive packets while the call is active. ... View more

there are just 2 possibilities. Either the BYE packet didnt reach the cube router or it reached but it was discarded. either way you need a packet capture and ccsip debugs to find out the root cause. there could be a difference in the way the SIP BYE message is sent from the provider side in case of <9 minute calls versus >9 minute calls. if you can get the packet capture from the provider side comparing the 2 BYE messages, maybe you could get a clue (compare VIA headers, URIs, packet size etc) ... View more

provider can send this error, if during a dialogue, the SIP URI/from/To field changes within the SIP messages of the same transaction. since you have hidden all these headers we cannot say for sure if they are maintained same or changed to something different. what you can do to fix this is configure INVITE consumption on the cube router so that the RE-INVITE is not sent to the provider if they dont support it. some providers are not able to handle mid call re-invites to break media during HOLD/transfer events. Conf t Voice service voip Sip midcall-signaling passthru media-change exit this will ensure mid call re-invite is not sent and CUBE handles the 2 SIP legs separately. no business impact. thanks, Ishan ... View more