Presence stuff uses tm callbacks to send messages and does not follow the config file (that&#39;s what Vaclav was saying) and it&#39;s therefore impossible to use this approach for presence.<br>Moreover, I would definetely prefer integrating Path and Service-Route in the SER core and not in the routing script....
<br><br>samuel.<br><br><div><span class="gmail_quote">2007/8/15, Greger V. Teigre &lt;<a href="mailto:greger@teigre.com">greger@teigre.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
You can actually use the select and avps to implement Path header
functionality in ser.cfg by storing path info in db. I have never done
it, but a how-to for <a href="http://iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">iptel.org</a> faqs would be much appreciated ;-)<br><span class="sg">
g-)</span><div><span class="e" id="q_1146940f2d8a0d5e_2"><br>
<br>
Vaclav Kubart wrote:
<blockquote type="cite">
  <pre>On Po, srp 06, 2007 at 11:41:46 +0200, samuel wrote:<br>  </pre>
  <blockquote type="cite">
    <pre>I&#39;ll give a try to this parameter...I didn&#39;t pay enough attention to the<br>serdev mail....<br><br>Maybe a reasonable approach would be to be able to define a presence<br>outbound proxy (as it&#39;s done in presence_b2b) and you can set up &quot;easily&quot; a
<br>separate presence proxy or route the messages to yourself so you can process<br>it again in your config script. This would, however, break just a little bit<br>3261 routing algorithm....easy but I don&#39;t like it...
<br>    </pre>
  </blockquote>
  <pre>Good idea. :-) I like it much more than calling script routes from presence<br>modules. And it is much easier to implement it.<br><br>But similar effect could be probably got by forwarding the SUBSCRIBE<br>request once more to itself if it will be needed to process the NOTIFYs
<br>by nathelper. (Adds a step to routes where can be the &quot;deNATification&quot;<br>done.)<br><br>  </pre>
  <blockquote type="cite">
    <pre>Thinking loud...what about Path or Service-Route headers compatibility in<br>presence modules?? Setting up these headers would allow flexible routing<br>while keeping compliancy to standards...Can this be achieved with
<br>2.0release and select framework??<br>    </pre>
  </blockquote>
  <pre>Sorry, we don&#39;t support these in presence modules...<br><br>        Vaclav<br><br>  </pre>
  <blockquote type="cite">
    <pre>Regards,<br><br>Samuel.<br><br>2007/8/6, Vaclav Kubart <a href="mailto:vaclav.kubart@iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">&lt;vaclav.kubart@iptel.org&gt;</a>:<br>    
</pre>
    <blockquote type="cite">
      <pre>Yes, you are right.<br><br>But Maxim has introduced new module parameter by which you can say, that<br>NOTIFY is not target refresh request and thus NOTIFY responses won&#39;t<br>refresh the target.<br><br>From my point of view is this only temporary hack (because NOTIFY was in
<br>some discussions aggreed to be target refresh). Better solution is<br>probably to let the NOTIFY go through config script and process it and<br>its responses by nathelper.<br><br>        Vaclav<br><br>On Po, srp 06, 2007 at 10:24:17 +0200, samuel wrote:
<br>      </pre>
      <blockquote type="cite">
        <pre>mmmm<br><br>coming back to the discussion....the missing OK Contact mangle happened<br>        </pre>
      </blockquote>
      <pre>with<br>      </pre>
      <blockquote type="cite">
        <pre>a separated prosence proxy...<br><br>I was wondering...In the case of a single SIP server<br>(proxy,registrar,presence,...) when the &quot;presence&quot; part sends the NOTIFY<br>        </pre>
      </blockquote>
      <pre>to<br>      </pre>
      <blockquote type="cite">
        <pre>a natted UA and this latter one replies with the 200OK, the Contact<br>        </pre>
      </blockquote>
      <pre>would<br>      </pre>
      <blockquote type="cite">
        <pre>contain the internal IP and since this NOTIFY is not handled by the SER<br>route config file , it can not be managed by nathelper|mediaproxy<br>        </pre>
      </blockquote>
      <pre>options.<br>      </pre>
      <blockquote type="cite">
        <pre>This would cause a modification in the target of the dialog to the<br>        </pre>
      </blockquote>
      <pre>internal<br>      </pre>
      <blockquote type="cite">
        <pre>IP (following RFC 3261) and the presence dialog would be useless because<br>        </pre>
      </blockquote>
      <pre>no<br>      </pre>
      <blockquote type="cite">
        <pre>notifications would work....am I right?<br><br>Thanks,<br>Samuel.<br><br>2007/8/3, samuel <a href="mailto:samu60@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">&lt;samu60@gmail.com&gt;
