What Is Required On SBC/CUBE To Respond To Carrier's SIP Options PING?

[Michael Mertens]

I'm adding a 2nd SIP trunk to SBC/CUBE and am testing with the Test DID. I have outbound calls working but not inbound...I never see the INVITE because I'm not sending SIP 200 OKs in response to the carrier's SIP OPTIONS PING. What do I need in the CUBE/SBC to allow it to repond to the SIP Options PING from the new carrier IP BE? (I can see it is not responding by doing a "debug ccsip messages" and not see the response). 

I have the IP BE included in the voice services voip's IP trusted list, I have a route to the IPBE (show ip cef, show ip route, and the fact that outgoing calls to IPBE work), I have a destination-pattern dial-peer with IPBE specified...I've never had to configure anything specifically to allow a response to SIP OPTIONS PING from the carrier? (This deployment does not have CUCM, so I cannot leverage the CUCM SIP PING). 

I even tried applying the "voice-class sip options-keepalive up-interval 30" command on the dial-peer, and it shows up/up/active, but I still don't see me respond to the SIP Options in debug.

#show dial-peer voice sum

AD PRE PASS SESS-SER-GRP\ OUT TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VR
220 voip up up 0 ipv4:12.253.103.134 active NA

I'm perplexed to say the least. Thanks for any/all help!!

Mike

[Roger Kallberg]

How do you match the inbound dial peer? I’m making an assumption that you match on perhaps called number. If so it would be recommended to change that to use information in the VIA header in the inbound invite instead as that’s a much better match. Apart from that it’s important that you use bind statements on the dial peers so that the traffic is sourced from the correct interface.

[Michael Mertens]

Roger, 

Thanks for your input...every day I learn how little I know about SIP- What is the VIA header, and what/how do I match a dial-peer to it? You are right, that I'm matching the inbound call lef with the incoming called-number and that is bound to my outside interface (Carrier-assigned media/control IP)...
Any clarification or further ideas would be greatly appreciated!

Thanks!

Mike

[Roger Kallberg]

See this wonderful document for that and likely all that you'd probably didn't know that you did not know about call routing in IOS.

In Depth Explanation of Cisco IOS and IOS-XE Call Routing 

[Michael Mertens]

Roger, your DOC was very comprehensive and I don't believe I've come across that before,

So after further debugs and comparing it to a working site and looking at the packet capture, I see that the CUBE is indeed responding to the Out-of-Dialogue OPTIONS PING, however, it is responding using the inside address of the CUBE so is not getting routed/allowed out the FW. I can only find documentation online for enable the CUBE to initiate OOD OPTIONS and not how to configure/control the response. In the below document, it talks of pre-requisites.

Cisco UBE Out-of-dialog OPTIONS Ping for Specified SIP Servers or Endpoints  [Support] - Cisco Systems

I've created a voip dial-peer with sipv2 and the target of the IP BE sending the OPTIONS, along with binding it to the outside interface, but the CUBE still sources the IP packet (and SIP header info) with the inside address. After studying this today, I've concluded the OPTIONS PING and response are as follows in teh "Options PIC.png": The orange font is from the IPBE, the blue font is from the CUBE (I was confused by the from showing 12.253.102.86 (IPBE) and the to: showing 32.253.59.194 (CUBE outside), however after looking at the PCAP I see that this is just saying this is the response to the to/from). The third part shows the SDP information, but the crux of my problem is that the CUBE is responding to the OPTIONS with the inside address- see PNG "Packet Capture of Options Resonse".

Based on the doc above, I created a dial-peer 220 to match the IP BE using incoming called-number, however, it still sources the packet from the inside interface. 

do show dial-peer voice sum
dial-peer hunt 0
AD PRE PASS SESS-SER-GRP\ OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF

220 voip up up 0 ipv4:12.253.103.134 active NA
For server-grp details please execute command:show voice class server-group <tag_id>

!
dial-peer voice 220 voip
description Outgoing to AT&T -VoIP and PBX Call Leg
translation-profile outgoing pstn-out
no modem passthrough
session protocol sipv2
session target ipv4:12.253.103.134
incoming called-number .
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip profiles 1
voice-class sip options-keepalive up-interval 30
voice-class sip pass-thru content sdp
voice-class sip bind control source-interface GigabitEthernet0/0/2
voice-class sip bind media source-interface GigabitEthernet0/0/2
fax-relay ecm disable
fax-relay sg3-to-g3
fax rate disable
fax nsf 000000
fax protocol pass-through g711ulaw
ip qos dscp cs3 signaling
no vad
!

!
interface GigabitEthernet0/0/2
description SIP#2 Outside 
ip address 32.253.59.194 255.255.255.248
negotiation auto
end

Any ideas would be GREATLY apprecaited on how to get the CUBE to source the proper outside address.

Thanks!

Mike

[Roger Kallberg]

The option ping does not have any called number, that’s why you should use the IP information in the VIA header to match the inbound dial peer, that and the fact that the VIA information is matched before called or called numbers. How to do that is outlined in the document I shared.

Apart from that it’s my strongest recommendation to use different dial peers for inbound and outbound direction, primarily because it makes it easier to troubleshoot and follow the flow of the call.

[Roger Kallberg · Accepted solution]

This is what the document outlines as an example.

voice class uri PSTN sip
 host ipv4:14.50.244.2
 host ipv4:14.50.244.20
!
dial-peer voice 200 voip
 description INCOMING DIAL PEER FROM PSTN 
 session protocol sipv2
 incoming uri via PSTN
 voice-class codec 1
 voice-class sip bind control source-interface GigabitEthernet0/0/2
 voice-class sip bind media source-interface GigabitEthernet0/0/2
 no vad
!
dial-peer voice 220 voip
 no incoming called-number .

Modify the IP(s) in the voice class to match with information you see in the VIA header for the SIP dialogue for transactions originating from the service provider.

[Michael Mertens]

Roger, 
I really, really, really appreciate your input and solution!!!! This fixed my immediate problem, and I now answer to the PINGs from the IPBE with that incoming dial-peer (who is bound to the correct interface). This also has opened up an entirely new education front on SIP with the URI matching and voice class URI commands...I've been "playing with it" all day!

I was really stuck and had no avenue forward- I greatly appreciate your time and input!!!! Words do not capture it...

Mike

[Roger Kallberg]

You’re very welcome. Glad that I could help you out and that you learned something new. That makes me really happy to hear.