<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<div class="moz-cite-prefix">On 6/24/13 2:39 PM, Halina Nowak wrote:<br>
</div>
<blockquote cite="mid:51C83DED.3030504@mbdsys.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hello,<br>
<br>
These modifications as well as those for EARLY dialog were
implemented in the solution using PRACK and 2 UPDATEs (one in
each direction ) before 200OK.<br>
<br>
The cseq numbering was incorrect when server itself decided to
cut the communication and sent 2 BYEs.<br>
The cseqs in UPDATEs where 2 and 22 and in BYEs they were 1 and
21 instead of 3 and 23, so BYEs were rejected by clients.<br>
</div>
</blockquote>
ok, updating the cseq should happen for prack and update requests.
But I couldn't get the relation between the patches and fixing this
problem.<br>
<br>
Another thing was switching to state confirmed from early, not going
through confirmed_na (which is confirmend with no ack). This might
be due to the fact that your patch is rather old and maybe at that
time was no confirmed_na state.<br>
<br>
<blockquote cite="mid:51C83DED.3030504@mbdsys.com" type="cite">
<div class="moz-cite-prefix"> <br>
Always in this solution I detected memory leak on cseq, not on
tag. Maybe this memory leak was because of using UPDATEs - I'm
not sure.<br>
</div>
</blockquote>
<br>
Looked a little odd that in a function that allocated two chunks of
shared memory only one is being take care of. Because if that
function is executed many times, protection against a leak should be
in both cases.<br>
<blockquote cite="mid:51C83DED.3030504@mbdsys.com" type="cite">
<div class="moz-cite-prefix"> I've implemented these modifications
3 years ago and I've "found" them porting our solution to
kamailio4.<br>
</div>
</blockquote>
What is the version you had the patches for? just to check the
development of the module and see what changes were done in general.<br>
<br>
Thanks,<br>
Daniel<br>
<br>
<blockquote cite="mid:51C83DED.3030504@mbdsys.com" type="cite">
<div class="moz-cite-prefix"> <br>
Cheers<br>
<br>
Halina Nowak<br>
<br>
<br>
On 06/21/2013 07:32 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote cite="mid:51C48E1D.7010304@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hello,<br>
<br>
some comments inline.<br>
<br>
<div class="moz-cite-prefix">On 6/14/13 2:03 PM, Halina Nowak
wrote:<br>
</div>
<blockquote cite="mid:51BB067E.3060208@mbdsys.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<font size="-1">Proposal for cseq:<br>
<br>
cseq numbering:<br>
<br>
--- a/modules/dialog/dlg_handlers.c Wed Apr 03 13:33:38
2013 +0200<br>
+++ b/modules/dialog/dlg_handlers.c Fri Jun 14 13:39:47
2013 +0200<br>
@@ -220,7 +220,7 @@<br>
cseq = (get_cseq(msg))->number;<br>
} else {<br>
/* use the same as in request */<br>
- cseq = dlg->cseq[DLG_CALLER_LEG];<br>
+ cseq = dlg->cseq[DLG_CALLEE_LEG];<br>
</font></blockquote>
<br>
<font size="-1">at quick check, the comment says the cseq is
taken from the request because it is processing the reply in
this part of the code.<br>
<br>
You change that to take the value of the stored cseq for
callee, which is different than the current processed message.<br>
<br>
What was the problem you discovered? Can you give an example
to understand this change?<br>
<br>
</font>
<blockquote cite="mid:51BB067E.3060208@mbdsys.com" type="cite"><font
size="-1"> }<br>
<br>
<br>
avoid memory leak:<br>
<br>
--- a/modules/dialog/dlg_hash.c Fri Jun 14 13:40:12 2013
+0200<br>
+++ b/modules/dialog/dlg_hash.c Fri Jun 14 13:45:21 2013
+0200<br>
@@ -485,7 +485,14 @@<br>
char *p;<br>
<br>
dlg->tag[leg].s = (char*)shm_malloc( tag->len +
rr->len + contact->len );<br>
- dlg->cseq[leg].s = (char*)shm_malloc( cseq->len
);<br>
+ if(dlg->cseq[leg].s){<br>
+ if (dlg->cseq[leg].len < cseq->len) {<br>
+ shm_free(dlg->cseq[leg].s);<br>
+ dlg->cseq[leg].s =
(char*)shm_malloc(cseq->len);<br>
+ }<br>
+ }else{<br>
+ dlg->cseq[leg].s = (char*)shm_malloc( cseq->len
);<br>
+ }<br>
if ( dlg->tag[leg].s==NULL ||
dlg->cseq[leg].s==NULL) {<br>
LM_ERR("no more shm mem\n");<br>
if (dlg->tag[leg].s)<br>
</font></blockquote>
I see tag is also allocated each time, isn't it exposed to same
issue? You changed only cseq to reuse existing buffer or free
the old one and allocate a bigger one when needed.<br>
<br>
Cheers,<br>
Daniel<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>
</pre>
</blockquote>
<br>
</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>
</pre>
</body>
</html>