<div dir="ltr">Hi all,<div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/2 Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
30 apr 2013 kl. 20:16 skrev Juha Heinanen <<a href="mailto:jh@tutpro.com">jh@tutpro.com</a>>:<br>
<div class="im"><br>
> Peter Dunkley writes:<br>
><br>
>> If you look at the recent (yesterday and today) discussion on DISPATCH<br>
>> the conclusion appears to be that this is how it should work and that<br>
>> RFC 5626 should have been clearer on the behaviour.<br>
><br>
> i read the discussion and don't understand why would route set change.<br>
> if ua looses connection to its proxy, it sets up a new one, but the<br>
> proxy (which is in the route set established by r-r headers) is still<br>
> the same.<br>
<br>
</div>If you are using edge proxys separate from the registrar, the new<br>
registration may come through another edge proxy, so the<br>
gruu will resolve in a new path to the client, which replaces<br>
the existing route through the possibly dead edge proxy.<br></blockquote><div><br></div><div style>Such new path to the client will be used instead of the old and invalid one as far as I understand f<span style="font-family:arial,sans-serif;font-size:13px">rom RFC 5626, chapter 7:</span></div>
<div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">```</div><div style="font-family:arial,sans-serif;font-size:13px"><pre style="white-space:pre-wrap;font-size:1em;margin-bottom:0px;margin-top:0px">
The proxy uses the next-hop target of the message and the value of
   any stored Path header field vector in the registration binding to
   decide how to forward and populate the Route header in the request.
   If the proxy is co-located with the registrar and stored information
   about the flow to the UA that created the binding, then the proxy
   MUST send the request over the same 'logical flow' saved with the
   binding, since that flow is known to deliver data to the specific
   target UA instance's network flow that was saved with the binding.
</pre><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">``` </div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Which means that a newly created registration binding (following the procedures defined in chapter 4.4) will contain the PATH route with the new and valid flow token, and such 'logical flow' MUST be used instead of that in the Route. Hence, the Route header(s) pointing to the old and deprecated 'logical flow' is replaced with the new one gathered from the registration after the flow failure.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
/O<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>José Luis Millán
</div></div>