<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Kennard,<br>
<br>
I agree, the best solution is to generate a unique to tag in the
presence module - it is easy to do in tm module ( the b2b_entities
module already does this, it uses t_reply_with_body function), but in
sl there is no support to inject the to tag. I will speak with Bogdan
to see what solution we can find for this.<br>
<br>
On 09/28/2010 09:47 PM, <a class="moz-txt-link-abbreviated" href="mailto:Kennard_White@logitech.com">Kennard_White@logitech.com</a> wrote:
<blockquote
cite="mid:OF0917D43E.ECDB68DE-ON882577AC.0063F366-882577AC.00673FD8@logitech.com"
type="cite">
<p>Hi Anca,<br>
<br>
There are some "big" issues that I don't think I can solve. I'll try to
describe:<br>
<br>
1. Need to decide if indexing is based upon totag (if globally unique)
or the 5-tuple of from_uri,from_tag,to_uri,to_tag,callid. Whichever is
decided, should be used informally for hash & db, for all ops
(insert, search and delete). Current code has mixture. My own "vote" is
to make totag unique (within the sever), much the way PUBLISH's etag is
unique. Then a subscription can be identified by a single key (the
totag).<br>
<br>
2. The unique totag needs to be generated *before* sending the
response. E.g., all the hash&db operations need to complete
successfully before sending reply message. With current code where the
totag is generated as side-effect of sending 2XX, the client thinks it
has a good subscription when in fact it has failed due to DB issue.<br>
<br>
3. Consequence of above, my suggestion is generate totag within
presence module, complete DB ops, then send 2XX. Need new API so that
the totag can be passed into tm layer, instead of tm layer generating.
This is bigger change than I want to do (and even if I did, don't know
if patch would be accepted).<br>
<br>
4. The totag generated by tm has a very long prefix that is GUID for
the opensips instance, and there is comment in code about this being
used to detect spirals. Is this used? If not, perhaps consider dropping
this prefix portion and making the dialog-specific portion longer (and
unique).<br>
<br>
5. I don't understand why the totag is generated the way it is. The
method used makes sense for the sl module: the to tag (because hash of
prior hop state) will be the same for replies generated for
retransmits. But why do this in tm module? The whole "point" of tm is
that it keeps state to handle retransmits. And the whole "point" of the
totag is to provide a convenient handle to look up dialog state.
Clearly, I'm missing something here.<br>
<br>
6. I only use the "presence_xml" module. The other presence modules
(e.g., pua) use the low-level APIs of the presence module. I'm just not
familiar with how these other modules work, and cannot assess impact of
changes to core presence module.<br>
</p>
</blockquote>
There is no other module to generate a to tag - only presence module
does this.<br>
<blockquote
cite="mid:OF0917D43E.ECDB68DE-ON882577AC.0063F366-882577AC.00673FD8@logitech.com"
type="cite">
<p><br>
7. The startup order is messy. Currently the db-restore is done from
mod_init(). This has two problems: (a) the other modules may or may not
have been initialized, which leads to non-determinism in how the
get_auth_status() is handled, and (b) the statistics variables are not
ready. Suggest moving db-restore into the "first" child_init, assuming
stats are ready then. But really need a thread-join for all the
child-inits prior to handling traffic. E.g., need to block all PUB/SUB
traffic until restore is complete. (Ideally generating 5XX with
retry-after header). Don't really know how to implement this
join/blocking.<br>
<br>
</p>
</blockquote>
Indeed, get_auth_status might not be available in mod_init if the
modules that add events are not loaded before. We can move the reload
from db in the first child as you suggested.<br>
<br>
I will let you know when I finish the unique to tag implementation.<br>
<br>
Thanks and regards,<br>
<pre class="moz-signature" cols="72">--
Anca Vamanu
<a class="moz-txt-link-abbreviated" href="http://www.voice-system.ro">www.voice-system.ro</a></pre>
<br>
<blockquote
cite="mid:OF0917D43E.ECDB68DE-ON882577AC.0063F366-882577AC.00673FD8@logitech.com"
type="cite">
<p>As a consequence of all the above, I don't think I can ever give
you a final patch, or even any much better than what you have now. I
just didn't want you to think my patch was good or ready for
production. Need to resolve above big issues. If you decide to go with
a global totag, then some of my changes will need to be backed out.
I'll happily deal with any version control conflicts if it gets us
closer to final solution.<br>
<br>
Kennard<br>
<br>
<img src="cid:part1.08000600.08040707@opensips.org"
alt="Inactive hide details for "SourceForge.net" ---09/28/2010 02:30:29 AM---Patches item #3076805, was opened at 2010-09-28 00:00 M"
height="16" width="16" border="0"><font color="#424282">"SourceForge.net"
---09/28/2010 02:30:29 AM---Patches item #3076805, was opened at
2010-09-28 00:00 Message generated for change (Comment added) m</font><br>
<br>
<font size="2" color="#5f5f5f">From: </font><font size="2">"SourceForge.net"
<a class="moz-txt-link-rfc2396E" href="mailto:noreply@sourceforge.net"><noreply@sourceforge.net></a></font><br>
<font size="2" color="#5f5f5f">To: </font><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:noreply@sourceforge.net">noreply@sourceforge.net</a></font><br>
<font size="2" color="#5f5f5f">Date: </font><font size="2">09/28/2010
02:30 AM</font><br>
<font size="2" color="#5f5f5f">Subject: </font><font size="2">[OpenSIPS-Devel]
[ opensips-Patches-3076805 ] presence non-unique totag and more</font><br>
<font size="2" color="#5f5f5f">Sent by: </font><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:devel-bounces@lists.opensips.org">devel-bounces@lists.opensips.org</a></font><br>
</p>
<hr style="color: rgb(128, 145, 165);" noshade="noshade" size="2"
width="100%" align="left"><br>
<br>
<br>
<tt>Patches item #3076805, was opened at 2010-09-28 00:00<br>
Message generated for change (Comment added) made by anca_vamanu<br>
You can respond by visiting: <br>
</tt><tt><a moz-do-not-send="true"
href="https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3076805&group_id=232389">https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3076805&group_id=232389</a></tt><tt><br>
<br>
Please note that this message will contain a full copy of the comment
thread,<br>
including the initial issue submission, for this request,<br>
not just the latest update.<br>
Category: modules<br>
Group: trunk<br>
Status: Open<br>
Resolution: None<br>
Priority: 5<br>
Private: No<br>
Submitted By: Kennard White (kennardwhite)<br>
>Assigned to: Anca Vamanu (anca_vamanu)<br>
Summary: presence non-unique totag and more<br>
<br>
Initial Comment:<br>
Attached is a bundle of changes to presence module. We deployed
opensips1.6 and saw a number of different failures under production
load. This patch isn't finished quality: it is just snapshot of where I
stand now. I thought it worth sharing the issues I've seen so far. A
clean solutions really require larger change outside the scope of just
the presence module. I'll send email to the list about these ideas.<br>
<br>
This includes:<br>
* Partial bug fix for non-unique totags. The hash-table and DB code for
deleting subscriptions assumes that the totag is unique. But the totag
has only 16 bits of possible uniqueness per server (it is CRC of branch
info). IN practice, easy to get totag collisions after few thousand
subscribers. Patch includes fix to the hash-table side but the DB side
is still broken. For now, code just does nothing to DB when deleteting
a subscription, and just lets it expire out.<br>
* Bug fix for expiring subscriptions from DB prior to updating.
Subscriptions that we renewd (via reSUB) are deleted from DB prior to
writing the new (unexpired) time into the DB. Change to do DB delete
after sync.<br>
* Bug fix for "if ( foo & NO_UPDATE_DB) when NO_UPDATE_DB is zero
value. Note that at least one other module has same bug and is not
patched here.<br>
* Addition of statistics for presence module. The isn't cleanest of
implementations because the DB restore function runs before statistics
are available. Would be much cleaner if DB restore could run after
stats are available.<br>
* Addition of new 'activeSubs' mi command to help trace down these
problems.<br>
* More info in many of the log messages to help trace down these errors.<br>
* Addition of 'override_481_code' as work-around for bad resiprocate
clients. We use this option to force a 5xx code instead of standard 481
since some versions of resip get stuck with 481.<br>
* Change to NOTIFY code to node register a response callback function
if subscription is being terminated. No point is looking for 481
response if sub is terminated.<br>
* Fix for expires_offset as discussed previously to prevent
subscriptions walking to zero length.<br>
<br>
----------------------------------------------------------------------<br>
<br>
>Comment By: Anca Vamanu (anca_vamanu)<br>
Date: 2010-09-28 12:30<br>
<br>
Message:<br>
Hi Kennard,<br>
<br>
Thank you for this complex patch - some issues are really bugs that we<br>
were not aware of and the additions seem useful. I will review this
patch<br>
and send comments if I have any. I will not apply it until you say it's
the<br>
final version.<br>
<br>
Regards,<br>
Anca<br>
<br>
----------------------------------------------------------------------<br>
<br>
You can respond by visiting: <br>
</tt><tt><a moz-do-not-send="true"
href="https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3076805&group_id=232389">https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3076805&group_id=232389</a></tt><tt><br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Devel@lists.opensips.org">Devel@lists.opensips.org</a><br>
</tt><tt><a moz-do-not-send="true"
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a></tt><tt><br>
</tt><br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Devel@lists.opensips.org">Devel@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a>
</pre>
</blockquote>
</body>
</html>