<div dir="auto">Yep. Record-Route. Sorry for typo.<div dir="auto"><br></div><div dir="auto">Thx for the explanation.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 1, 2018, 10:56 Alex Balashov <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, that was a confusing statement. To clarify: <br>
<br>
Record-Route imposes obligations on both UAs to send their in-dialog<br>
requests through an intermediate proxy hop. The callee will do this<br>
because the intermediate proxy added a Record-Route to the INVITE before<br>
passing it to the callee, and the caller will do it because the same<br>
Record-Route is copied into the 2xx response by the callee so that the<br>
caller knows about it. If any of these things are not happening, that<br>
could be the reason.<br>
<br>
On Sun, Jul 01, 2018 at 10:50:45AM +0300, Yuriy Gorlichenko wrote:<br>
<br>
> Alex thank you for the response<br>
> So all that I found is correct and known looks like correct.<br>
> Then last question confusing me - why some UAC's ignoring it.<br>
> Looks like they are just have not full RFC interpretation but as i beleive<br>
> FreeSwitch have good SIP binding with almost full RFC compatable<br>
> <br>
> question is: Any guess why this can happen?<br>
> Because on my side - when kamailio as one more proxy between porvider and<br>
> UAC all works correctly (means kamailio not ignores Route header and it is<br>
> right behaivor).<br>
> Looks like this happens when only 1 Request route arrives at the response<br>
> from UAS...<br>
> <br>
> 2018-07-01 10:28 GMT+03:00 Alex Balashov <<a href="mailto:abalashov@evaristesys.com" target="_blank" rel="noreferrer">abalashov@evaristesys.com</a>>:<br>
> <br>
> > Hi,<br>
> ><br>
> > Record-Route from the UAS in the 2xx response to the initial INVITE<br>
> > transaction should be recast a Route set in in-dialog messages<br>
> > originating from the caller, of which an end-to-end ACK is one.<br>
> ><br>
> > The next Route header should be followed for reaching the next hop on the<br>
> > network and transport level. The request URI should cosmetically be<br>
> > equivalent to the Contact URI of the far end, but the Route header will<br>
> > cause a deviation in where the request is actually sent.<br>
> ><br>
> > This is entirely appropriate and correct. Nobody should be ignoring a<br>
> > Route header.<br>
> ><br>
> > -- Alex<br>
> ><br>
> > On Sun, Jul 01, 2018 at 10:27:00AM +0300, Yuriy Gorlichenko wrote:<br>
> ><br>
> > > Hi<br>
> > > I know that this is not question too much close to the kamialio users but<br>
> > > mostly losed to the RFC specifiacations but this community looks like<br>
> > > pretty much close to it that is why I want to ask this question here,<br>
> > > that's why sorry and thanks for help in this question:<br>
> > ><br>
> > > I have a situation when provider sends me 200 response with Request-Route<br>
> > > header and changed contact header:<br>
> > ><br>
> > > Means response comes from<br>
> > > <a href="http://1.1.1.1:5060" rel="noreferrer noreferrer" target="_blank">1.1.1.1:5060</a><br>
> > > Request-Route contains:<br>
> > > <a href="http://1.1.1.1:5060" rel="noreferrer noreferrer" target="_blank">1.1.1.1:5060</a><br>
> > > But Contact contains:<br>
> > > <a href="http://1.1.1.1:5061" rel="noreferrer noreferrer" target="_blank">1.1.1.1:5061</a><br>
> > ><br>
> > > My ACK (handled by kamailio) goes to the <a href="http://1.1.1.1:5060" rel="noreferrer noreferrer" target="_blank">1.1.1.1:5060</a> as it setted up at<br>
> > > the Route Hedaer of ACK (because of Request-Route)<br>
> > ><br>
> > > but provider says me that i should use Contact for the ACK<br>
> > ><br>
> > ><br>
> > > I was surprised because of<br>
> > > <a href="https://tools.ietf.org/html/rfc3261#section-12.2.1.1" rel="noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc3261#section-12.2.1.1</a><br>
> > > and<br>
> > > <a href="https://tools.ietf.org/html/rfc3261#section-8.1.2" rel="noreferrer noreferrer" target="_blank">https://tools.ietf.org/html/rfc3261#section-8.1.2</a><br>
> > ><br>
> > > Says that I should use Route header for reaching destination<br>
> > > But I was surprised second time when tested this scenario with FreeSwitch<br>
> > > and another softphone (as UA) because of it both sends ACK to the based<br>
> > on<br>
> > > Contact address and ignores Route<br>
> > ><br>
> > > I just wanna ask if I missed some scenario in the RFC when it is<br>
> > described<br>
> > > to ignore Route header for the UA<br>
> > ><br>
> > > (I know that I use kamailio on my case as proxy server but should<br>
> > > understand finally who should make changes with packet handling)<br>
> > ><br>
> > > Thanks one more time for the resonses and sorry one more time for the<br>
> > goal<br>
> > > of this question that belongs to the kamailio just partially<br>
> ><br>
> > > _______________________________________________<br>
> > > Kamailio (SER) - Users Mailing List<br>
> > > <a href="mailto:sr-users@lists.kamailio.org" target="_blank" rel="noreferrer">sr-users@lists.kamailio.org</a><br>
> > > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> ><br>
> ><br>
> > --<br>
> > Alex Balashov | Principal | Evariste Systems LLC<br>
> ><br>
> > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)<br>
> > Web: <a href="http://www.evaristesys.com/" rel="noreferrer noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
> ><br>
> > _______________________________________________<br>
> > Kamailio (SER) - Users Mailing List<br>
> > <a href="mailto:sr-users@lists.kamailio.org" target="_blank" rel="noreferrer">sr-users@lists.kamailio.org</a><br>
> > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> ><br>
<br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" target="_blank" rel="noreferrer">sr-users@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank" rel="noreferrer">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>