Hi Daniel, After updating to latest 3.2 git rev, I can't see to reproduce this so I guess it must have been fixed somewhere. My apologies for the run around.
For completeness the log with the added debugging is here: http://pastebin.com/8TNE0w7q Thanks, Spencer On Sep 10, 2012, at 12:54 PM, Spencer Thomason wrote: > Hello, > Apologies for the delay, I will update tonight and report back. > > Thanks, > Spencer > > > On Sep 7, 2012, at 1:34 AM, Daniel-Constantin Mierla wrote: > >> Hello, >> >> can you apply attached patch to the rtpproxy module and send again the log >> messages from kamailio? No need for siptrace, I just want to see if the to >> tag is detected properly and the number of paramters for rtpproxy command >> from kamailio point of view. >> >> Cheers, >> Daniel >> >> On 9/6/12 8:44 AM, Spencer Thomason wrote: >>> Hi Daniel, >>> >>> I collected logs and a trace exhibiting this behavior. >>> >>> The logs are here: >>> http://pastebin.com/1rQwLmx9 >>> >>> The trace is here: >>> http://pastebin.com/sXVL69tD >>> >>> Thanks, >>> Spencer >>> >>> >>> On Aug 31, 2012, at 1:33 PM, Daniel-Constantin Mierla wrote: >>> >>>> Hello, >>>> >>>> the command to rtpproxy for the reply seem to miss the to-tag, can you >>>> grab the ngrep trace for such call and the logs for processing it? Having >>>> the logs from a different call than the ngrep trace you posted on pastebin >>>> is not helping much. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 8/31/12 6:49 PM, Spencer Thomason wrote: >>>>> Yes, >>>>> >>>>> The request (re-INVITE): >>>>> >>>>> Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]: ERROR: *** cfgtrace: >>>>> c=[/etc/kamailio/kamailio.cfg] l=471 a=25 n=rtpproxy_manage >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:handle_command: received >>>>> command "25778_11 U [email protected] 184.170.249.3 32122 >>>>> 3ae1Dvgr5vmeg;1 199857477;1" >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: INFO:handle_command: adding strong >>>>> flag to existing session, new=1/0/0 >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: INFO:handle_command: lookup on ports >>>>> 55324/46010, session timer restarted >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:doreply: sending reply >>>>> "25778_11 46010 184.170.249.8#012" >>>>> >>>>> >>>>> The reply: >>>>> >>>>> Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]: ERROR: *** cfgtrace: >>>>> c=[/etc/kamailio/kamailio.cfg] l=471 a=25 n=rtpproxy_manage >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:handle_command: received >>>>> command "25778_12 L [email protected] 71.104.248.48 6016 >>>>> 3ae1Dvgr5vmeg;1" >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: INFO:handle_command: lookup request >>>>> failed: session [email protected], tags 3ae1Dvgr5vmeg;1/NONE >>>>> not found >>>>> Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:doreply: sending reply >>>>> "25778_12 0 184.170.249.8#012" >>>>> Aug 30 22:38:59 sip /usr/sbin/kamailio[25778]: ERROR: rtpproxy >>>>> [rtpproxy.c:2260]: incorrect port 0 in reply from rtp proxy >>>>> >>>>> >>>>> I was able to get it working correctly by reworking the config like the >>>>> 3.1 branch by using rtpproxy_offer instead of force_rtp_proxy. When I >>>>> attempted to use rtpproxy_answer in the reply route, I was getting the >>>>> same lookup request failed error from rtpproxy. In the request and >>>>> reply, the tags change. Could this be the reason that the session lookup >>>>> is failing? If I use rtpproxy_offer in both the request and reply, >>>>> everything works correctly. Is there any consequence to doing this? >>>>> >>>>> Thanks, >>>>> >>>>> Spencer >>>>> >>>>> >>>>> >>>>> On 31.08.2012 01:53, Daniel-Constantin Mierla wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> On 8/31/12 3:41 AM, Spencer Thomason wrote: >>>>>>> Hi Daniel, I can confirm that rtpproxy_manage is called. See: >>>>>>> http://pastebin.com/ZVXjK9ry I'm seeing ERROR: rtpproxy >>>>>>> [rtpproxy.c:2260]: incorrect port 0 in reply from rtp proxy in the logs >>>>>>> when processing the 200OK in the re-INVITE. I've included a debug level >>>>>>> log from rtpproxy in the log as well. >>>>>> this can happen because the rtpproxy was not engaged for the request, >>>>>> but only for the reply. >>>>>> >>>>>> As you say, the logs are for the 200OK, what about the ones for request, >>>>>> is rtpproxy called there? >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>>> When handling the re-INVITE there is: • Aug 30 22:38:59 sip >>>>>>> /usr/sbin/kamailio[25778]: ERROR: *** cfgtrace: >>>>>>> c=[/etc/kamailio/kamailio.cfg] l=471 a=25 n=rtpproxy_manage • Aug 30 >>>>>>> 22:38:59 sip rtpproxy[25671]: DBUG:handle_command: received command >>>>>>> "25778_11 U [email protected] 184.170.249.3 32122 >>>>>>> 3ae1Dvgr5vmeg;1 199857477;1" • Aug 30 22:38:59 sip rtpproxy[25671]: >>>>>>> INFO:handle_command: adding strong flag to existing session, new=1/0/0 >>>>>>> • Aug 30 22:38:59 sip rtpproxy[25671]: INFO:handle_command: lookup on >>>>>>> ports 55324/46010, session timer restarted • Aug 30 22:38:59 sip >>>>>>> rtpproxy[25671]: DBUG:doreply: sending reply "25778_11 46010 >>>>>>> 184.170.249.8#012" but the 200OK: • Aug 30 22:38:59 sip >>>>>>> /usr/sbin/kamailio[25778]: ERROR: *** cfgtrace: >>>>>>> c=[/etc/kamailio/kamailio.cfg] l=471 a=25 n=rtpproxy_manage • Aug 30 >>>>>>> 22:38:59 sip rtpproxy[25671]: DBUG:handle_command: received command >>>>>>> "25778_12 L [email protected] 71.104.248.48 6016 >>>>>>> 3ae1Dvgr5vmeg;1" • Aug 30 22:38:59 sip rtpproxy[25671]: >>>>>>> INFO:handle_command: lookup request failed: session >>>>>>> [email protected], tags 3ae1Dvgr5vmeg;1/NONE not found • >>>>>>> Aug 30 22:38:59 sip rtpproxy[25671]: DBUG:doreply: sending reply >>>>>>> "25778_12 0 184.170.249.8#012" • Aug 30 22:38:59 sip >>>>>>> /usr/sbin/kamailio[25778]: ERROR: rtpproxy [rtpproxy.c:2260]: incorrect >>>>>>> port 0 in reply from rtp proxy I'm not familiar with the rtpproxy >>>>>>> commands to know why it cannot locate the session. Thanks for your >>>>>>> assistance, Spencer On Aug 30, 2012, at 11:59 AM, Daniel-Constantin >>>>>>> Mierla wrote: >>>>>>>> >>>>>>>> Hello, I could not spot by quick eye checking what could happen there, >>>>>>>> the best is to use the debugger module with cfg_trace parameter set >>>>>>>> and check the execution trace to see what actions of the configuration >>>>>>>> file are executed and be sure the rtpproxy is called or not. You can >>>>>>>> post the execution trace here if you need further help with it. >>>>>>>> Cheers, Daniel On 8/30/12 7:40 PM, Spencer Thomason wrote: >>>>>>>>> >>>>>>>>> Hi Daniel, Thanks for your help with this. Here is a trace: >>>>>>>>> http://pastebin.com/pXeFbwBz I see the nat=yes parameter added to the >>>>>>>>> Route header. I've posted the script here: >>>>>>>>> http://pastebin.com/2qwHYHvjForgive my ignorance, I can't tell what >>>>>>>>> I'm doing wrong. Thanks! Spencer On Aug 30, 2012, at 12:51 AM, >>>>>>>>> Daniel-Constantin Mierla wrote: >>>>>>>>>> >>>>>>>>>> Hello, if your config it is based on the default one, the Route >>>>>>>>>> header for within dialog requests is marked by a parameter, nat=yes, >>>>>>>>>> that is used to decide whether to do rtpproxy or not. So, if you >>>>>>>>>> have a custom config, check the default one for the nat traversal >>>>>>>>>> handling part. Cheers, Daniel On 8/30/12 12:39 AM, Spencer Thomason >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, I'm using Kamailio 3.2.4 for NAT traversal using >>>>>>>>>>> rtpproxy_manage() in a largely stock script. Everything works great >>>>>>>>>>> until the far end (on a public ip) sends a t.38 re-INVITE. The >>>>>>>>>>> 200OK from the NATed UAC then doesn't trigger rtpproxy and the >>>>>>>>>>> private IP in the sdp causes the fax to fail. Any help handling >>>>>>>>>>> these re-INVITEs would be greatly appreciated. I'm happy to post >>>>>>>>>>> traces if that helps describe the situation. The network topology >>>>>>>>>>> looks like this: NATed UAC -> Kamailio on a public IP -> UAS on a >>>>>>>>>>> public IP Thanks in advance, Spencer Connected by DROID on Verizon >>>>>>>>>>> Wireless _______________________________________________ SIP >>>>>>>>>>> Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>>>>>>> -- Daniel-Constantin Mierla - http://www.asipto.com >>>>>>>>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>>>>>>>> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - >>>>>>>>>> http://asipto.com/u/kat >>>>>>>> -- Daniel-Constantin Mierla - http://www.asipto.com >>>>>>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>>>>>> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - >>>>>>>> http://asipto.com/u/kat >>>>>>> _______________________________________________ SIP Express Router >>>>>>> (SER) and Kamailio (OpenSER) - sr-users mailing list >>>>>>> [email protected] >>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> -- >>>> Daniel-Constantin Mierla - http://www.asipto.com >>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat >>> >> >> -- >> Daniel-Constantin Mierla - http://www.asipto.com >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat >> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - >> http://asipto.com/u/katu >> <rtpproxy-dgb.patch> > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
