I've created another RTPProxy command trace. Again, in the failed example, the RTPProxy fails to match up RTP ports. It's on the SIP Reinvite. Perhaps the Call-id is too long?
I've replicated the scenario by using exactly the same UAC as the callee. For both below, I've replaced the IP's with: SOURCE_PUBLIC_IP SIP_PROXY_IP DEST_PUBLIC_IP In the Failed example: UAC behind NAT --> SIP Proxy --> UAC (Analog Adapter) behind NAT In the Working example: Call via UAC behind NAT --> SIP Proxy --> UAC (Analog Adapter) behind NAT === FAILED === U 2010/07/17 23:49:14.116158 127.0.0.1:54785 -> 127.0.0.1:9000 18806_5 Uc0 fd685b7f-a31c-46d3-9f2a-0e1a5d166...@192.168.0.15 SOURCE_PUBLIC_IP 49200 IPF_PORT_0001_1049;1 # U 2010/07/17 23:49:14.116240 127.0.0.1:9000 -> 127.0.0.1:54785 18806_5 12310 SIP_PROXY_IP # U 2010/07/17 23:49:20.605284 127.0.0.1:44781 -> 127.0.0.1:9000 18807_4 Lc0,100,101 fd685b7f-a31c-46d3-9f2a-0e1a5d166...@192.168.0.15 DEST_PUBLIC_IP 16384 IPF_PORT_0001_1049;1 f8594af262fc4c4di0;1 # U 2010/07/17 23:49:20.605334 127.0.0.1:9000 -> 127.0.0.1:44781 18807_4 13254 SIP_PROXY_IP # U 2010/07/17 23:49:22.984839 127.0.0.1:54131 -> 127.0.0.1:9000 18810_7 U fd685b7f-a31c-46d3-9f2a-0e1a5d166...@192.168.0.15 DEST_PUBLIC_IP 16384 f8594af262fc4c4di0;1 IPF_PORT_0001_1049;1 # U 2010/07/17 23:49:22.984878 127.0.0.1:9000 -> 127.0.0.1:54131 18810_7 13254 SIP_PROXY_IP # U 2010/07/17 23:49:22.987261 127.0.0.1:54785 -> 127.0.0.1:9000 18806_6 L fd685b7f-a31c-46d3-9f2a-0e1a5d166...@192.168.0.15 SOURCE_PUBLIC_IP 49152 f8594af262fc4c4di0;1 IPF_PORT_0001_1049;1 # U 2010/07/17 23:49:22.988894 127.0.0.1:9000 -> 127.0.0.1:54785 18806_6 12310 SIP_PROXY_IP # U 2010/07/17 23:49:59.868120 127.0.0.1:51577 -> 127.0.0.1:9000 18812_6 D fd685b7f-a31c-46d3-9f2a-0e1a5d166...@192.168.0.15 IPF_PORT_0001_1049 f8594af262fc4c4di0 # U 2010/07/17 23:49:59.868196 127.0.0.1:9000 -> 127.0.0.1:51577 18812_6 0 === WORKING === U 2010/07/17 23:46:23.322411 127.0.0.1:51577 -> 127.0.0.1:9000 18812_5 Uc0,96 8482700691772010234...@source_public_ip SOURCE_PUBLIC_IP 14000 1c848271171;1 # U 2010/07/17 23:46:23.322487 127.0.0.1:9000 -> 127.0.0.1:51577 18812_5 11456 SIP_PROXY_IP # U 2010/07/17 23:46:29.817014 127.0.0.1:54785 -> 127.0.0.1:9000 18806_4 Lc0,100,96 8482700691772010234...@source_public_ip DEST_PUBLIC_IP 16482 1c848271171;1 9176acf3859a789i0;1 # U 2010/07/17 23:46:29.817073 127.0.0.1:9000 -> 127.0.0.1:54785 18806_4 12224 SIP_PROXY_IP # U 2010/07/17 23:46:32.206194 127.0.0.1:37508 -> 127.0.0.1:9000 18809_5 U 8482700691772010234...@source_public_ip DEST_PUBLIC_IP 16482 9176acf3859a789i0;1 1c848271171;1 # U 2010/07/17 23:46:32.206237 127.0.0.1:9000 -> 127.0.0.1:37508 18809_5 12224 SIP_PROXY_IP # U 2010/07/17 23:46:32.241299 127.0.0.1:50755 -> 127.0.0.1:9000 18808_5 L 8482700691772010234...@source_public_ip SOURCE_PUBLIC_IP 14002 9176acf3859a789i0;1 1c848271171;1 # U 2010/07/17 23:46:32.246470 127.0.0.1:9000 -> 127.0.0.1:50755 18808_5 11456 SIP_PROXY_IP # U 2010/07/17 23:47:44.737578 127.0.0.1:50755 -> 127.0.0.1:9000 18808_6 D 8482700691772010234...@source_public_ip 1c848271171 9176acf3859a789i0 # U 2010/07/17 23:47:44.737647 127.0.0.1:9000 -> 127.0.0.1:50755 18808_6 0 On Thu, Jul 15, 2010 at 8:53 PM, Klaus Darilion <klaus.mailingli...@pernau.at> wrote: > > > Am 15.07.2010 18:25, schrieb Julian Yap: >> >> I'm not calling RTPProxy with any flags. >> >> Hmm what do those extra arguments mean? >> >> >> On 7/15/10, Klaus Darilion<klaus.mailingli...@pernau.at> wrote: >>> >>> I only see 2 differences: >>> >>> 1. in the nonworking case the callee's request triggers a lookup with >>> more arguments "Lc0,100,101" as in the working case "Lc0". > > I do not know. Maybe some extra information which is present in the SDP? > > regards > Klaus > _______________________________________________ Users mailing list Users@rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/users
