<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    You can make a simple config, relaying to local host port 9 and in
    failure route send a t_reply() with your code.<br>
    <br>
    Btw, I just added to dialog module a new parameter that allows
    disabling usage of dialog module to store the values for From/To
    headers. As you exposed, it might be a chance that not-tracked
    dialogs with changes to From/To will not be handled properly - I
    will write another message to be reviewed.<br>
    <br>
    Anyhow, is good to have an option not to use dialog module. I used
    it many times in memory-only mode, a restart can cause troubles for
    sure.<br>
    <br>
    To be easy to backport without a risk for conflicts, I split the
    changes in two commits, one for source code and the other for docs.
    If you want to try, just cherry-pick this commit in 3.3:<br>
    <br>
<a class="moz-txt-link-freetext" href="http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0d299fea8a642887305797203536e1340cdf74f9">http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0d299fea8a642887305797203536e1340cdf74f9</a><br>
    <br>
    Once the issue is sorted out, I will backport the patch if it proves
    to fix some wrong behavior.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/2/12 10:05 PM, Alex Balashov
      wrote:<br>
    </div>
    <blockquote
      cite="mid:vacumt495jomcvbfs9kug8xm.1349208316317@email.android.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div>I will check. The problem is that this installation is exotic
        and deviant from my usual order of operations, which creates
        further confusion. </div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>
        <div style="font-size:75%;color:#575757">-- Alex<br>
          <br>
          --<br>
          Sent from my Samsung mobile, and thus lacking in the
          refinement one might expect from a proper keyboard. <br>
          <br>
          Alex Balashov - Principal<br>
          Evariste Systems LLC<br>
          235 E Ponce de Leon Ave<br>
          Suite 106<br>
          Decatur, GA 30030<br>
          Tel: +1-678-954-0670<br>
          Web: <a class="moz-txt-link-freetext" href="http://www.evaristesys.com/">http://www.evaristesys.com/</a></div>
      </div>
      <br>
      Daniel-Constantin Mierla <a class="moz-txt-link-rfc2396E" href="mailto:miconda@gmail.com">&lt;miconda@gmail.com&gt;</a> wrote:<br>
      <br>
      <div class="moz-cite-prefix">On 10/2/12 9:45 PM, Alex Balashov
        wrote:<br>
      </div>
      <blockquote
        cite="mid:0t8g0l35bbk721e1ifh4wvog.1349207098393@email.android.com"
        type="cite">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        <div>Perhaps the source of my misunderstanding is something to
          do with branching. </div>
        <div><br>
        </div>
        <div>The actual case I am troubleshooting is a 503 generated via
          t_reply out of a failure route. The complaint is that this 503
          contains a modified From header, exposed to the originator of
          the call. <br>
        </div>
      </blockquote>
      If you created the transaction after calling msg_apply_changes(),
      then I am quite sure it is how it worked all the time. Try with an
      older version and see.<br>
      <br>
      Cheers,<br>
      Daniel<br>
      <br>
      <blockquote
        cite="mid:0t8g0l35bbk721e1ifh4wvog.1349207098393@email.android.com"
        type="cite">
        <div><br>
        </div>
        <div><br>
        </div>
        <div>
          <div style="font-size:75%;color:#575757">-- Alex<br>
            <br>
            --<br>
            Sent from my Samsung mobile, and thus lacking in the
            refinement one might expect from a proper keyboard. <br>
            <br>
            Alex Balashov - Principal<br>
            Evariste Systems LLC<br>
            235 E Ponce de Leon Ave<br>
            Suite 106<br>
            Decatur, GA 30030<br>
            Tel: +1-678-954-0670<br>
            Web: <a moz-do-not-send="true"
              class="moz-txt-link-freetext"
              href="http://www.evaristesys.com/">http://www.evaristesys.com/</a></div>
        </div>
        <br>
        Daniel-Constantin Mierla <a moz-do-not-send="true"
          class="moz-txt-link-rfc2396E" href="mailto:miconda@gmail.com">&lt;miconda@gmail.com&gt;</a>
        wrote:<br>
        Those originated locally were never using the original value if
        you called msg apply changes -- you can try with an older
        version, if it does that, then it is a bug somewhere :-).<br>
        <br>
        Btw, if you called msg apply changes after creating the
        transaction, then SL is out of scope and tm local reply is using
        the initial values, but that means the changes are only for that
        branch, a failure route will get the initial request content.<br>
        <br>
        Cheers,<br>
        Daniel<br>
        <br>
        <br>
        <br>
        <div class="moz-cite-prefix">On 10/2/12 9:30 PM, Alex Balashov
          wrote:<br>
        </div>
        <blockquote
          cite="mid:5rixy6ebp8d2dbbye6lw7b5q.1349206206128@email.android.com"
          type="cite">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          <div>The expected behaviour is that all replies, both relayed
            and endogenously originated (via SL or TM), as well as
            sequential requests directed back to the caller, will
            preserve the original headers. </div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>
            <div style="font-size:75%;color:#575757">-- Alex<br>
              <br>
              --<br>
              Sent from my Samsung mobile, and thus lacking in the
              refinement one might expect from a proper keyboard. <br>
              <br>
              Alex Balashov - Principal<br>
              Evariste Systems LLC<br>
              235 E Ponce de Leon Ave<br>
              Suite 106<br>
              Decatur, GA 30030<br>
              Tel: +1-678-954-0670<br>
              Web: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://www.evaristesys.com/">http://www.evaristesys.com/</a></div>
          </div>
          <br>
          Daniel-Constantin Mierla <a moz-do-not-send="true"
            class="moz-txt-link-rfc2396E"
            href="mailto:miconda@gmail.com">&lt;miconda@gmail.com&gt;</a>
          wrote:<br>
          Not sure what is 'work as you expect', provided the details I
          gave in the previous mail related to local replies.<br>
          <br>
          Otherwise, if you don't track all dialogs, could be an issue
          if some of the replies are ok and some are not.<br>
          <br>
          I will check the uac module and add a parameter to not use
          dialog module even if loaded, if such option is not already
          there.<br>
          <br>
          Cheers,<br>
          Daniel<br>
          <br>
          <div class="moz-cite-prefix">On 10/2/12 9:11 PM, Alex Balashov
            wrote:<br>
          </div>
          <blockquote
            cite="mid:ndpm4vkpjwddsjlmv9gtfff8.1349205047484@email.android.com"
            type="cite">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8">
            <div>So, you're saying that if all the dialogs were tracked,
              everything would work as I expect it to? </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>
              <div style="font-size:75%;color:#575757">-- Alex<br>
                <br>
                --<br>
                Sent from my Samsung mobile, and thus lacking in the
                refinement one might expect from a proper keyboard. <br>
                <br>
                Alex Balashov - Principal<br>
                Evariste Systems LLC<br>
                235 E Ponce de Leon Ave<br>
                Suite 106<br>
                Decatur, GA 30030<br>
                Tel: +1-678-954-0670<br>
                Web: <a moz-do-not-send="true"
                  class="moz-txt-link-freetext"
                  href="http://www.evaristesys.com/">http://www.evaristesys.com/</a></div>
            </div>
            <br>
            Daniel-Constantin Mierla <a moz-do-not-send="true"
              class="moz-txt-link-rfc2396E"
              href="mailto:miconda@gmail.com">&lt;miconda@gmail.com&gt;</a>
            wrote:<br>
            I think there was an addition to use dialog module to store
            initial and new values. I don't know if it can be turned off
            or is automatically when the dialog module is loaded - just
            to see if that is the cause.<br>
            <br>
            However, if you do msg_apply_changes(), local replies will
            use the new headers. I'm pretty sure it happened the same
            before -- e.g., it was no way to revert back so that sl can
            use older values of the headers. Perhaps you can revert from
            config, changing the header to initial value that you store
            in an avp, apply changes and send the reply.<br>
            <br>
            Received and relayed replies should be converted.<br>
            <br>
            Cheers,<br>
            Daniel<br>
            <br>
            <div class="moz-cite-prefix">On 10/2/12 8:57 PM, Alex
              Balashov wrote:<br>
            </div>
            <blockquote
              cite="mid:8ckqu28pcg053s9jgu9tjpfj.1349204175091@email.android.com"
              type="cite">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8">
              <div>I should be clearer: when I say "internally
                generated", I don't mean it in the sense of 408 or
                something else opaquely generated by the proxy. I mean
                internally generated as in originating from the proxy,
                e.g. something sent with sl_send_reply() or t_reply(). </div>
              <div><br>
              </div>
              <div><br>
              </div>
              <div>
                <div style="font-size:75%;color:#575757">-- Alex<br>
                  <br>
                  --<br>
                  Sent from my Samsung mobile, and thus lacking in the
                  refinement one might expect from a proper keyboard. <br>
                  <br>
                  Alex Balashov - Principal<br>
                  Evariste Systems LLC<br>
                  235 E Ponce de Leon Ave<br>
                  Suite 106<br>
                  Decatur, GA 30030<br>
                  Tel: +1-678-954-0670<br>
                  Web: <a moz-do-not-send="true"
                    class="moz-txt-link-freetext"
                    href="http://www.evaristesys.com/">http://www.evaristesys.com/</a></div>
              </div>
              <br>
              Alex Balashov <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:abalashov@evaristesys.com">&lt;abalashov@evaristesys.com&gt;</a>
              wrote:<br>
              Hello,<br>
              <br>
              I am using the latest cloned 3.3 branch and performing a <br>
              uac_replace_from() operation.  After the operation, I do <br>
              msg_apply_changes().<br>
              <br>
              My 'uac' modparams are:<br>
              <br>
              modparam("uac", "rr_from_store_param", "vsfc")<br>
              modparam("uac", "restore_mode", "auto")<br>
              modparam("uac", "restore_passwd", "xxxxxxxxx")<br>
              <br>
              However, the modified From URI is getting back to the
              originator, both <br>
              in internally generated errors, and in relayed replies.<br>
              <br>
              This didn't used to happen before 3.3, but has been
              outstanding for <br>
              quite some time (I didn't look at it much until now).  Is
              there some <br>
              possibility that there is a &gt;= 3.3 bug?  Or, have I
              simply misconfigured <br>
              something?<br>
              <br>
              Thanks!<br>
              <br>
              -- Alex<br>
              <br>
              -- <br>
              Alex Balashov - Principal<br>
              Evariste Systems LLC<br>
              235 E Ponce de Leon Ave<br>
              Suite 106<br>
              Decatur, GA 30030<br>
              Tel: +1-678-954-0670<br>
              Fax: +1-404-961-1892<br>
              Web: <a moz-do-not-send="true"
                class="moz-txt-link-freetext"
                href="http://www.evaristesys.com/">http://www.evaristesys.com/</a>,
              <a moz-do-not-send="true" class="moz-txt-link-freetext"
                href="http://www.alexbalashov.com/">http://www.alexbalashov.com/</a><br>
              <br>
              _______________________________________________<br>
              SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
              mailing list<br>
              <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
                href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
              <a moz-do-not-send="true" class="moz-txt-link-freetext"
                href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
              <br>
              <fieldset class="mimeAttachmentHeader"></fieldset>
              <br>
              <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
            </blockquote>
            <br>
            <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
          </blockquote>
          <br>
          <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
        </blockquote>
        <br>
        <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/#%21/miconda">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
  </body>
</html>