When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R URI needs to contain FQDN of Kamailio SIP proxy instead of its IP address. Document
https://skalatan.de/de/blog/kamailio-sbc-teams
suggest to replace record_route(); call with
record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls", "SBC-IP-ADDR:5060");
That works only in a very simple case where the request came in over UDP or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
One way to solve the problem might be a new r_r function that would take FQDN of the top R-R URI as argument or introduction of a pv from where the current record_route() function would take the FQDN if it has been set.
Any comments or other solutions?
-- Juha
On 10.02.21 21:01, Juha Heinanen wrote:
When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R URI needs to contain FQDN of Kamailio SIP proxy instead of its IP address. Document
https://skalatan.de/de/blog/kamailio-sbc-teams
suggest to replace record_route(); call with
record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls", "SBC-IP-ADDR:5060");
That works only in a very simple case where the request came in over UDP or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
One way to solve the problem might be a new r_r function that would take FQDN of the top R-R URI as argument or introduction of a pv from where the current record_route() function would take the FQDN if it has been set.
Any comments or other solutions?
Not sure I understand: do you want to get the value of the second parameter for record_route_preset() based on local sockets where the request was received?
Cheers, Daniel
Daniel,
I don't want to use record_route_preset at all, since its use is very complicated when Kamailio is listening on multiple IP addresses and when request can come over UDP, TCP, or TLS and when R-R URIs can have many parameters depending on if rtpengine is used, etc.
So I simply want to keep on using record_route() as before, but tell it to use a FQDN instead of IP address of the proxy in the first or second R-R header that it is adding.
-- Juha
-------------------------------------------------------------------------
Daniel-Constantin Mierla writes:
On 10.02.21 21:01, Juha Heinanen wrote:
When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R URI needs to contain FQDN of Kamailio SIP proxy instead of its IP address. Document
https://skalatan.de/de/blog/kamailio-sbc-teams
suggest to replace record_route(); call with
record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls", "SBC-IP-ADDR:5060");
That works only in a very simple case where the request came in over UDP or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
One way to solve the problem might be a new r_r function that would take FQDN of the top R-R URI as argument or introduction of a pv from where the current record_route() function would take the FQDN if it has been set.
Any comments or other solutions?
Not sure I understand: do you want to get the value of the second parameter for record_route_preset() based on local sockets where the request was received?
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
I think the parameters are added even if you use the record_route_preset(), isn't it? If you use add_rr_param() and this function, the params are not showing up in headers?
If not, then that has to be added because the purpose of record_route_preset() is to be able to set rr header as one needs based on variables that can be used in parameters. Note that the parameters are only "host:port;transport=", without protocol, for the reason to let the code decide between sip and sips.
Cheers, Daniel
On 11.02.21 09:20, Juha Heinanen wrote:
Daniel,
I don't want to use record_route_preset at all, since its use is very complicated when Kamailio is listening on multiple IP addresses and when request can come over UDP, TCP, or TLS and when R-R URIs can have many parameters depending on if rtpengine is used, etc.
So I simply want to keep on using record_route() as before, but tell it to use a FQDN instead of IP address of the proxy in the first or second R-R header that it is adding.
-- Juha
Daniel-Constantin Mierla writes:
On 10.02.21 21:01, Juha Heinanen wrote:
When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R URI needs to contain FQDN of Kamailio SIP proxy instead of its IP address. Document
https://skalatan.de/de/blog/kamailio-sbc-teams
suggest to replace record_route(); call with
record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls", "SBC-IP-ADDR:5060");
That works only in a very simple case where the request came in over UDP or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
One way to solve the problem might be a new r_r function that would take FQDN of the top R-R URI as argument or introduction of a pv from where the current record_route() function would take the FQDN if it has been set.
Any comments or other solutions?
Not sure I understand: do you want to get the value of the second parameter for record_route_preset() based on local sockets where the request was received?
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
Daniel-Constantin Mierla writes:
I think the parameters are added even if you use the record_route_preset(), isn't it? If you use add_rr_param() and this function, the params are not showing up in headers?
Daniel,
That exactly is the problem. If I call record_route_preset() and after that add_rr_param(), the params are not added.
I just made a test:
record_route_preset("teams.tutpro.com:8007;transport=tls;bc", "127.0.0.1:5070;transport=tcp;bc"); add_rr_param(";r2=on");
and this is what is sent out:
Record-Route: sip:teams.tutpro.com:8007;transport=tls;bc;lr Record-Route: sip:127.0.0.1:5070;transport=tcp;bc;lr
It may be a bug in Kamailio, since the OpenSIPS doc tells to do that:
record_route_preset("LAN_IP:5060", "SBC_FQDN:5061;transport=tls"); add_rr_param(";r2=on");
-- Juha
On 11.02.21 09:52, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I think the parameters are added even if you use the record_route_preset(), isn't it? If you use add_rr_param() and this function, the params are not showing up in headers?
Daniel,
That exactly is the problem. If I call record_route_preset() and after that add_rr_param(), the params are not added.
I just made a test:
record_route_preset("teams.tutpro.com:8007;transport=tls;bc", "127.0.0.1:5070;transport=tcp;bc"); add_rr_param(";r2=on");and this is what is sent out:
Record-Route: sip:teams.tutpro.com:8007;transport=tls;bc;lr Record-Route: sip:127.0.0.1:5070;transport=tcp;bc;lr
The code of add_rr_param() used after the record-route header is added indicates that the values should be added. I didn't have the time to check what is with the cached params if add_rr_param() used beore the record-route header is added. I will try to reproduce.
On your specific case, your probably can just add ";r2=on" in the params of the record_route_preset() function.
Cheers, Daniel
Daniel-Constantin Mierla writes:
The code of add_rr_param() used after the record-route header is added indicates that the values should be added. I didn't have the time to check what is with the cached params if add_rr_param() used beore the record-route header is added. I will try to reproduce.
On your specific case, your probably can just add ";r2=on" in the params of the record_route_preset() function.
Yes, in this case I could just add ";r2=on" to record_route_preset(). But there are many other params that I use in R-R URIs that are not constant. For example, which rtpengine set was used in the call, what kind of media conversion was done, etc.
So it would be good to get the add_rr_param() work also after record_route_preset().
-- Juha
Daniel-Constantin Mierla writes:
If not, then that has to be added because the purpose of record_route_preset() is to be able to set rr header as one needs based on variables that can be used in parameters. Note that the parameters are only "host:port;transport=", without protocol, for the reason to let the code decide between sip and sips.
I didn't quite understand the last sentence. In case of tls transport, also port of the socket usually needs to be different than in case of udp or tcp.
I haven't tested yet, if I only give host, will record_route_preset() add both port and transport automatically based on which socket is used to send the request out.
-- Juha
On 11.02.21 12:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
If not, then that has to be added because the purpose of record_route_preset() is to be able to set rr header as one needs based on variables that can be used in parameters. Note that the parameters are only "host:port;transport=", without protocol, for the reason to let the code decide between sip and sips.
I didn't quite understand the last sentence. In case of tls transport, also port of the socket usually needs to be different than in case of udp or tcp.
The address, port and protocol are taken from listen socket by the usual record_route() function, they are known.
I haven't tested yet, if I only give host, will record_route_preset() add both port and transport automatically based on which socket is used to send the request out.
In the case of record_route_preset(), it is the parameters that have to set them, address, port and transport, it is nothing added related to them.
Cheers, Daniel
Daniel-Constantin Mierla writes:
The address, port and protocol are taken from listen socket by the usual record_route() function, they are known.
Yes, that is what I'm normally using.
I haven't tested yet, if I only give host, will record_route_preset() add both port and transport automatically based on which socket is used to send the request out.
In the case of record_route_preset(), it is the parameters that have to set them, address, port and transport, it is nothing added related to them.
Yes, and that complicates matters. That's why I proposed the possibility to tell to record_route() to use FQDN instead of IP address.
-- Juha
On 11.02.21 14:52, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The address, port and protocol are taken from listen socket by the usual record_route() function, they are known.
Yes, that is what I'm normally using.
I haven't tested yet, if I only give host, will record_route_preset() add both port and transport automatically based on which socket is used to send the request out.
In the case of record_route_preset(), it is the parameters that have to set them, address, port and transport, it is nothing added related to them.
Yes, and that complicates matters. That's why I proposed the possibility to tell to record_route() to use FQDN instead of IP address.
The record_route_preset() is supposed to offer the flexibility of setting the address part in RR headers via variables. I do not see how the record_route() can be better variant, because it will end up in the same kind functionality: for which to use the FQDN? For first of the second Record-Route header, or for both?
These are conditions that are made in configuration file, based on routing needs, when deciding what socket to use and where to send. There are variables that give access to receiving socket ip/port or sending socket.
I used record_route_preset() with variables and additional parameters, adding everything at once, even when using rtpengine/rtpproxy. Including for the MS Teams interconnect proxy instances I built. So I didn't need the add_rr_param() at all, by that not noticing is not working here. The add_rr_param() is useful with record_route() because it is not know what IP/addresses to add in the headers, thus they cannot be added like for record_route_preset(). Note that record_route_preset() can be used in branch_route(), after the rtpengine/rtpproxy is engaged, which might be even required for cases of serial forking.
Anyhow, the record_route_preset() had a condition on additional rr parameters, but it was actually not using the value. I just pushed a commit that should fix it. I did some basic testing, see if works for you.
Cheers, Daniel
Daniel-Constantin Mierla writes:
The record_route_preset() is supposed to offer the flexibility of setting the address part in RR headers via variables. I do not see how the record_route() can be better variant, because it will end up in the same kind functionality: for which to use the FQDN? For first of the second Record-Route header, or for both?
I was thinking this kind of new function:
record_route_with_fqdn(first_header_fqdn, second_header_fqdn)
It would work the same way as record_route, but would use the fqdn param instead of IP address if the param is not "".
So, when INVITE goes to teams, I would make call
record_route_with_fqdn("tenantX.teams.tutpro.com", "");
and then INVITE comes from teams, I would make call
record_route_with_fqdn("", "tenantX.teams.tutpro.com");
These are conditions that are made in configuration file, based on routing needs, when deciding what socket to use and where to send. There are variables that give access to receiving socket ip/port or sending socket.
Yes, I know that the variables exist, but it is messy to use them.
-- Juha
I do not see benefits of the variant you propose, there must be conditions to figure outing tenants, which direction is going to be, how to route it, etc...
But you can add new functions as you consider useful, there is also a function for record route with advertised address.
Cheers, Daniel
On 11.02.21 17:02, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The record_route_preset() is supposed to offer the flexibility of setting the address part in RR headers via variables. I do not see how the record_route() can be better variant, because it will end up in the same kind functionality: for which to use the FQDN? For first of the second Record-Route header, or for both?
I was thinking this kind of new function:
record_route_with_fqdn(first_header_fqdn, second_header_fqdn)
It would work the same way as record_route, but would use the fqdn param instead of IP address if the param is not "".
So, when INVITE goes to teams, I would make call
record_route_with_fqdn("tenantX.teams.tutpro.com", "");
and then INVITE comes from teams, I would make call
record_route_with_fqdn("", "tenantX.teams.tutpro.com");
These are conditions that are made in configuration file, based on routing needs, when deciding what socket to use and where to send. There are variables that give access to receiving socket ip/port or sending socket.
Yes, I know that the variables exist, but it is messy to use them.
-- Juha
On 10 Feb 2021, at 21:01, Juha Heinanen jh@tutpro.com wrote:
When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R URI needs to contain FQDN of Kamailio SIP proxy instead of its IP address. Document
https://skalatan.de/de/blog/kamailio-sbc-teams
suggest to replace record_route(); call with
record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls", "SBC-IP-ADDR:5060");
That works only in a very simple case where the request came in over UDP or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
One way to solve the problem might be a new r_r function that would take FQDN of the top R-R URI as argument or introduction of a pv from where the current record_route() function would take the FQDN if it has been set.
Any comments or other solutions?
This is needed for all TLS rr’s since we need to vallidate the cert with the FQDN.
/O
Maybe need to move into more global changes...
How about DNS hostname usage for all headers? "Via", "Record-Route" maybe "Contact" when Kamailio with extra modules play media?
how about global directive like header_with_hostname=tue
Sergey
On Thu, Feb 11, 2021 at 10:44 AM Olle E. Johansson oej@edvina.net wrote:
On 10 Feb 2021, at 21:01, Juha Heinanen jh@tutpro.com wrote:
When request is sent from Kamailio to MS Teams SIP Proxy, the top R-R URI needs to contain FQDN of Kamailio SIP proxy instead of its IP address. Document
https://skalatan.de/de/blog/kamailio-sbc-teams
suggest to replace record_route(); call with
record_route_preset("SBC-DNS-DOMAIN:5061;transport=tls",
"SBC-IP-ADDR:5060");
That works only in a very simple case where the request came in over UDP or TCP and SIP Proxy has only one listening address, i.e., SBC-IP-ADDR.
One way to solve the problem might be a new r_r function that would take FQDN of the top R-R URI as argument or introduction of a pv from where the current record_route() function would take the FQDN if it has been set.
Any comments or other solutions?
This is needed for all TLS rr’s since we need to vallidate the cert with the FQDN.
/O _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Sergey Safarov writes:
Maybe need to move into more global changes...
How about DNS hostname usage for all headers? "Via", "Record-Route" maybe "Contact" when Kamailio with extra modules play media?
how about global directive like header_with_hostname=tue
I'm not sure if that is a good idea, since, for example, I would like to keep on using IP address 127.0.0.1:
Record-Route: sip:teams.tutpro.com:8007;transport=tls;r2=on;lr;pm=0 Record-Route: sip:127.0.0.1:5070;transport=tcp;r2=on;lr;pm=0
-- Juha
Hi,
I don't understand the trouble: Wouldn't the following lead to the exact example:
listen=tls:1.2.3.4:8007 advertise teams.tutpro.com:8007 listen=tcp:1.2.3.4:5070
As soon as you do: $fs = "tcp:1.2.3.4:5070"; record_route(); (or put the other socket into $fs)
This results into two record-route headers, one with the hostname and one with the IP.
We use the Hostnames in all kinds of Record-Route and Via-Headers by doing exactly this.
Thanks, Carsten
-- Carsten Bock I CTO & Founder
ng-voice GmbH
Trostbrücke 1 I 20457 Hamburg I Germany T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com
Registry Office at Local Court Hamburg, HRB 120189 Managing Directors: Dr. David Bachmann, Carsten Bock
Am Do., 11. Feb. 2021 um 09:45 Uhr schrieb Juha Heinanen jh@tutpro.com:
Sergey Safarov writes:
Maybe need to move into more global changes...
How about DNS hostname usage for all headers? "Via", "Record-Route" maybe "Contact" when Kamailio with extra modules play media?
how about global directive like header_with_hostname=tue
I'm not sure if that is a good idea, since, for example, I would like to keep on using IP address 127.0.0.1:
Record-Route: sip:teams.tutpro.com:8007;transport=tls;r2=on;lr;pm=0 Record-Route: sip:127.0.0.1:5070;transport=tcp;r2=on;lr;pm=0
-- Juha
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Carsten Bock writes:
I don't understand the trouble: Wouldn't the following lead to the exact example:
listen=tls:1.2.3.4:8007 advertise teams.tutpro.com:8007 listen=tcp:1.2.3.4:5070
That would not work when K is a multi-tenant carrier Teams SBC proxy that requires tenant specific FQDN to be used in R-R header.
In that case the base domain would e.g. be teams.tutpro.com and each tenant has its sub-domain, e.g., tenant1.teams.tutpro.com, tenant2.teams.tutpro.com, ...
This is explained in
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-...
-- Juha
Carsten,
Thanks for the neat trick! I did not realise one could use an FQDN with the 'advertise' parameter to a listener.
An example of this is present in the 5.4.x core cookbook, but not in prior versions.
-- Alex
On 2/11/21 3:54 AM, Carsten Bock wrote:
Hi,
I don't understand the trouble: Wouldn't the following lead to the exact example:
listen=tls:1.2.3.4:8007 http://1.2.3.4:8007 advertise teams.tutpro.com:8007 http://teams.tutpro.com:8007 listen=tcp:1.2.3.4:5070 http://1.2.3.4:5070
As soon as you do: $fs = "tcp:1.2.3.4:5070 http://1.2.3.4:5070"; record_route(); (or put the other socket into $fs)
This results into two record-route headers, one with the hostname and one with the IP.
We use the Hostnames in all kinds of Record-Route and Via-Headers by doing exactly this.
Thanks, Carsten
-- Carsten Bock I CTO & Founder
ng-voice GmbH____
Trostbrücke 1 I 20457 Hamburg I Germany T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com http://www.ng-voice.com/____
Registry Office at Local Court Hamburg, HRB 120189 Managing Directors: Dr. David Bachmann, Carsten Bock
Am Do., 11. Feb. 2021 um 09:45 Uhr schrieb Juha Heinanen <jh@tutpro.com mailto:jh@tutpro.com>:
Sergey Safarov writes: > Maybe need to move into more global changes... > > How about DNS hostname usage for all headers? > "Via", "Record-Route" maybe "Contact" when Kamailio with extra modules > play media? > > how about global directive like > header_with_hostname=tue I'm not sure if that is a good idea, since, for example, I would like to keep on using IP address 127.0.0.1 <http://127.0.0.1>: Record-Route: <sip:teams.tutpro.com:8007 <http://teams.tutpro.com:8007>;transport=tls;r2=on;lr;pm=0> Record-Route: <sip:127.0.0.1:5070;transport=tcp;r2=on;lr;pm=0> -- Juha _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <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
On 11.02.21 16:16, Alex Balashov wrote:
Carsten,
Thanks for the neat trick! I did not realise one could use an FQDN with the 'advertise' parameter to a listener.
An example of this is present in the 5.4.x core cookbook, but not in prior versions.
... and many people complain that the docs do not improve, but they read only the manual they bought with version 4.3.2 ;-) ...
I always encouraged people to improve the docs with examples found useful on mailing lists discussions, but it seems that as soon as one gets the answers for own questions, stops there ...
Cheers, Daniel
-- Alex
On 2/11/21 3:54 AM, Carsten Bock wrote:
Hi,
I don't understand the trouble: Wouldn't the following lead to the exact example:
listen=tls:1.2.3.4:8007 http://1.2.3.4:8007 advertise teams.tutpro.com:8007 http://teams.tutpro.com:8007 listen=tcp:1.2.3.4:5070 http://1.2.3.4:5070
As soon as you do: $fs = "tcp:1.2.3.4:5070 http://1.2.3.4:5070"; record_route(); (or put the other socket into $fs)
This results into two record-route headers, one with the hostname and one with the IP.
We use the Hostnames in all kinds of Record-Route and Via-Headers by doing exactly this.
Thanks, Carsten
-- Carsten Bock I CTO & Founder
ng-voice GmbH____
Trostbrücke 1 I 20457 Hamburg I Germany T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com http://www.ng-voice.com/____
Registry Office at Local Court Hamburg, HRB 120189 Managing Directors: Dr. David Bachmann, Carsten Bock
Am Do., 11. Feb. 2021 um 09:45 Uhr schrieb Juha Heinanen <jh@tutpro.com mailto:jh@tutpro.com>:
Sergey Safarov writes:
> Maybe need to move into more global changes... > > How about DNS hostname usage for all headers? > "Via", "Record-Route" maybe "Contact" when Kamailio with extra modules > play media? > > how about global directive like > header_with_hostname=tue
I'm not sure if that is a good idea, since, for example, I would like to keep on using IP address 127.0.0.1 http://127.0.0.1:
Record-Route: <sip:teams.tutpro.com:8007 http://teams.tutpro.com:8007;transport=tls;r2=on;lr;pm=0> Record-Route: sip:127.0.0.1:5070;transport=tcp;r2=on;lr;pm=0
-- Juha
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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
-
Alex Balashov -
Carsten Bock -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Sergey Safarov