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
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 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
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
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@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
Yep. Record-Route. Sorry for typo.
Thx for the explanation.
On Sun, Jul 1, 2018, 10:56 Alex Balashov abalashov@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@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
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
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 abalashov@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 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
On Sun, Jul 01, 2018 at 11:27:36AM +0300, Yuriy Gorlichenko wrote:
So FS in this case ignores single route header and sends request to the Provider Contact....
If so, that's wrong.
I suppose it's possible that it matches the next hop based on IP address alone and not port, but that's radioactively incorrect.
Hm... Nice guess I will try to check it Thank you so much for clarify these things Alex!
2018-07-01 11:35 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Sun, Jul 01, 2018 at 11:27:36AM +0300, Yuriy Gorlichenko wrote:
So FS in this case ignores single route header and sends request to the Provider Contact....
If so, that's wrong.
I suppose it's possible that it matches the next hop based on IP address alone and not port, but that's radioactively incorrect.
-- 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
Just in continue of the discussion forund in the RFC3261 12.1.2 (UAC behaivor) this:
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
2018-07-01 11:48 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Hm... Nice guess I will try to check it Thank you so much for clarify these things Alex!
2018-07-01 11:35 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Sun, Jul 01, 2018 at 11:27:36AM +0300, Yuriy Gorlichenko wrote:
So FS in this case ignores single route header and sends request to the Provider Contact....
If so, that's wrong.
I suppose it's possible that it matches the next hop based on IP address alone and not port, but that's radioactively incorrect.
-- 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
On Mon, Jul 02, 2018 at 12:03:24AM +0300, Yuriy Gorlichenko wrote:
Just in continue of the discussion forund in the RFC3261 12.1.2 (UAC behaivor) this:
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
Indeed. What is your intended thesis?
Actually no one... I just confused
So looks like here is an exception from rules for the Route header handling in case of UAC behaivor... It was posted only for to be sure that I have right interpretation of this particular case:
Because of me these 2 descriptions are very opposite
This route
set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
2018-07-02 0:05 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 12:03:24AM +0300, Yuriy Gorlichenko wrote:
Just in continue of the discussion forund in the RFC3261 12.1.2 (UAC behaivor) this:
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
Indeed. What is your intended thesis?
-- 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
The "remote target" in this case refers to the request URI, cosmetically.
On Mon, Jul 02, 2018 at 12:10:26AM +0300, Yuriy Gorlichenko wrote:
Actually no one... I just confused
So looks like here is an exception from rules for the Route header handling in case of UAC behaivor... It was posted only for to be sure that I have right interpretation of this particular case:
Because of me these 2 descriptions are very opposite
This route
set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
2018-07-02 0:05 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 12:03:24AM +0300, Yuriy Gorlichenko wrote:
Just in continue of the discussion forund in the RFC3261 12.1.2 (UAC behaivor) this:
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
Indeed. What is your intended thesis?
-- 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
yep I understand that. I just see that in fact ACK soudl ignore Route header if it... Single?
2018-07-02 1:45 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
The "remote target" in this case refers to the request URI, cosmetically.
On Mon, Jul 02, 2018 at 12:10:26AM +0300, Yuriy Gorlichenko wrote:
Actually no one... I just confused
So looks like here is an exception from rules for the Route header
handling
in case of UAC behaivor... It was posted only for to be sure that I have right interpretation of
this
particular case:
Because of me these 2 descriptions are very opposite
This route
set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
2018-07-02 0:05 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 12:03:24AM +0300, Yuriy Gorlichenko wrote:
Just in continue of the discussion forund in the RFC3261 12.1.2 (UAC behaivor) this:
The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and
preserving
all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This
route
set, even if empty, overrides any pre-existing route set for
future
requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response.
Indeed. What is your intended thesis?
-- 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
On Mon, Jul 02, 2018 at 09:00:02AM +0300, Yuriy Gorlichenko wrote:
yep I understand that. I just see that in fact ACK soudl ignore Route header if it... Single?
What? No.
There are two kinds of ACKs: hop-by-hop ACKs, which acknowledge negative final replies on every branch, and end-to-end ACKs, which are handled according to the rules for in-dialog requests. An ACK for a 2xx reply to an INVITE is going to be an in-dialog request, and under no circumstances should any Route headers be ignored unless they refer to the very proxy through which they are traversing. In that case, they should be stripped off before continuing with the next-hop Route. This is the standard loose-routing procedure labouriously articulated in the RFC, and implemented by loose_route().
Sorry for noize from my side I just cant fully understand dependency:
I understand that actually route header shoud not be ingnored because it is shows way for the in-dialog packet That is fine.
Just regarding behaivor of the FreeSwitch and other UACs
For now I have a next picture
When my provider sends me 200 - it contains as Record-Route: 1.1.1.1:5060 which contains last interface i sent INVITE to Also it contains Contact: 1.1.1.1:5061
So when UAC receives this call without my proxy between provider and UAC it sends ACK to Contact URI (Ignoring Route header that actually also exists in the Contact field) sent at the 200 according rfc3261 -12.1.2 (that I shared above)
But when it sends via my proxy:
UAC receives ACK with 2 Route headers (that is right) and sends it to the topmost Route (myProxy) then my proxy as normal proxy resends it to the provider using second Route (that topmost for now after myProxy removes itself from Route set)
But here provider says me - you should use Contact field to reach target even from myProxy.
So in this case - At the behaivor of UAC -> Provider it looks matched 12.1.2 but I still cant understand why in this case it ignores Route header at the ACK that actually exists
2018-07-02 9:02 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:00:02AM +0300, Yuriy Gorlichenko wrote:
yep I understand that. I just see that in fact ACK soudl ignore Route header if it... Single?
What? No.
There are two kinds of ACKs: hop-by-hop ACKs, which acknowledge negative final replies on every branch, and end-to-end ACKs, which are handled according to the rules for in-dialog requests. An ACK for a 2xx reply to an INVITE is going to be an in-dialog request, and under no circumstances should any Route headers be ignored unless they refer to the very proxy through which they are traversing. In that case, they should be stripped off before continuing with the next-hop Route. This is the standard loose-routing procedure labouriously articulated in the RFC, and implemented by loose_route().
-- 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
* which contains last interface i sent INVITE to - means that uri in the Route hasinterface and it just same with interface I sent invite to. I understand hat it is not a dependency. * (Ignoring Route header that actually also exists in the Contact field) - means aslo existsi in the resquest. Not in the contact field offcource
2018-07-02 9:31 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Sorry for noize from my side I just cant fully understand dependency:
I understand that actually route header shoud not be ingnored because it is shows way for the in-dialog packet That is fine.
Just regarding behaivor of the FreeSwitch and other UACs
For now I have a next picture
When my provider sends me 200 - it contains as Record-Route: 1.1.1.1:5060 which contains last interface i sent INVITE to Also it contains Contact: 1.1.1.1:5061
So when UAC receives this call without my proxy between provider and UAC it sends ACK to Contact URI (Ignoring Route header that actually also exists in the Contact field) sent at the 200 according rfc3261 -12.1.2 (that I shared above)
But when it sends via my proxy:
UAC receives ACK with 2 Route headers (that is right) and sends it to the topmost Route (myProxy) then my proxy as normal proxy resends it to the provider using second Route (that topmost for now after myProxy removes itself from Route set)
But here provider says me - you should use Contact field to reach target even from myProxy.
So in this case - At the behaivor of UAC -> Provider it looks matched 12.1.2 but I still cant understand why in this case it ignores Route header at the ACK that actually exists
2018-07-02 9:02 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:00:02AM +0300, Yuriy Gorlichenko wrote:
yep I understand that. I just see that in fact ACK soudl ignore Route header if it... Single?
What? No.
There are two kinds of ACKs: hop-by-hop ACKs, which acknowledge negative final replies on every branch, and end-to-end ACKs, which are handled according to the rules for in-dialog requests. An ACK for a 2xx reply to an INVITE is going to be an in-dialog request, and under no circumstances should any Route headers be ignored unless they refer to the very proxy through which they are traversing. In that case, they should be stripped off before continuing with the next-hop Route. This is the standard loose-routing procedure labouriously articulated in the RFC, and implemented by loose_route().
-- 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
On Mon, Jul 02, 2018 at 09:31:02AM +0300, Yuriy Gorlichenko wrote:
But here provider says me - you should use Contact field to reach target even from myProxy.
Not if they added another Record-Route hop of theirs.
That was my point also... But they sent me lint to rfc3261 12.1.2 and that confused me
So just for resume:
So am I right if I say that in case If provider receives INVITE with Record-Route from my side (myProxy) Provider should care about it's own Record-Route and it should have uri where myProxy should sent ACK to instead of using Contact in thi case
In case direct conntect UAC -> Provider I still need to use Contact field as URI to send ACK to that explained on the 12.1.2 of rfc3261?
2018-07-02 9:46 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:31:02AM +0300, Yuriy Gorlichenko wrote:
But here provider says me - you should use Contact field to reach target even from myProxy.
Not if they added another Record-Route hop of theirs.
-- 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
On Mon, Jul 02, 2018 at 09:59:12AM +0300, Yuriy Gorlichenko wrote:
That was my point also... But they sent me lint to rfc3261 12.1.2 and that confused me
So just for resume:
So am I right if I say that in case If provider receives INVITE with Record-Route from my side (myProxy) Provider should care about it's own Record-Route and it should have uri where myProxy should sent ACK to instead of using Contact in thi case
In case direct conntect UAC -> Provider I still need to use Contact field as URI to send ACK to that explained on the 12.1.2 of rfc3261?
If the provider sent you a Record-Route of their own in addition to any that you have placed there, your UAC must still follow it when contacting them for in-dialog requests.
Yep this clear for me from the start.
For me for now not clear question abot direct connect for now.
2018-07-02 10:00 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:59:12AM +0300, Yuriy Gorlichenko wrote:
That was my point also... But they sent me lint to rfc3261 12.1.2 and that confused me
So just for resume:
So am I right if I say that in case If provider receives INVITE with Record-Route from my side (myProxy) Provider should care about it's own Record-Route and it should have uri where myProxy should sent ACK to instead of using Contact in thi case
In case direct conntect UAC -> Provider I still need to use Contact field as URI to send ACK to that explained on the 12.1.2 of rfc3261?
If the provider sent you a Record-Route of their own in addition to any that you have placed there, your UAC must still follow it when contacting them for in-dialog requests.
-- 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
Anyway thank you so much for your responses I really appreciate your time and your help here
2018-07-02 10:42 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Yep this clear for me from the start.
For me for now not clear question abot direct connect for now.
2018-07-02 10:00 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:59:12AM +0300, Yuriy Gorlichenko wrote:
That was my point also... But they sent me lint to rfc3261 12.1.2 and that confused me
So just for resume:
So am I right if I say that in case If provider receives INVITE with Record-Route from my side (myProxy) Provider should care about it's own Record-Route and it should have uri where myProxy should sent ACK to instead of using Contact in thi case
In case direct conntect UAC -> Provider I still need to use Contact
field
as URI to send ACK to that explained on the 12.1.2 of rfc3261?
If the provider sent you a Record-Route of their own in addition to any that you have placed there, your UAC must still follow it when contacting them for in-dialog requests.
-- 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
Jut in update In kamailio case all goes well Kamailio sets to UAC Record-Route in the 200 reply and then UAC sends ACK via Route sent...
I totally confised... In both examples from my provider 200 contains Route set but in case of kamailio UAC uses route and in case of provider it uses Contact...
both Route heanders contains "lr"
Provider based Route header jsut contains only *sip:ip:port;lr *when my testing kamaili regitrar contains *sip:ip:port;lr,ftag=fromtaghere*
2018-07-02 10:45 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Anyway thank you so much for your responses I really appreciate your time and your help here
2018-07-02 10:42 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Yep this clear for me from the start.
For me for now not clear question abot direct connect for now.
2018-07-02 10:00 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:59:12AM +0300, Yuriy Gorlichenko wrote:
That was my point also... But they sent me lint to rfc3261 12.1.2 and that confused me
So just for resume:
So am I right if I say that in case If provider receives INVITE with Record-Route from my side (myProxy) Provider should care about it's own Record-Route and it should have uri where myProxy should sent ACK to instead of using Contact in thi case
In case direct conntect UAC -> Provider I still need to use Contact
field
as URI to send ACK to that explained on the 12.1.2 of rfc3261?
If the provider sent you a Record-Route of their own in addition to any that you have placed there, your UAC must still follow it when contacting them for in-dialog requests.
-- 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
Thx Alex Finally I clarified question for myself UAC not ignores Route in case of direct connection to provider It sends to needed ip:port on the transport:network layers
So provider wrong in case that avaits ACK at the different port than Route.
THx all .For now all clear.
2018-07-02 11:24 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Jut in update In kamailio case all goes well Kamailio sets to UAC Record-Route in the 200 reply and then UAC sends ACK via Route sent...
I totally confised... In both examples from my provider 200 contains Route set but in case of kamailio UAC uses route and in case of provider it uses Contact...
both Route heanders contains "lr"
Provider based Route header jsut contains only *sip:ip:port;lr *when my testing kamaili regitrar contains *sip:ip:port;lr,ftag=fromtaghere*
2018-07-02 10:45 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Anyway thank you so much for your responses I really appreciate your time and your help here
2018-07-02 10:42 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:
Yep this clear for me from the start.
For me for now not clear question abot direct connect for now.
2018-07-02 10:00 GMT+03:00 Alex Balashov abalashov@evaristesys.com:
On Mon, Jul 02, 2018 at 09:59:12AM +0300, Yuriy Gorlichenko wrote:
That was my point also... But they sent me lint to rfc3261 12.1.2 and that confused me
So just for resume:
So am I right if I say that in case If provider receives INVITE with Record-Route from my side (myProxy) Provider should care about it's own Record-Route and it should have
uri
where myProxy should sent ACK to instead of using Contact in thi case
In case direct conntect UAC -> Provider I still need to use Contact
field
as URI to send ACK to that explained on the 12.1.2 of rfc3261?
If the provider sent you a Record-Route of their own in addition to any that you have placed there, your UAC must still follow it when contacting them for in-dialog requests.
-- 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
-
Alex Balashov -
Yuriy Gorlichenko