A sort of related question: If the INVITE is always record-routed with
lr=on, is it a guarantee that all in-dialog requests
(BYE,ACK,reINVITE,INFO, etx) will be loose routed? <br>
<span class="sg"><br></span>Mark<br><br><div><span class="gmail_quote">On 9/29/05, <b class="gmail_sendername">Klaus Darilion</b> <<a href="mailto:klaus.mailinglists@pernau.at">klaus.mailinglists@pernau.at</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br><a href="mailto:jim.pafford@comcast.net">jim.pafford@comcast.net</a> wrote:<br>
> In ser 0.9.3 I am seeing the following problem with a parallel forking<br>> scenario. The SER is sending the final Request ACK to the wrong location<br>> every time. Is there a way to fix this. See below:<br>>
<br>> Endpoint (<a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a> <mailto:<a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a>>) sends<br>> Invite(<a href="mailto:abc123@proxy.com">abc123@proxy.com</a> <mailto:<a href="mailto:abc123@proxy.com">
abc123@proxy.com</a>>) to the SER.<br>> SER looks up location and then sends the following three messages:<br>> TRYING back to (<a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a> <mailto:<a href="mailto:xyz@1.1.1.1">
xyz@1.1.1.1</a>>)<br>> INVITE to <a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a> <mailto:<a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a>><br>> INVITE to <a href="mailto:abc123@3.3.3.3">abc123@3.3.3.3</a>
<mailto:<a href="mailto:abc123@3.3.3.3">abc123@3.3.3.3</a>><br>><br>> This looks good so far.<br>> SER then gets back ringing from both endpoints and sends along to<br>> <a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1
</a> <mailto:<a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a>><br>><br>> <a href="mailto:abc123@3.3.3.3">abc123@3.3.3.3</a> <mailto:<a href="mailto:abc123@3.3.3.3">abc123@3.3.3.3</a>> answers the call and sends back OK
<br>> SER then sends OK to <a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a> <mailto:<a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a>> - Still good<br>> SER then sends CANCEL to <a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2
</a> <mailto:<a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a>><br>> <a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a> <mailto:<a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a>> responds with 200 Canceling - so
<br>> far so good.<br>><br>> Now <a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a> <mailto:<a href="mailto:xyz@1.1.1.1">xyz@1.1.1.1</a>> sends the ACK to (<a href="mailto:abc123@proxy.com">abc123@proxy.com</a><br>
> <mailto:<a href="mailto:abc123@proxy.com">abc123@proxy.com</a>>) - Still looks good.<br>><br>> But now after looking up location for abc123 SER sends the ACK to the<br><br>Do you use lookup(location) for ACK? This is not necessary. It should be
<br>handled in loose_route section.<br><br>klaus<br><br><br>> wrong endpoint <a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a> <mailto:<a href="mailto:abc123@2.2.2.2">abc123@2.2.2.2</a>><br>><br>> What am I doing wrong? SER always sends the ACK back to the first
<br>> address in the list as shown by serctl ul show abc123. Is there a way<br>> to correct this so that SER knows the correct endpoint to relay the ACK<br>> to? Seems like it should understand which endpoint sent back the OK to
<br>> the original INVITE and then send the ACK to that endpoint and not the<br>> first one in the list after a location lookup.<br>><br>> thanks,<br>> Jim<br>><br>><br>> ------------------------------------------------------------------------
<br>><br>> _______________________________________________<br>> Serusers mailing list<br>> <a href="mailto:serusers@lists.iptel.org">Serusers@iptel.org</a><br>> <a href="http://lists.iptel.org/mailman/listinfo/serusers">
http://lists.iptel.org/mailman/listinfo/serusers</a><br><br>_______________________________________________<br>Serusers mailing list<br><a href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a><br><a href="http://mail.iptel.org/mailman/listinfo/serusers">
http://lists.iptel.org/mailman/listinfo/serusers</a><br></blockquote></div><br>