
<html>

  <head>

    <meta content="text/html; charset=ISO-8859-1"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-cite-prefix">El 01/08/14 01:24, Daniel-Constantin

      Mierla escribió:<br>

    </div>

    <blockquote cite="mid:53DB328C.5050003@gmail.com" type="cite">

      <meta content="text/html; charset=ISO-8859-1"

        http-equiv="Content-Type">

      The uac from/to replacement relies that parties keep the same

      from/to headers content.<br>

      <br>

      The mechanism to replace A with B is to combine both and get the

      key X which is added in the record-route as parameter. Then

      practically from A and X results B and from B and X results A.<br>

      <br>

      Now in this case, the notify comes with something different than

      was in SUBSCRIBE, therefore the result is messed up.<br>

      <br>

      Perhaps a check over the result to see if it is at least a good

      value would be useful, but doesn't solve this issue.<br>

      <br>

      If both sides in this dialog rely on RFC3261 dialog matching

      (call-id, from tag and to tag), then practically after the initial

      SUBSCRIBE (where is no To tag), then you can replace From/To

      display name and uri with anything (e.g., anonymous).<br>

      <br>

      An improvement could be to know in advance that one side is not

      keeping From/To, then practically storing (encrypted/encode) the

      intial value only. This requires C coding.<br>

    </blockquote>

    <br>

    I had to patch kamailio to work around the issue. What I did is to

    calculate a small (8-bit) XOR checksum of the old uri, and prepend

    this byte on the old uri in order to calculate the rr parameter. On

    restoring, the value should match, and if it does not, the relevant

    header is left unchanged.<br>

    <br>

    Is this strategy worthy of submitting for merge, or is it too hacky?<br>

  </body>

</html>