Will catch dump for now one more time to clarify this situation about directly sent ACK from UAC with ignotring Route
2018-07-01 10:54 GMT+03:00 Alex Balashov <abalas...@evaristesys.com>: > 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 <abalas...@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 >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users