Regarding UAC I meant not internal handling at the Freeswitch
I mean when one call leg of the FS (presume B leg for outgouing) palys role of the UAC:
Generates INVITE to the Provider directly for example

In this case provider answers with Record-Route header as 1.1.1.1:5060
and Contact header as 1.1.1.1:5061 

So FS in this case ignores single route header and sends request to the Provider Contact....

That was confused me...

2018-07-01 10:52 GMT+03:00 Alex Balashov <abalashov@evaristesys.com>:
By "request route", I assume you mean Record-Route?

All of these rules are for proxy behaviour. A B2BUA like Freeswitch can
do whatever it wants with the other, logically independent call leg.

See RFC 3261 § 16 for more details.

On Sun, Jul 01, 2018 at 10:50:45AM +0300, Yuriy Gorlichenko wrote:

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

> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users