SIP port negotiation

[Glenn Martindell]

I feel like I should know the answer to this question but am a little confused so here goes.

I have a SIP trunk from a telco provider into a Cisco CUBE.   I have an access list inbound on the interface that blocks non-standard RTP ports.   On this trunk, I was having an issue with my access list blocking inbound RTP due to negotiating a low destination port (8010)   In looking at my SIP setup messages, I can't seem to find where or who negotiated port 8010 as the CUBE destination port.   Since this is below standard RTP ports, my access list was blocking the RTP traffic.  I don't see CUBE sending a 200 ok to the initial invite and I'm assuming this is because I'm using fast start.   I only send a 100 trying.   Where should I see the negotiated CUBE destination (receive) port in my SIP debugs?

Thanks,

Glenn

[Roger Kallberg]

Not a direct answer to your question, but have you checked with the service provider what ports they use for RTP? You can’t make an assumption that they should be using a standard range of ports and block anything else in your ACL. Also to use the correct terminology, fast start is a thing in H.323, with SIP it’s called early offer.

[Roger Kallberg]

To add to what I wrote before this document is a great source of information for how to harden an IOS SBC. Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices 

Worth knowing is that newer ISRs use a much larger range of ports per default for RTP as they use 8000-48198, so if you’re limiting the ports to the older standard range of 16384-32768 you might want to consider making a configuration change in IOS so that it uses that range. That said as stated in my previous reply you also need to know what port range your service provider expects to use and account for that in your access list and IOS configuration.

[Jonathan Schulenberg]

Also, Fast Start is an H.323 term. There is always a 200 OK for a SIP call. Each side determines its own RTP receive port. As Roger indicated, the default range for an IOS gateway is 8000-48189; you can adjust it using the rtp-port command if necessary.

[Glenn Martindell]

Thanks all for the replies and yes I incorrectly stated fast start when I meant early offer.   Thanks for that correction.

I'm just a little confused why I don't see a 200 OK coming from my CUBE until after I cancelled the call and then CUBE responds with 200 OK.   I see "m=audio 10062 RTP/AVP 18 0 8 9 101" on the initial invite but nothing similar in the CUBE's response

Thanks,

Glenn

[Jonathan Schulenberg]

The 200 OK for the INVITE is sent when the called party answers. You won’t see that if the caller hangs up before then. If you see a CANCEL then the caller hung up before the call connected. 

If this is Early Offer there are two places where the SDP response could be sent back: the 180 Ringing / 183 Session Progress or 200 OK; early and delayed media, respectively. Early media also obligates the called party to play ringback. CUBE is passing these messages through to the other dial-peer. If the other side replies to CUBE with early media in its 180/183 that will be included (subject to voice class codec) in the response on the opposing dial-peer.

[Roger Kallberg · Accepted solution]

In an Early Offer call, the SDP message is sent by the calling endpoint in the initial invite message. The receiving endpoint sends their SDP in the 200 OK message sent when the call is answered. So if the initial invite is coming from the service provider, the SDP with the RTP port to use for that call leg would be included in the inbound invite and then the called, aka the SBC (Cube), would respond with a 200 OK with it's RTP port when the call is answered. Based on that what you're describing seems to be the expected behavior, or am I missing something here?

[Glenn Martindell]

Maybe I ended my debug too soon as I never see a 200 ok message even though the call was answered by voicemail before I cancelled the call.   At least I thought that's what I did.   Maybe I'll need to do another SIP debug to verify.   But thanks to all for the information.   I'll need to adjust my ports on the CUBE or my ACL.

Thanks,

Glenn

[Elliot Dierksen]

FWIW. I had to change some CUBE parameters when going from an ISRG2 to an ISR4K for certain service providers, notably Spectrum.

voice service voip
 rtp-port range 16384 32766

 That makes the ISR4K use the same port selection criteria as an ISRG2. I haven't tried that with an 8K yet.