<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">>I see no problem from sip point of view -- each party can send re-invites as they have something new to negotiate.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Will try to patch resiprocate :) </span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks for your help !</span></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 4:47 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<br>
<div>On 11/08/14 15:18, Dmytro Bogovych
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">You can
try not sending the 100 trying, so the sender does
retransmissions</span><br>
<div><span style="font-family:arial,sans-serif;font-size:13px">Sender
did not receive 100 answer; anyway it did not retransmit. It
is based on resiprocate.</span></div>
</div>
</blockquote></div>
Ahh, right, for tls the reliability of transmission is given by
transport layer. So no much to try on this option.<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">maybe
the sender should send a new re-invite as it changes to a
new network again.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">Is
it legal in SIP? I ask because such attempt violates
resiprocate's invite session state machine rules;
resiprocate will throw exception.</span></div>
</div>
</blockquote>
<br></div>
I see no problem from sip point of view -- each party can send
re-invites as they have something new to negotiate.<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Aug 11, 2014 at 3:17 PM,
Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> The SIP reply is
routed based on the address in the VIA header. The address
in VIA is set by each node sending a request, if between
the request and the response the sender is no longer
available at the address it added as VIA, then it is
little one can do for that.<br>
<br>
You can try not sending the 100 trying, so the sender does
retransmissions. Also, maybe the sender should send a new
re-invite as it changes to a new network again.<br>
<br>
Cheers,<br>
Daniel
<div>
<div><br>
<br>
<div>On 11/08/14 13:10, Dmytro Bogovych wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">Greetings all.
<div>I have following use case:</div>
<div><br>
</div>
<div>0) Peer A and B registers on kamailio via
TLS.</div>
<div>1) Peer A establishes call to peer B.</div>
<div>2) Peer A changes network and call has to be
refreshed. Peer A reregisters, gathers ICE
candidates, builds reINVITE and sends it to B.
After peer A changes network again, reregisters
and waits for answer from old reINVITE.</div>
<div>3) Peer B receives reINVITE and sends answer.</div>
<div><br>
</div>
<div>The problem is this answer never gets to peer
B. Kamailio cannot route answer as old TLS
connection is closed and new one did not
established before reregistering.</div>
<div><br>
</div>
<div>Is there way to solve or avoid this
situation?</div>
<div><br>
</div>
<div>Thank you :)</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><span><font color="#888888">
</font></span></pre>
<span><font color="#888888"> </font></span></blockquote>
<span><font color="#888888"> <br>
<pre cols="72">--
Daniel-Constantin Mierla
<a href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</font></span></div>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre cols="72">--
Daniel-Constantin Mierla
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Next Kamailio Advanced Trainings 2014 - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA</pre>
</div></div></div>
</blockquote></div><br></div>