Send Error If Outbound dial-peer session target Not Local Network

[AdamB32212]

First some background. We have the following setup:

PhoneSim1 : 172.16.5.6

RealPhone1 : 172.19.140.113

SBC has internal interface of 172.19.140.114 (+ 2 other external non-172.x.x.x interfaces)

Pings work among all three of the above devices (172.16.5.x and 172.19.140.x are connected and inter-routeable).

Now, if INVITE comes from the external side and is destined to RealPhone1, it works fine - SBC forwards the INVITE to RealPhone1.

But if INVITE comes from the external side and is destined to PhoneSim1 (different phone number, different dial-peer), the CUBE builds an appropriate message (i.e. INVITE w/rewritten fields and values) but fails to send it (even though an appropriate route is configured). Here's the debug dump:

186059: Sep 3 00:01:31.836: //2288/00088CF696DD/SIP/Error/HandleUdpSocketWrites:
Send failed errno 261
186060: Sep 3 00:01:31.836: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF47F880AB8
186061: Sep 3 00:01:31.836: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 for event 56
186062: Sep 3 00:01:31.836: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/ccsip_process_sipspi_queue_event: ccsip_spi_get_msg_type returned: 2 for event 54
186063: Sep 3 00:01:31.837: //2288/00088CF696DD/SIP/Error/act_socket_send_msg_failure:
Send Error to 172.16.5.6:5060 for transport UDP

Question: Is there some special config needed to allow SBC to direct incoming requests to networks that are ACCESSIBLE, though not directly tied to its interfaces?

[Mohammed al Baqari]

Hi,

Have you added destination subnet in the allowed trust list of the cube.?
Can you debug voice dialpeer all to see what dialpeer is matched? Did you
allow sip-sip on cube?

**** please remember to rate useful posts

[AdamB32212]

Have you added destination subnet in the allowed trust list of the cube.?
Yes, I have this in the config:
voice service voip
ip address trusted list
ipv4 172.16.5.6
(Although that is supposedly not needed because addresses from session target lines are automatically added to the list.)


Can you debug voice dialpeer all to see what dialpeer is matched?
Dial-peer matching works fine because I have only 2 outbound dial-peers and they have specific destination-patterns (for testing, I use 10-digit targets so that matching is perfect). I also see in the debug log the actual message that CUBE tries to send (i.e. modified INVITE) and it looks all-correct. And if I change the session target to a device on a native interface, the message gets sent.

Did you allow sip-sip on cube?
Yes.

voice service voip
allow-connections sip to sip

I've had this configuration (and different ones) for about 20 months now, and everything worked fine until I tried to forward the INVITE to a non-native address.

[Roger Kallberg]

As long as the router can communicate with the IP address that you point to in your dial peer it should work, it doesn’t matter if it’s a native address as you call it.

So far as per what you’ll describing it sounds like you might not have a call processing system involved in your system landscape, aka your phones act as independent devices. If so it would more likely be that the phone sim software isn’t responding correctly to the communication from your gateway.

If I’m reading your post wrongly can you please provide a bit of more specific details on your setup for us to help you out.

[AdamB32212]

Yes, it is very unexpected and I know that it should work.

But what I see in the log is that at the SBC/CUBE-level, the software is building the message (i.e. it populates the INVITE as I would expect to see it in a message sent downstream), and the log says:

...

482077: Sep 3 15:09:04.291: //5934/C8DDACBAA8C4/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:4565551023@sim1.mydomain.mil:5060 SIP/2.0
...

But from the following entries in the log it appears that lower in the stack there is a failure and the message does not get sent (in fact, nothing is captured on the interface on which it is supposed to be seen going out). Anyway, here's the rest of the log following the "Sent:" block (the snippet shown above):

