<div>Ah ok. So the device is following RFC 3261 then, sending proper callid and incremental CSeq with the request. Thinking out loud, its as though the command from kamailio to the DB is being duplicated for some reason but only one AOR is being kept in cache.</div>
<div><br></div><div> I don't know what the next step to troubleshoot would be. Jon or Andreas will be better suited to assist further.</div><div><br></div><div>Skyler</div><div><br></div><br><div class="gmail_quote">On Sun, Nov 18, 2012 at 9:35 PM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The cseq is indeed incrementing each 60 seconds, but all the duplicate entries in the database do too.</div>
<div><br></div><div>I should have sent an SQL following another 60 seconds, to demonstrate it but I didnt think of it :(</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Dave</div></font></span><div><div class="h5">
<br><div><div>On 2012-11-19, at 12:26 AM, Skyler <<a href="mailto:skchopperguy@gmail.com" target="_blank">skchopperguy@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div>Hi Dave,</div><div><br></div><div> Looking at the sql you sent, I see the callid, last_modified and cseq are identical in all entries for ddufresne and test2. As you stated, the multiple entries in the DB are occurring whether the device reboots or it sits powered on (re-registering every 60 seconds) over time.</div>
<div><br></div><div>Quoting Andreas from earlier in this thread:</div><div><br></div><div>"<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">If you register a contact for the first time, the server takes the</span></div>
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">call-id and cseq and stores the binding. If a UA wants to refresh this</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">binding, it MUST send the same call-id, and it MUST increment the cseq.</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">Failing to increment the cseq leads to an error message from the server,</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">and failing to use the same call-id leads to an additional entry in the</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">location table."</span><div><font color="#222222" face="arial, sans-serif"><br></font><div> So, the device is indeed not following RFC 3261 - <span style="white-space:pre-wrap">12.2.1 UAC Behavior; it is clearly ignoring the requirement where "</span><span style="white-space:pre-wrap">the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field."</span></div>
<div><br></div><div> IMO, Kamailio is handling the CSeq error on the server-side by maintaining 1 entry in cache to avoid this UA's problem to avoid call failures, however, the location entry deletion is not occurring in the DB...(maybe on purpose?) so you/we can find problem UA's like this.</div>
<div><br></div><div>Skyler</div><div><div><br></div><div><br><div class="gmail_quote">On Sun, Nov 18, 2012 at 8:46 PM, Dave Massey <span dir="ltr"><<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was looking at RFC 3261 for call-id requiring to remain the same across reboots, and I cant find anything stating it is :(<br>
Im just looking for ammunition to give the developers.<br>
<br>
Ive confirmed that it doesn't with this UA, but at this point, all they are going to say, is "so?"<br>
<div><div><br>
<br>
<br>
On 2012-11-15, at 9:28 AM, Jon Bonilla (Manwe) <<a href="mailto:jbonilla@sipwise.com" target="_blank">jbonilla@sipwise.com</a>> wrote:<br>
<br>
> El Thu, 15 Nov 2012 09:21:40 -0500<br>
> Dave Massey <<a href="mailto:dave@optionsdsl.ca" target="_blank">dave@optionsdsl.ca</a>> escribió:<br>
><br>
>> This is probably exactly whats happening. :(<br>
>><br>
><br>
><br>
> If you can confirm this issue, probably you could ask the device developers to<br>
> update the firmware to fix it.<br>
><br>
><br>
> _______________________________________________<br>
> Spce-user mailing list<br>
> <a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a><br>
> <a href="http://lists.sipwise.com/listinfo/spce-user" target="_blank">http://lists.sipwise.com/listinfo/spce-user</a><br>
<br>
<br>
_______________________________________________<br>
Spce-user mailing list<br>
<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a><br>
<a href="http://lists.sipwise.com/listinfo/spce-user" target="_blank">http://lists.sipwise.com/listinfo/spce-user</a><br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div></blockquote></div><br>