by the way, I'm trying this using openser 1.3.0-pre1-notls from latest svn of trunk as of 12-4-07 I'm trying to do findme logic.. Call comes in, lookup settings for where it is supposed to go. phone, a cell phone, and the home ata associated with account. To keep voicemail handled by the home account and not by one of the places that they are forwarding to they want voicemail to be triggered after 15 seconds. The friends home phone is actually one of our accounts and has two ata's associated with it that register as the same sip user and they have it also ring a cell phone and the account sends the call to voicemail after 18 seconds. Psudo Call flow/Logic of what I have so far. Call comes in to openser for 555/123-4567 pull from usr_preferences settings for the call destination number. so I get a stack of avps $avp(s:brahch_uri) from usr_preferences like this: sip:5551239876@127.0.0.1 sip:localuser3@127.0.0.1 sip:5553216548@127.0.0.1 I do diversion header then branch for them with: avp_pushto("$br", "$avp(s:branch_uri)" I drop the local branch. The branched calls come in as expected and verify that it is a valid intentional loopback by testing: if ( ruri =~ "127.0.0.1" && dst_ip == 127.0.0.1 ) { < mark as valid loopback > } Like the beginning of the original call I lookup where they should go and if the user in the diversion header is allowed to send them there (PSTN) In this case one call would be sent out through the PSTN gateways with full failover logic, another would call the device associated with the account by doing a lookup("location") and the third, (the one to the friend that our customer) would add another diversion header and start another parallel fork with loopback for the cell phone and two ata's When I test with a simple forward to a single PSTN number, in the loopbacked session, I rewrite the ruri accordingly with real dest user and real ip address. the ruri shows what I want in the logs just before t_relay and exit and in branch_route[1] after last log entry from branch_route, I have in the log: ERROR:core:udp_send: sendto(sock,0xb619d954,1376,0,0xb619ba6c,16): Invalid argument(22) CRITICAL:core:udp_send: invalid sendtoparameters one possible reason is the server is bound to localhost and attempts to send to the net ERROR:tm:msg_send: udp_send failed ERROR:tm:t_forward_nonack: sending request failed Then I have log entrys from onreply_route[1]: Reply - S=100 M=INVITE RURI=<null> src_ip = 127.0.0.1 Reply - S=477 M=INVITE RURI=<null> src_ip = 127.0.0.1 not the real world IP address of the other server I set in the ruri and there is nothing in the logs on the intended server or the local server indicating routing logic for an invite failed I'm woundering if the TM module, while processing the invite in the loopback, is matching up the transaction with the session that originated the loopback and using the settings and status from it. Any Ideas, Thoughts, HELP!!? Or is OpenSER just not ready for this yet? Thanks Dave