</a>:<br>        </pre>
        <blockquote type="cite">
          <pre>Ok.<br><br>I found out the &quot;problem&quot;, there was a missing NAT handling of the<br>responses, and the 200 OK response updated the target dialog with a<br>non-routable IP. That&#39;s why further messages had the wronf Req-URI.
<br><br>Thanks for your pointers,<br>sam.<br><br>2007/8/2, Vaclav Kubart <a href="mailto:vaclav.kubart@iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">&lt;vaclav.kubart@iptel.org&gt;</a>:
<br>          </pre>
          <blockquote type="cite">
            <pre>Hi Samuel,<br>Maxim Sobolev was fighting with NAT and presence some time ago.<br><br>I was trying to allow calling script route block when sending NOTIFY<br>            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>to<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre>allow its modifications, but I had not enough time to get results.<br><br>The NOTIFY should be constructed according RFC 3261; the request URI<br>should be the value from Contact of the SUBSCRIBE request (if only
<br>            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>loose<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre>routers in routes appear).<br><br>To, From, Via and routes should follow RFC 3261 too.<br><br>Contact header value is the address at which the SUBSCRIBE request<br>arrives to the server (according examples in RFC 3856, this is
<br>controversial but possible).<br><br>Modifying of async_auth_queries should have no influence on sent<br>NOTIFYs. If does, it is probably a bug.<br><br>All headers you mentioned are derived from dialog initiating<br>            
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>SUBSCRIBE<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre>request as RFC says.<br><br>        Vaclav<br><br>On Čt, srp 02, 2007 at 12:05:02 +0200, samuel wrote:<br>            </pre>
            <blockquote type="cite">
              <pre>Hi all!!!<br><br>I&#39;m experiencing quite difficulties setting up a dedicated (and<br>              </pre>
            </blockquote>
            <pre>separated)<br>            </pre>
            <blockquote type="cite">
              <pre>presence server with NATted end-points and the dstblacklist<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>feature.<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre>I&#39;d like to get some info about the construction of the most<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>important<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre>headers (Req-URI,Contact,To,From,Via,Routr) for the different<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>NOTIFY<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre>modalities depending on the state of the subscription.<br><br>Setting up async_auth_queries I&#39;ve seen the pending and the active<br>              </pre>
            </blockquote>
            <pre>NOTIFY<br>            </pre>
            <blockquote type="cite">
              <pre>have different Req-URI and the second one is blocked by the NAT<br>              </pre>
            </blockquote>
            <pre>router.<br>            </pre>
            <blockquote type="cite">
              <pre>Further mid-dialog NOTIFYs providing changes in the presence<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>status<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre>has also<br>            </pre>
            <blockquote type="cite">
              <pre>different headers...<br>My main concern is whether the info for constructing the routing<br>              </pre>
            </blockquote>
            <pre>headers is<br>            </pre>
            <blockquote type="cite">
              <pre>taken from location table, from watcherinfo.dialog table, or from<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>the<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <pre>incoming message...I know I could follow the code but an<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>explanation<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre>would<br>            </pre>
            <blockquote type="cite">
              <pre>provide a really helpfull overview and later checking the code<br>              </pre>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre>will be<br>      </pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre>much<br>            </pre>
            <blockquote type="cite">
              <pre>simpler.<br><br><br>Thanks in advance,<br>Samuel.<br>              </pre>
            </blockquote>
            <blockquote type="cite">
              <pre>_______________________________________________<br>Serusers mailing list<br><a href="mailto:Serusers@lists.iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.iptel.org/mailman/listinfo/serusers</a>
              </pre>
            </blockquote>
            <pre>            </pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <blockquote type="cite">
        <pre>_______________________________________________<br>Serusers mailing list<br><a href="mailto:Serusers@lists.iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.iptel.org/mailman/listinfo/serusers</a>
        </pre>
      </blockquote>
      <pre>      </pre>
    </blockquote>
  </blockquote>
  <pre>  </pre>
  <blockquote type="cite">
    <pre>_______________________________________________<br>Serusers mailing list<br><a href="mailto:Serusers@lists.iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.iptel.org/mailman/listinfo/serusers</a>
    </pre>
  </blockquote>
  <pre>_______________________________________________<br>Serusers mailing list<br><a href="mailto:Serusers@lists.iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@lists.iptel.org
</a>
<a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.iptel.org/mailman/listinfo/serusers</a>


  </pre>
</blockquote>
</span></div></div>

</blockquote></div><br>