RTP IP Manipulation?

[RedTech443]

We have some new 9608/9611 sip phones connecting to Avaya Session manager 6.3, they are on the outside of our firewall coming in through an audiocodes dmz setup. The phones register, we can make calls internally based on what is allowed in the dialplan and we can see them registered. However we have no audio in either direction. When we wireshark, we can see that the RTP data being sent back from the phone is going to the wrong IP address.

My question is, is there anyway to manipulate the outgoing RTP ip address and tell it where to send its RTP data. The remote phone is behind a standard home / small office setup.

 

[kyle555]

46xx:
##################### PORT SETTINGS (SIP ONLY) #####################
##
## UDP Minimum Port Value
## Specifies the lower limit of the UDP port range
## to be used by RTP/RTCP or SRTP/SRTCP connections.
## (1024 -65503).
## Note : This setting is applicable for 1603 SIP phones also.
## Note: For H1xx SIP R1.0 and later the first half of the range is used for audio
## and the second half for video.
## SET RTP_PORT_LOW 5004
##
## UDP Port Range
## Specifies the range or number of UDP ports
## available for RTP/RTCP or SRTP/SRTCP connections.
## This value is added to RTP_PORT_LOW to determine
## the upper limit of the UDP port range (32-64511).
## Note : This setting is applicable for 1603 SIP phones also.
## Note: For H1xx SIP R1.0 and later the first half of the range is used for audio
## and the second half for video.
## SET RTP_PORT_RANGE 40

 

[RedTech443]

Yeah I saw this also, but I am confused because I also get the same results when using soft phones, like one-x communicator or x-lite.

 

[kyle555]

There's port range preferences in the "network settings" of One-X Communicator to set your RTP ports and I'm sure Xlite has the same.

Now, I re-read your post and you say "the rtp data being sent from the phone is to the wrong IP"

What do you mean by that? The phone is sending direct to the internal IP address and not the outside IP of the Audiocodes in the DMZ? Say if you called that phone from inside your network, the first SIP INVITE out to that phone would have what IP in the c= line in the SDP of the invite? That's ultimately what's telling the phone what to do.

That Audiocodes gateway needs to act a bit more like an SBC and handle the NAT on either end. What kind of audiocodes device do you have?

 

[RedTech443]

Yes you are exactly correct, the RTP ip address going back from the phone on the outside of the network is trying to communicate with an internal IP adress and not the public IP address or fqdn. I assumed this is some sort of funky NAT issue going on, but I am unable to prove this since I have no access to the audiocodes system.

I am not sure of the exact version of the AC device in use. I think I heard mediant or something like this.

 

[kyle555]

What kind of audiocodes device do you have? I don't think there's any certified via devconnect for remote workers like you're trying to do. That means you're pretty much on your own for setting it up!

Here's the one for the Avaya SBC:

https://www.devconnectprogram.com/fileMedia/download/2171d13a-7324-46b5-90d3-27441a3fca7b

Basically, you've got to set it up to pitch and catch from the inside to the outside and vice versa. Avaya's SBC is nice in that it has traceSM built in so you can just run a nice terminal trace and see what's up on both sides of the device.

