One-way audio on SIP phone

[Undercat]

I configured SP1 for GV, as per the blog post instructions. Configured SP3 as the SIP proxy, also as per instructions...with one difference: I could not, no matter what I tried, get the SIP phone to ring using {ph1,SP3(abc@local_client)} as the inbound call route on SP1. Not sure what 'local_client' is supposed to route to, anyway.

So I substituted it with the SIP target of the IP phone itself: {ph1, SP3(abc@xxx.xxx.xxx.xxx:pppp)}, where 'x' is the IP dotted-quad and 'p' is the SIP port (50640 in this case). That works. Sort of. Now, the phone will ring when the GV account number is called, along with any POTS device plugged into phone port 1 of the Obi, but while the hard phone has the expected two-way audio after call setup, the IP phone has only one way audio; namely, the other party can hear me talking, but I cannot hear them. Call setup proceeds flawlessly, but the RTP data doesn't seem to be reaching the IP phone.

I have tried it with and without symmetric RTP enabled at either or both ends (Obi/IP phone). No dice. The phone in question is a Grandstream GXV3140. Outbound proxy on the phone is set to 192.168.10.1:5062, which is SP2 on the Obi. SIP server on the phone is set to the same.

Any suggestions?

[Undercat]

To answer my own question: RTP port range needs to be locked on the Obi to whatever the IP phone is configured to accept. In my case, the phone has a single RTP inbound port and the Obi was trying to use its default "range" of RTP ports. No dice.

Locked the ITSP profile's RTP port range to a single port on the Obi (namely, the one used by the phone) and audio now flows both ways, as expected. Apparently, the Obi as a proxy does not respect RTP port requests from IP phones.

[hwittenb]

To answer my own question: RTP port range needs to be locked on the Obi to whatever the IP phone is configured to accept. In my case, the phone has a single RTP inbound port and the Obi was trying to use its default "range" of RTP ports. No dice.

Locked the ITSP profile's RTP port range to a single port on the Obi (namely, the one used by the phone) and audio now flows both ways, as expected. Apparently, the Obi as a proxy does not respect RTP port requests from IP phones.

It's good that you solved your problem.

The rtp port range setup in the ITSP is for the the rtp packets coming to the OBi.  The distant client may have completely different ports.  In the sip signaling when a call is started each side of the call tells the other the ip address and port number to use for the rtp packet streams.  When you only allow one rtp port in the OBi you reduce the number of simultaneous channels available for calls.

My testing of local network direct ip calling with the OBi (what you are doing with the ip phone) produced spotty results.  Some configurations worked others had audio problems similiar to what you reported.  In some cases the rtp packet stream was sent to the external ip address.  In some cases it looked like the rtp packets were not constructed properly.  Other cases were OK.  In my opinion the problems were OBi firmware related to direct ip address calling to the internal (local) network.

[Undercat]

The rtp port range setup in the ITSP is for the the rtp packets coming to the OBi.  The distant client may have completely different ports.

That's the way it's supposed to be; it's not the way it actually works, however. In fact, the reason it took so long for me to solve the problem was precisely because it should not have worked.

The original behavior was that outbound RTP packets were routing just fine---the other side could hear me---but inbound packets were never reaching the phone. The phone was originally configured to directly connect to a 3rd-party DID terminator punched through a firewall, so the RTP port on the phone was locked down to a specific value. This worked just fine because the 3rd-party switch respected the RTP request by the phone. The Obi does not. It always sends RTP to a port in its locally-declared range; thus, limiting that range to a single port (namely, the value of the port configured on the phone) allows the RTP data to reach the phone.

I want to emphasize that this is the only change made. With the RTP port range on the Obi set to its default value, no voice data reaches the (locked down) port on the phone; with the RTP port range on the Obi restricted to the single value used by the phone, RTP data reaches the phone.