On Friday 14 February 2014 16:31:20 Rob Moore wrote:
Anyway, I've had a look at the change you've suggested, unfortunately it seems to have made little difference and the RTP proxy is still trying to send traffic to the client SIPPhones private ip address and not the firewall.
It's probably worth clarifying (seen as the diagram got mangled) that I don't have an RTPproxy at our client site only in our data centre paid with our kamailio.
Well, we have the same setup:
U 109.235.34.226:42259 -> 109.235.32.42:5060 INVITE sip:0880100705@pisco.pocos.nl SIP/2.0. Via: SIP/2.0/UDP 10.0.3.175:5062;branch=z9hG4bK-54389de. From: "tryba" sip:tryba@pisco.pocos.nl;tag=ea2052858ec448f9o2. To: sip:0880100705@pisco.pocos.nl. Call-ID: 20654a75-2dca31c9@10.0.3.175. CSeq: 101 INVITE. Max-Forwards: 70. Contact: "tryba" sip:tryba@10.0.3.175:5062. Expires: 240. User-Agent: Linksys/SPA962-6.1.3(a). Content-Length: 205. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: replaces. Content-Type: application/sdp. . v=0. o=- 872251 872251 IN IP4 10.0.3.175. s=-. c=IN IP4 10.0.3.175. t=0 0. m=audio 16404 RTP/AVP 2 101. a=rtpmap:2 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv.
...
U 109.235.32.42:5060 -> 109.235.34.226:42259 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.0.3.175:5062;rport=42259;received=109.235.34.226;branch=z9hG4bK-54389de. Record-Route: sip:109.235.32.42;lr=on;ftag=ea2052858ec448f9o2;vsf=AAAAAF9BSFZRc0RZQ1NfHjAfChwQQUAcb2Nvcy5ubA--;nat=yes;vsf=Q2lwOnRyeWJhQHBpc2NvLnBvY29zLm5s;nat=yes. From: "tryba" sip:tryba@pisco.pocos.nl;tag=ea2052858ec448f9o2. To: sip:0880100705@pisco.pocos.nl;tag=as15267783. Call-ID: 20654a75-2dca31c9@10.0.3.175. CSeq: 101 INVITE. Server: Pocos. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Contact: sip:+31880100705@109.235.32.xx. Content-Type: application/sdp. Content-Length: 211. . v=0. o=root 87313901 87313901 IN IP4 109.235.32.42. s=Asterisk PBX 1.6.2.9-2+squeeze11. c=IN IP4 109.235.32.42. t=0 0. m=audio 45940 RTP/AVP 2. a=rtpmap:2 G726-32/8000. a=ptime:20. a=sendrecv. a=nortpproxy:yes.
The natted client will start the RTP stream towards 109.235.32.42:45940 and after about 5-10 packets kamailio/rtpproxy will start sending to the source of the incoming steam.
Attached a flow from an other test call.
As far as I know the only change I made was moving the rtpproxy_manage() a bit.
Maybe I'll have some time monday to generate a small proof of concept config, if nobody gives the answer before that time.
