Jason, That is very strange behavior. If there is no matching transaction I think there is no way to catch the message as reply and failure routes are triggered by tm module. I'm not sure since I haven't setup a stateless config.
I'm curious too if there is something that can be done here. Dave On Mon, Feb 21, 2011 at 7:08 PM, Tyler Merritt <[email protected]> wrote: > You know what I do? > I add append_hf("GW: BLAH") and change BLAH for each step in the if blocks. > Then you can grab a tcpdump and see your custom header. This has helped me > ENORMOUSLY during testing to track packet flow. > I prefer looking at the packets themselves and the custom headers rather > than searching through the logs. > It's a bit time consuming to add all the append_hf lines in nearly every if > () block, but man, after a while I started "seeing" the code :) > > > On Tue, Feb 22, 2011 at 11:54 AM, Jason Yeh <[email protected]> wrote: >> >> Tyler, >> Yes, I have already thought the same thing. However that 403 SIP Message >> didn't land there in the main routing block, yet through pcap traces I could >> see the SIP Message being routed to the end-user client. I had this basic >> log of every new messages routed to the main route, for example: >> ============ >> route { >> >> # Simple Log >> >> xlog("L_INFO", "#### M=$rm RURI=$ru F=$fu USR=$tU T=$tu IP=$si ID=$ci\n"); >> >> .... >> ============ >> I don't see 403 message landed there. >> I tried to add logic of something like this on main route: >> ============ >> >> # Detect if SIP/2.0 403 Message >> if ( status == "403" ) { >> >> xlog("got SIP 403"); >> >> } >> >> ============ >> >> Unfortunately, realized that the "status" reference of current message >> would only work for the onreply route.... I'm sure there is reason for it, >> most likely developers might can answer that. >> -Jason >> >> On Mon, Feb 21, 2011 at 9:10 PM, Tyler Merritt <[email protected]> wrote: >>> >>> I would do this by matching the method of the packet in the main routing >>> block, and then using textops to search for the 403 in a subsequent if () {} >>> block, and then just drop; or exit; >>> My methods are usually not the most elegant solution - I'll wait for Dave >>> or one of the Devs to chime in with a better method :) >>> >>> On Tue, Feb 22, 2011 at 10:09 AM, Jason Yeh <[email protected]> wrote: >>>> >>>> Hello everyone, >>>> This certain SIP UAS keeps on sending "SIP/2.0 403" messages to my >>>> OpenSIPS machine out of blue, this failure/warning messages has nothing to >>>> do with this certain client on the call. I wanted to figure out how to drop >>>> ("not proxy") that annoying non-transactional 4XX SIP Messages being routed >>>> through this proxy server, however I couldn't figure out where to get this >>>> message landed to my routing script. Because the fact that this requests >>>> wasn't initially sent by proxy, it will not land to the "failure_route" >>>> routing block. >>>> In summary, how can I configure OpenSIPS routing logic to handle the >>>> non-transactional 4XX request sent by someone else out of blue? >>>> Thanks, >>>> Jason >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >> >> >> >> -- >> Regards, >> >> Jason Yeh >> Co-Founder & CEO >> Streamoso, LLC. >> >> This e-mail, including any attachments may contain information that is >> protected by law as PRIVILEGED AND CONFIDENTIAL and is intended solely for >> the use of the recipient or the employee or agent responsible for delivering >> the message to the recipient. Please note that if you are not the intended >> recipient, you are hereby notified that any dissemination, copying, >> distribution, retention, re-transmission, printing or any other use of this >> e-mail or the information contained herein is strictly prohibited. If you >> have received this e-mail communication in error, please immediately send an >> e-mail reply to notify the sender and immediately and permanently delete >> this e-mail from your computer system. Thank you. > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