If you look at a trace from the Audiocodes inside/outside (or, from the phone and from the SM if you can't see the Audiocodes), you're going to see what the Audiocodes box does as an SBC - it basically intercepts and re-writes SIP messages. So, to/from the phone, in the contact and via headers, you should see public IP addresses. On the private side to SM, you should see private IPs.

The thing that tells the endpoints in the conversation what IP to send audio to is the c= line in the SDP of a SIP message - an INVITE, a TRYING, 200OK, or ACK - it can be in any number of message types. The audiocodes needs to take that info from internal being sent to your phone, it needs to send something back to SM to open audio on it's own IP - so your inside network has a 2 way leg set up to/from the SBC, and then the SBC needs to send that SIP msg to your phone, but with a c= line to the SBCs outside interface and then set that 2 way stream on the outside and then bridge them together. That's a little 1 paragraph overview of remote workers on SBCs.

Now, what did you do for PPM? That's in the sipera doc to, but your SIP phone downloads the 46xx, but upon registration downloads PPM. That's where all sorts of config like primary/backup SM are, keys programmed on the Avaya phone, etc. Its done to SM on HTTPS (or HTTP if you really want)
Normally, it happens automagically in the private network, but you've got to explicitly specify the outside interface of the SBC in the 46xx file and built an application flow to basically proxy HTTP/S requests to that IP thru the SBC. You could do it just on your firewall, but you'd be splitting how which public IPs ports are handled coming into your network. Generally, I've just seen people give a public IP totally forwarded to the SBC and let it handle what needs to be done.

Honestly though, get a wireshark from the phone and a traceSM (you can write out a pcap from it by pressing "w") and prove the audiocodes is asking the outside device to send audio to an internal ip and get the help from them. It can't be that tough!

 

[RedTech443]

So basically I need to configure the AC device to handle the c= line of the SDP message to tell the phone to communicate back on the public IP instead of the private IP?

The PPM data I have not even got to yet, but I knew I was going to need ports open for it. As for the 46xx file, I am not really using this so much at this point. For the physical phones we are manually entering sip settings via the craft menu. I think I read in the docs for PPM to work you need 80 or 443 open like you say. Right now I am still working on audio both directions, once we get that going I will work on PPM as well.

Thanks for the pcap from traceSM tip, going to try that now.

 

[kyle555]

Yes. That's what you need from the Audiocodes/SBC side.

RePM
When a phone registers to SM, SM will tell it where the PPM server is. Because that's all inside HTTP, it won't be NATted by the SBC going to the phone outside to say "don't use

https://privateSMIP:443,

use

https://publicIP:443

instead!" That configuration element is also in the settings file:

## ENABLE_PPM_SOURCED_SIPPROXYSRVR parameter enables PPM as a source of SIP proxy server information.
## Value Operation
## 0 Proxy server information received from PPM will not be used.
## 1 Proxy server information received from PPM will be used (default).
## This parameter is not supported in IP Office environment as PPM is not supported.
## This parameter is supported by:
## 96x1 SIP R6.0 and later
## 96x0 SIP R2.4.1 and later
## 1603 SIP R1.0 and later
## H1xx SIP R1.0 and later
## SET ENABLE_PPM_SOURCED_SIPPROXYSRVR 1.
##
## CONFIG_SERVER specifies the address of the Avaya configuration server.
## Zero or one IP address in dotted decimal or DNS name format,
## optionally followed by a colon and a TCP port number.
## The value may contain 0 to 255 characters; the default value is null ("").
## This parameter is not supported in IP Office environment as PPM is not supported.
## This parameter is supported by:
## 96x0 SIP R2.6.7 and later
## H1xx SIP R1.0 and later
## SET CONFIG_SERVER ppm.myco.com

 

[RedTech443]

Ah ok good to know.

I also believe (correct me if I am wrong) the setting on the craft menu under sip global settings has a "configuration server" setting where you can specify the IP address of the PPM server. This would be used instead of the 46xx setting file from what I understand.

 

[kyle555]

Yeah. For your sanity, maybe have a settings file for these sets that you know works. If you get PPM working, then it would be equally easy to do it to serve 46xx outside even if you only enable that access when you turn up a new set or try to do firmware updates. Local DHCP + manually entering HTTPSRVR and HTTPPORT would be the only manual config needed.

 

[RedTech443]

Gotcha thanks, once we get all this working I might look into a group setting in the 46xx file to have the settings reside there. Just need to get everything working manually first Thanks for your help again.

 

[RedTech443]

In regards to PPM - I am looking at my test lab and when the phone first logs in I see that it request PPM data.

How is the done, does the phone first ask for PPM data from the server, the server authenticates the phone is a registered user then sends requested PPM data? My trace below of the PPM data.

 

[kyle555]

Your test lab has no NAT to SM, right?
Default is that the phone sees the user agent it registers to as Avaya SM, so it asks via HTTP from that address to get PPM.

If you look in the "Getallendpointconfiguration response" you'll see all sorts of stuff like key programming and whatnot being sent to the phone.

You'd need to use 46xx or manual config in the phone to specify a different IP - ie. the outside interface IP that maps to SM internally

 

[RedTech443]

Yes correct, this is a local internal flat network for testing. Just wanted to verify this.

At the moment we are still working on figuring out how to get the c= line of the SDP message configured to send out the public ip instead of internal.

 

[kyle555]

Fair enough. In your traceSM, if you call the phone on the other side of the SBC, look at that C line in the SDP offer back from the Audiocodes and ask your support "why's your audiocodes asking me to send to the public non-natted IP? Or, capture on the phone/Audiocodes "why is the phone being asked to send to a private internal IP?

 

[RedTech443]

That is basically where I am at right now, I had to go back to 101 networking to verify how the encapsulation works when handling rtp / sdp messages in a sip header. Once I figured out this is all done via the SBC side I was good. Now I need to figure out why that is happening and how to fix it on the audiocodes side. I found some good docs from AC that might help, I think I am on the right track now anyway.