482078: Sep 3 15:09:04.490: //5934/C8DDACBAA8C4/SIP/Error/HandleUdpSocketWrites:
Send failed errno 261
482079: Sep 3 15:09:04.491: //5934/C8DDACBAA8C4/SIP/Error/act_socket_send_msg_failure:
Send Error to 172.16.5.6:5060 for transport UDP
482080: Sep 3 15:09:04.491: %VOICE_IEC-3-GW: SIP: Internal Error (Socket conn refused): IEC=1.1.186.7.102.1 on callID 5934 GUID=C8DDACBA0BFF11ECA8C4AEAE24661513
482081: Sep 3 15:09:04.491: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIGetContentQSIG:
No Inbound Container Created !!!
482082: Sep 3 15:09:04.491: //-1/xxxxxxxxxxxx/SIP/Error/sipSPIGetContentQ931:
No Inbound Container Created !!!
482083: Sep 3 15:09:04.491: //5934/C8DDACBAA8C4/SIP/Error/sipSPI_ipip_ExtractAndAddPassthruCopyListDataToContainer:
Container is NULL
482084: Sep 3 15:09:04.491: //-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_free:
Freeing NULL pointer!
482085: Sep 3 15:09:04.491: //-1/xxxxxxxxxxxx/SIP/Info/info/512/udpsock_close_connect: Socket fd: 0 closed for connid 5 with remote port: 5060
482086: Sep 3 15:09:04.491: //5934/C8DDACBAA8C4/SIP/Info/sipSPIDeferCallClose: Entering here
482087: Sep 3 15:09:04.491: //5934/C8DDACBAA8C4/SIP/Media/sipSPIDropVideoFlowAroundSessions: IP_IP GW: deleting video flow around session, callid=5934
482088: Sep 3 15:09:04.491: //5934/C8DDACBAA8C4/SIP/Media/sipSPIHandleDestroyRtpSession: stream:7FF47F8C0558
482089: Sep 3 15:09:04.491: //5934/C8DDACBAA8C4/SIP/Error/sipSPIDestroyRtpSession:
SRTP session not destroyed id: 218959117l
482090: Sep 3 15:09:04.492: //5934/C8DDACBAA8C4/SIP/Error/sipSPIFlushDeferredQueue:
Invalid deferredQueue
482091: Sep 3 15:09:04.492: //-1/xxxxxxxxxxxx/SIP/Error/sipConnectionManagerUnregisterCtxtInConnection:
Connection not found for addr=172.16.5.6, port=5060 local_addr=172.19.140.114
482092: Sep 3 15:09:04.492: //-1/xxxxxxxxxxxx/SIP/Error/sipSPI_ipip_FreeSipRawSdp:
no sdp to free
482093: Sep 3 15:09:04.492: //5933/C8DDACBAA8C4/SIP/Info/critical/512/sentErrResDisconnecting: Sent an 3456XX Error Response
482094: Sep 3 15:09:04.492: //5933/C8DDACBAA8C4/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable

#at this point 503 gets sent back to the source of the INVITE.

I tried reloading the box but that didn't help. And again, if I only change the dial-peer's session target to a device on the subnet on which one of the SBC's interface sits (I call it "native", though that's just my way of calling it), then the forwarding of the INVITE  works fine.

I wonder if there's something in that error block that I pasted that could help in tracking down the root cause. I googled errno 261 but nothing relevant came up....

[Roger Kallberg · Accepted solution]

Try to change the protocol on the DP towards the SIM phone to TCP. I did a quick search on the error you get "%VOICE_IEC-3-GW: SIP: Internal Error (Socket conn refused): IEC=1.1.186.7.102.1 on callID" and that pointed me to this post. https://community.cisco.com/t5/ip-telephony-and-phones/problem-with-incoming-calls-on-a-cisco-2911/td-p/1612060

[AdamB32212]

Roger,

This afternoon, the problem went away and I was able to send/forward messages as expected. I suspect that maybe we had some odd networking issue (perhaps something with ARP?) that was faulting the lower stack? Not sure. The important thing is that the SBC sends messages now to either far-end phone. 

Thank you for your help!