[SR-Users] Should I ignore Route header in ACK?

Yuriy Gorlichenko ovoshlook at gmail.com
Sun Jul 1 10:01:19 CEST 2018


Yep. Record-Route. Sorry for typo.

Thx for the explanation.

On Sun, Jul 1, 2018, 10:56 Alex Balashov <abalashov at evaristesys.com> wrote:

> Well, that was a confusing statement. To clarify:
>
> Record-Route imposes obligations on both UAs to send their in-dialog
> requests through an intermediate proxy hop. The callee will do this
> because the intermediate proxy added a Record-Route to the INVITE before
> passing it to the callee, and the caller will do it because the same
> Record-Route is copied into the 2xx response by the callee so that the
> caller knows about it. If any of these things are not happening, that
> could be the reason.
>
> 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 at 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 at 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 at lists.kamailio.org
> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > >
>
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180701/06db39ec/attachment.html>


More information about the sr-users mailing list