Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor
On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
Just made another test with TLS, not WSS. Same behavior
A -> Kamailio -> B
INVITE sip:88882@KAMAILIO_FQDN:5060 SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj84577fd7-611e-40ce-b095-835583310eab From: sip:88881@A_IP_ADDRESS;tag=62ce37c8-b186-40d9-ae88-31321338031d To: sip:88882@KAMAILIO_FQDN Contact: sip:asterisk@A_IP_ADDRESS:5060 Call-ID: 8c9f68bf-1514-4dfa-8ba0-72cd8922a22b CSeq: 597 INVITE Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Type: application/sdp Content-Length: 387
180 reply
SIP/2.0 180 Ringing Via: SIP/2.0/UDP A_IP_ADDRESS:5060;received=A_IP_ADDRESS;rport=5060;branch=z9hG4bKPj84577fd7-611e-40ce-b095-835583310eab From: sip:+XXXXX688881@tone.cern.ch;tag=62ce37c8-b186-40d9-ae88-31321338031d To: "TEST 88882" sip:88882@KAMAILIO_FQDN;tag=5AE57984-651CED77 CSeq: 597 INVITE Call-ID: 8c9f68bf-1514-4dfa-8ba0-72cd8922a22b Contact: sip:88882@192.168.0.30:54224;transport=tls Record-Route: sip:KAMAILIO_FQDN:5061;transport=tls;r2=on;lr=on;ftag=62ce37c8-b186-40d9-ae88-31321338031d;nat=tls, sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=62ce37c8-b186-40d9-ae88-31321338031d;nat=tls User-Agent: PolycomVVX-VVX_411-UA/6.3.1.11465 Allow-Events: conference,talk,hold Accept-Language: en Require: 100rel RSeq: 8193 Content-Length: 0
And PRACK from A
PRACK sip:88882@192.168.0.30:54224;transport=tls SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPjc9d866c0-a483-404e-9b97-d0738490fd74 From: sip:88881@A_IP_ADDRESS;tag=62ce37c8-b186-40d9-ae88-31321338031d To: sip:88882@KAMAILIO_FQDN;tag=5AE57984-651CED77 Call-ID: 8c9f68bf-1514-4dfa-8ba0-72cd8922a22b CSeq: 598 PRACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=62ce37c8-b186-40d9-ae88-31321338031d;nat=tls Route: sip:KAMAILIO_FQDN:5061;transport=tls;lr;r2=on;ftag=62ce37c8-b186-40d9-ae88-31321338031d;nat=tls RAck: 8193 597 INVITE Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
on *loose_route() *Kamailio is trying to send it to 192.168.0.30, which is just Contact address in 180 responce (incorrect one).
If using IP addresses in RR - all is working as expected
Maybe I'm missing some part of RFC?
Regards, Igor
On 07.05.2021 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel
On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor
On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel
On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel
On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel
On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor
On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel
On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel
On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
OK, because looping was something that should not have happened in this case.
Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses.
Cheers, Daniel
On 07.05.21 14:13, Igor Olhovskiy wrote:
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel
On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel
On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel
On 07.05.21 11:17, Igor Olhovskiy wrote: > > Hello, > > I saw there are some topics on this already and carefully walked > through all of them, but can't solve following issue. > > For a reason I do need that in Record-Route header sent to > endpoint would present FQDN. If it matters, it's UDP/WSS > conversion done on Kamailio. > > So, scheme is quite simple > > Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT) > > Main issue here, that if in Record-Route headers it's FQDN, but > not IP addresses, on a new transactions with a dialog (ACK on > 200, PRACK, BYE), Kamailio*loose_route()* function resolves > address of destination not current dialog, but actual R-URI (or > itself, if R-URI is something from WebRTC world) that is not > correct due to NAT. > > If in RR headers IP addresses are present - all is working as > expected. > > As an example (RR with FQDN) > > B answers 200 > > SIP/2.0 200 OK > Record-Route: > sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss > Record-Route: > sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss > Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP > ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e > To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 > From: > <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d > Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb > CSeq: 18326 INVITE > Contact: sip:88290@toleivu2gdbh.invalid;transport=wss > Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER > Supported: outbound > Content-Type: application/sdp > Content-Length: 817 > > > ACK looks like > > ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 > Via: SIP/2.0/UDP > A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 > From: > sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d > To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 > Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb > CSeq: 18326 ACK > Route: > sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss > Route: > sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss > Max-Forwards: 70 > User-Agent: Asterisk PBX 13.33.0 > Content-Length: 0 > > And Kamailio on *loose_route()* loops ACK to itself. (with > result of function == 1) > > In a case if in Record-Route/Route headers just IP address of > Kamailio present, all works as expected, but it's not really > behavior I want to achieve. > > I've tried to play with *record_route_preset("...")* specifying > only WSS part (as suggested in > https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but > no luck. > > Also wanted to try approach using record_route_preset() function > in branch route, but it was working only with first branch, not > affecting others (but I assume having different RR headers > across branches is not a good idea) > > -- > Regards, > Igor > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Daniel,
Seems to be it's really the case, but with other function
With FQDN in RR
|is_first_hop()|
is not acting correctly for reply.
For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it
But in Record-Route we have "myself", but *is_first_hop()* returning 0.
Thanks!
Regards, Igor
On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:
OK, because looping was something that should not have happened in this case.
Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses.
Cheers, Daniel
On 07.05.21 14:13, Igor Olhovskiy wrote:
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel
On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel
On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor On 07.05.2021 13:21, Daniel-Constantin Mierla wrote: > > Hello, > > is the KAMAILIO_FQDN set as local domain for Kamailio (via alias > parameter or domain module+register myself)? > > Cheers, > Daniel > > On 07.05.21 11:17, Igor Olhovskiy wrote: >> >> Hello, >> >> I saw there are some topics on this already and carefully >> walked through all of them, but can't solve following issue. >> >> For a reason I do need that in Record-Route header sent to >> endpoint would present FQDN. If it matters, it's UDP/WSS >> conversion done on Kamailio. >> >> So, scheme is quite simple >> >> Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT) >> >> Main issue here, that if in Record-Route headers it's FQDN, but >> not IP addresses, on a new transactions with a dialog (ACK on >> 200, PRACK, BYE), Kamailio*loose_route()* function resolves >> address of destination not current dialog, but actual R-URI (or >> itself, if R-URI is something from WebRTC world) that is not >> correct due to NAT. >> >> If in RR headers IP addresses are present - all is working as >> expected. >> >> As an example (RR with FQDN) >> >> B answers 200 >> >> SIP/2.0 200 OK >> Record-Route: >> sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >> Record-Route: >> sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >> Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP >> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e >> To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 >> From: >> <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >> CSeq: 18326 INVITE >> Contact: sip:88290@toleivu2gdbh.invalid;transport=wss >> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER >> Supported: outbound >> Content-Type: application/sdp >> Content-Length: 817 >> >> >> ACK looks like >> >> ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 >> Via: SIP/2.0/UDP >> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >> From: >> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >> CSeq: 18326 ACK >> Route: >> sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >> Route: >> sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >> Max-Forwards: 70 >> User-Agent: Asterisk PBX 13.33.0 >> Content-Length: 0 >> >> And Kamailio on *loose_route()* loops ACK to itself. (with >> result of function == 1) >> >> In a case if in Record-Route/Route headers just IP address of >> Kamailio present, all works as expected, but it's not really >> behavior I want to achieve. >> >> I've tried to play with *record_route_preset("...")* specifying >> only WSS part (as suggested in >> https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but >> no luck. >> >> Also wanted to try approach using record_route_preset() >> function in branch route, but it was working only with first >> branch, not affecting others (but I assume having different RR >> headers across branches is not a good idea) >> >> -- >> Regards, >> Igor >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> *sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the sender! >> Edit mailing list options or unsubscribe: >> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- > Daniel-Constantin Mierla --www.asipto.com > www.twitter.com/miconda --www.linkedin.com/in/miconda > Kamailio Advanced Training - Online > May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) > *https://www.asipto.com/sw/kamailio-advanced-training-online/
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
-- Daniel-Constantin Mierla --www.asipto.com www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/
Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead.
On Fri, 7 May 2021 at 13:48, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Daniel,
Seems to be it's really the case, but with other function
With FQDN in RR is_first_hop()
is not acting correctly for reply.
For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it
But in Record-Route we have "myself", but *is_first_hop()* returning 0.
Thanks!
Regards, Igor
On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:
OK, because looping was something that should not have happened in this case.
Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses.
Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor
On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor
On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor
On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio* loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@ <KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
David,
Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config.
So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias
Regards, Igor
On 07.05.2021 16:07, David Villasmil wrote:
Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead.
On Fri, 7 May 2021 at 13:48, Igor Olhovskiy <igorolhovskiy@gmail.com mailto:igorolhovskiy@gmail.com> wrote:
Daniel, Seems to be it's really the case, but with other function With FQDN in RR |is_first_hop()| is not acting correctly for reply.For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching itBut in Record-Route we have "myself", but *is_first_hop()* returning 0. Thanks! Regards, Igor On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:OK, because looping was something that should not have happened in this case. Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses. Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:Ah, no, sorry, I was wrong at this one, This just is not sent with "unable to resolve address toleivu2gdbh.invalid". Sorry. Looping were something else during my tests, this just with *advertise* added Regards, Igor On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added. Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:Sure. ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: <sip:88881@A_IP_ADDRESS>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: <sip:88290@KAMAILIO_FQDN>;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: <sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss> Route: <sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss> Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0 By loop I meant, Kamailio just relaying it back to self and discard. Regards, Igor On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:Can you paste the ACK that loops, after being handled once by Kamailio? Cheers, Daniel On 07.05.21 13:25, Igor Olhovskiy wrote:> > Daniel, > > Yes, it is. > > alias=... > > Also tried with > > listen = IP advertise FQDN > > same behavior, loose_route() stops acting correctly. > > PS: Forgot to add, Kamailio 5.4.3 / 5.4.4 > > Regards, > Igor > On 07.05.2021 13:21, Daniel-Constantin Mierla wrote: >> >> Hello, >> >> is the KAMAILIO_FQDN set as local domain for Kamailio (via >> alias parameter or domain module+register myself)? >> >> Cheers, >> Daniel >> >> On 07.05.21 11:17, Igor Olhovskiy wrote: >>> >>> Hello, >>> >>> I saw there are some topics on this already and carefully >>> walked through all of them, but can't solve following issue. >>> >>> For a reason I do need that in Record-Route header sent to >>> endpoint would present FQDN. If it matters, it's UDP/WSS >>> conversion done on Kamailio. >>> >>> So, scheme is quite simple >>> >>> Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT) >>> >>> Main issue here, that if in Record-Route headers it's >>> FQDN, but not IP addresses, on a new transactions with a >>> dialog (ACK on 200, PRACK, BYE), Kamailio*loose_route()* >>> function resolves address of destination not current >>> dialog, but actual R-URI (or itself, if R-URI is something >>> from WebRTC world) that is not correct due to NAT. >>> >>> If in RR headers IP addresses are present - all is working >>> as expected. >>> >>> As an example (RR with FQDN) >>> >>> B answers 200 >>> >>> SIP/2.0 200 OK >>> Record-Route: >>> sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>> Record-Route: >>> sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>> Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP >>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e >>> To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 >>> From: >>> <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>> CSeq: 18326 INVITE >>> Contact: sip:88290@toleivu2gdbh.invalid;transport=wss >>> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER >>> Supported: outbound >>> Content-Type: application/sdp >>> Content-Length: 817 >>> >>> >>> ACK looks like >>> >>> ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 >>> Via: SIP/2.0/UDP >>> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >>> From: >>> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>> CSeq: 18326 ACK >>> Route: >>> sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>> Route: >>> sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>> Max-Forwards: 70 >>> User-Agent: Asterisk PBX 13.33.0 >>> Content-Length: 0 >>> >>> And Kamailio on *loose_route()* loops ACK to itself. (with >>> result of function == 1) >>> >>> In a case if in Record-Route/Route headers just IP address >>> of Kamailio present, all works as expected, but it's not >>> really behavior I want to achieve. >>> >>> I've tried to play with *record_route_preset("...")* >>> specifying only WSS part (as suggested in >>> https://skalatan.de/de/blog/kamailio-sbc-teams >>> https://skalatan.de/de/blog/kamailio-sbc-teams) with >>> FQDN, but no luck. >>> >>> Also wanted to try approach using record_route_preset() >>> function in branch route, but it was working only with >>> first branch, not affecting others (but I assume having >>> different RR headers across branches is not a good idea) >>> >>> -- >>> Regards, >>> Igor >>> >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>> Edit mailing list options or unsubscribe: >>> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> -- >> Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com >> www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >> Kamailio Advanced Training - Online >> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >> *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender! > Edit mailing list options or unsubscribe:
> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>-- Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>-- Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>-- Regards,
David Villasmil email: david.villasmil.work@gmail.com mailto:david.villasmil.work@gmail.com phone: +34669448337
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Have you tried verifying Kamailio actually believes the FQDN is itself?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy igorolhovskiy@gmail.com wrote:
David,
Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config.
So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias
Regards, Igor
On 07.05.2021 16:07, David Villasmil wrote:
Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead.
On Fri, 7 May 2021 at 13:48, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Daniel,
Seems to be it's really the case, but with other function
With FQDN in RR is_first_hop()
is not acting correctly for reply.
For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it
But in Record-Route we have "myself", but *is_first_hop()* returning 0.
Thanks!
Regards, Igor
On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:
OK, because looping was something that should not have happened in this case.
Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses.
Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor
On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor
On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor
On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio* loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@ <KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Yes. It passesuri == myself condition on auth.
Regards, Igor
On 07.05.2021 17:32, David Villasmil wrote:
Have you tried verifying Kamailio actually believes the FQDN is itself?
Regards,
David Villasmil email: david.villasmil.work@gmail.com mailto:david.villasmil.work@gmail.com phone: +34669448337
On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy <igorolhovskiy@gmail.com mailto:igorolhovskiy@gmail.com> wrote:
David, Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config. So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias Regards, Igor On 07.05.2021 16:07, David Villasmil wrote:Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead. On Fri, 7 May 2021 at 13:48, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Daniel, Seems to be it's really the case, but with other function With FQDN in RR |is_first_hop()| is not acting correctly for reply.For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching itBut in Record-Route we have "myself", but *is_first_hop()* returning 0. Thanks! Regards, Igor On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:OK, because looping was something that should not have happened in this case. Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses. Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:Ah, no, sorry, I was wrong at this one, This just is not sent with "unable to resolve address toleivu2gdbh.invalid". Sorry. Looping were something else during my tests, this just with *advertise* added Regards, Igor On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added. Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:Sure. ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: <sip:88881@A_IP_ADDRESS>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: <sip:88290@KAMAILIO_FQDN>;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: <sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss> Route: <sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss> Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0 By loop I meant, Kamailio just relaying it back to self and discard. Regards, Igor On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:> > Can you paste the ACK that loops, after being handled > once by Kamailio? > > Cheers, > Daniel > > On 07.05.21 13:25, Igor Olhovskiy wrote: >> >> Daniel, >> >> Yes, it is. >> >> alias=... >> >> Also tried with >> >> listen = IP advertise FQDN >> >> same behavior, loose_route() stops acting correctly. >> >> PS: Forgot to add, Kamailio 5.4.3 / 5.4.4 >> >> Regards, >> Igor >> On 07.05.2021 13:21, Daniel-Constantin Mierla wrote: >>> >>> Hello, >>> >>> is the KAMAILIO_FQDN set as local domain for Kamailio >>> (via alias parameter or domain module+register myself)? >>> >>> Cheers, >>> Daniel >>> >>> On 07.05.21 11:17, Igor Olhovskiy wrote: >>>> >>>> Hello, >>>> >>>> I saw there are some topics on this already and >>>> carefully walked through all of them, but can't solve >>>> following issue. >>>> >>>> For a reason I do need that in Record-Route header >>>> sent to endpoint would present FQDN. If it matters, >>>> it's UDP/WSS conversion done on Kamailio. >>>> >>>> So, scheme is quite simple >>>> >>>> Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT) >>>> >>>> Main issue here, that if in Record-Route headers it's >>>> FQDN, but not IP addresses, on a new transactions >>>> with a dialog (ACK on 200, PRACK, BYE), >>>> Kamailio*loose_route()* function resolves address of >>>> destination not current dialog, but actual R-URI (or >>>> itself, if R-URI is something from WebRTC world) that >>>> is not correct due to NAT. >>>> >>>> If in RR headers IP addresses are present - all is >>>> working as expected. >>>> >>>> As an example (RR with FQDN) >>>> >>>> B answers 200 >>>> >>>> SIP/2.0 200 OK >>>> Record-Route: >>>> sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>> Record-Route: >>>> sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>> Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP >>>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e >>>> To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 >>>> From: >>>> <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>> CSeq: 18326 INVITE >>>> Contact: sip:88290@toleivu2gdbh.invalid;transport=wss >>>> Allow: >>>> ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER >>>> Supported: outbound >>>> Content-Type: application/sdp >>>> Content-Length: 817 >>>> >>>> >>>> ACK looks like >>>> >>>> ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 >>>> Via: SIP/2.0/UDP >>>> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >>>> From: >>>> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>> CSeq: 18326 ACK >>>> Route: >>>> sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>> Route: >>>> sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>> Max-Forwards: 70 >>>> User-Agent: Asterisk PBX 13.33.0 >>>> Content-Length: 0 >>>> >>>> And Kamailio on *loose_route()* loops ACK to itself. >>>> (with result of function == 1) >>>> >>>> In a case if in Record-Route/Route headers just IP >>>> address of Kamailio present, all works as expected, >>>> but it's not really behavior I want to achieve. >>>> >>>> I've tried to play with *record_route_preset("...")* >>>> specifying only WSS part (as suggested in >>>> https://skalatan.de/de/blog/kamailio-sbc-teams >>>> https://skalatan.de/de/blog/kamailio-sbc-teams) >>>> with FQDN, but no luck. >>>> >>>> Also wanted to try approach using >>>> record_route_preset() function in branch route, but >>>> it was working only with first branch, not affecting >>>> others (but I assume having different RR headers >>>> across branches is not a good idea) >>>> >>>> -- >>>> Regards, >>>> Igor >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>> Edit mailing list options or unsubscribe: >>>> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> -- >>> Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com >>> www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >>> Kamailio Advanced Training - Online >>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >>> *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the sender! >> Edit mailing list options or unsubscribe: >> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- > Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com > www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda > Kamailio Advanced Training - Online > May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) > *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/
-- Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>-- Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Can you share a trace?
On Fri, 7 May 2021 at 21:12, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Yes. It passes uri == myself condition on auth.
Regards, Igor
On 07.05.2021 17:32, David Villasmil wrote:
Have you tried verifying Kamailio actually believes the FQDN is itself?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy igorolhovskiy@gmail.com wrote:
David,
Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config.
So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias
Regards, Igor
On 07.05.2021 16:07, David Villasmil wrote:
Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead.
On Fri, 7 May 2021 at 13:48, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Daniel,
Seems to be it's really the case, but with other function
With FQDN in RR is_first_hop()
is not acting correctly for reply.
For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it
But in Record-Route we have "myself", but *is_first_hop()* returning 0.
Thanks!
Regards, Igor
On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:
OK, because looping was something that should not have happened in this case.
Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses.
Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor
On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor
On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor
On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio* loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@ <KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
May be related to a previous topic about is_first_hop() and 'myself'
https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html
On Fri, May 7, 2021 at 7:22 PM David Villasmil < david.villasmil.work@gmail.com> wrote:
Can you share a trace?
On Fri, 7 May 2021 at 21:12, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Yes. It passes uri == myself condition on auth.
Regards, Igor
On 07.05.2021 17:32, David Villasmil wrote:
Have you tried verifying Kamailio actually believes the FQDN is itself?
Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy igorolhovskiy@gmail.com wrote:
David,
Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config.
So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias
Regards, Igor
On 07.05.2021 16:07, David Villasmil wrote:
Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead.
On Fri, 7 May 2021 at 13:48, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Daniel,
Seems to be it's really the case, but with other function
With FQDN in RR is_first_hop()
is not acting correctly for reply.
For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it
But in Record-Route we have "myself", but *is_first_hop()* returning 0.
Thanks!
Regards, Igor
On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:
OK, because looping was something that should not have happened in this case.
Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses.
Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:
Ah, no, sorry, I was wrong at this one,
This just is not sent with "unable to resolve address toleivu2gdbh.invalid".
Sorry. Looping were something else during my tests, this just with *advertise* added
Regards, Igor
On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:
This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added.
Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:
Sure.
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
By loop I meant, Kamailio just relaying it back to self and discard.
Regards, Igor
On 07.05.2021 13:48, Daniel-Constantin Mierla wrote:
Can you paste the ACK that loops, after being handled once by Kamailio?
Cheers, Daniel On 07.05.21 13:25, Igor Olhovskiy wrote:
Daniel,
Yes, it is.
alias=...
Also tried with
listen = IP advertise FQDN
same behavior, loose_route() stops acting correctly.
PS: Forgot to add, Kamailio 5.4.3 / 5.4.4
Regards, Igor
On 07.05.2021 13:21, Daniel-Constantin Mierla wrote:
Hello,
is the KAMAILIO_FQDN set as local domain for Kamailio (via alias parameter or domain module+register myself)?
Cheers, Daniel On 07.05.21 11:17, Igor Olhovskiy wrote:
Hello,
I saw there are some topics on this already and carefully walked through all of them, but can't solve following issue.
For a reason I do need that in Record-Route header sent to endpoint would present FQDN. If it matters, it's UDP/WSS conversion done on Kamailio.
So, scheme is quite simple
Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint B (NAT)
Main issue here, that if in Record-Route headers it's FQDN, but not IP addresses, on a new transactions with a dialog (ACK on 200, PRACK, BYE), Kamailio* loose_route()* function resolves address of destination not current dialog, but actual R-URI (or itself, if R-URI is something from WebRTC world) that is not correct due to NAT.
If in RR headers IP addresses are present - all is working as expected.
As an example (RR with FQDN)
B answers 200
SIP/2.0 200 OK Record-Route: sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Record-Route: sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Via: SIP/2.0/UDP <A_IP_ADDRESS>:5060;received=A IP ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 From: <sip:+XXXX7688881@ <KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 INVITE Contact: sip:88290@toleivu2gdbh.invalid;transport=wss Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound Content-Type: application/sdp Content-Length: 817
ACK looks like
ACK sip:88290@toleivu2gdbh.invalid;transport=wss SIP/2.0 Via: SIP/2.0/UDP A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 From: sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb CSeq: 18326 ACK Route: sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Route: sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss Max-Forwards: 70 User-Agent: Asterisk PBX 13.33.0 Content-Length: 0
And Kamailio on *loose_route()* loops ACK to itself. (with result of function == 1)
In a case if in Record-Route/Route headers just IP address of Kamailio present, all works as expected, but it's not really behavior I want to achieve.
I've tried to play with *record_route_preset("...")* specifying only WSS part (as suggested in https://skalatan.de/de/blog/kamailio-sbc-teams) with FQDN, but no luck.
Also wanted to try approach using record_route_preset() function in branch route, but it was working only with first branch, not affecting others (but I assume having different RR headers across branches is not a good idea)
-- Regards, Igor
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Regards,
David Villasmil email: david.villasmil.work@gmail.com phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Sergiu,
Actually, yes
Problem is in order of checking in this function
https://github.com/kamailio/kamailio/blob/02240711239149e2f5c4890a70ab158d10...
if (((ip = str2ip(&(puri.host))) == NULL) && ((ip = str2ip6(&(puri.host))) == NULL)) { LM_DBG("uri host is not an ip address\n"); return -1; }
So, it's checking if Record-Route is an IP address before actually calling *check_self()* function. I'll add an issue.
Regards, Igor
On 08.05.2021 02:42, Sergiu Pojoga wrote:
May be related to a previous topic about is_first_hop() and 'myself'
https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html
On Fri, May 7, 2021 at 7:22 PM David Villasmil <david.villasmil.work@gmail.com mailto:david.villasmil.work@gmail.com> wrote:
Can you share a trace? On Fri, 7 May 2021 at 21:12, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Yes. It passesuri == myself condition on auth. Regards, Igor On 07.05.2021 17:32, David Villasmil wrote:Have you tried verifying Kamailio actually believes the FQDN is itself? Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: David, Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config. So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias Regards, Igor On 07.05.2021 16:07, David Villasmil wrote:Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead. On Fri, 7 May 2021 at 13:48, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Daniel, Seems to be it's really the case, but with other function With FQDN in RR |is_first_hop()| is not acting correctly for reply.For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching itBut in Record-Route we have "myself", but *is_first_hop()* returning 0. Thanks! Regards, Igor On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:OK, because looping was something that should not have happened in this case. Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses. Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:Ah, no, sorry, I was wrong at this one, This just is not sent with "unable to resolve address toleivu2gdbh.invalid". Sorry. Looping were something else during my tests, this just with *advertise* added Regards, Igor On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:This looks like incoming ACK, because there is only one Via header, so it is not what proxy forwards -- that one is relevant to see what headers were consumed and added. Cheers, Daniel On 07.05.21 13:51, Igor Olhovskiy wrote:> Sure. > > ACK sip:88290@toleivu2gdbh.invalid;transport=wss > SIP/2.0 > Via: SIP/2.0/UDP > A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 > From: > sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d > To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 > Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb > CSeq: 18326 ACK > Route: > sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss > Route: > sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss > Max-Forwards: 70 > User-Agent: Asterisk PBX 13.33.0 > Content-Length: 0 > > > By loop I meant, Kamailio just relaying it back > to self and discard. > > Regards, > Igor > On 07.05.2021 13:48, Daniel-Constantin Mierla wrote: >> >> Can you paste the ACK that loops, after being >> handled once by Kamailio? >> >> Cheers, >> Daniel >> >> On 07.05.21 13:25, Igor Olhovskiy wrote: >>> >>> Daniel, >>> >>> Yes, it is. >>> >>> alias=... >>> >>> Also tried with >>> >>> listen = IP advertise FQDN >>> >>> same behavior, loose_route() stops acting >>> correctly. >>> >>> PS: Forgot to add, Kamailio 5.4.3 / 5.4.4 >>> >>> Regards, >>> Igor >>> On 07.05.2021 13:21, Daniel-Constantin Mierla >>> wrote: >>>> >>>> Hello, >>>> >>>> is the KAMAILIO_FQDN set as local domain for >>>> Kamailio (via alias parameter or domain >>>> module+register myself)? >>>> >>>> Cheers, >>>> Daniel >>>> >>>> On 07.05.21 11:17, Igor Olhovskiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> I saw there are some topics on this already >>>>> and carefully walked through all of them, >>>>> but can't solve following issue. >>>>> >>>>> For a reason I do need that in Record-Route >>>>> header sent to endpoint would present FQDN. >>>>> If it matters, it's UDP/WSS conversion done >>>>> on Kamailio. >>>>> >>>>> So, scheme is quite simple >>>>> >>>>> Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint >>>>> B (NAT) >>>>> >>>>> Main issue here, that if in Record-Route >>>>> headers it's FQDN, but not IP addresses, on >>>>> a new transactions with a dialog (ACK on >>>>> 200, PRACK, BYE), Kamailio*loose_route()* >>>>> function resolves address of destination not >>>>> current dialog, but actual R-URI (or itself, >>>>> if R-URI is something from WebRTC world) >>>>> that is not correct due to NAT. >>>>> >>>>> If in RR headers IP addresses are present - >>>>> all is working as expected. >>>>> >>>>> As an example (RR with FQDN) >>>>> >>>>> B answers 200 >>>>> >>>>> SIP/2.0 200 OK >>>>> Record-Route: >>>>> sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>> Record-Route: >>>>> sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>> Via: SIP/2.0/UDP >>>>> <A_IP_ADDRESS>:5060;received=A IP >>>>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e >>>>> To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 >>>>> From: >>>>> <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>>> CSeq: 18326 INVITE >>>>> Contact: >>>>> sip:88290@toleivu2gdbh.invalid;transport=wss >>>>> Allow: >>>>> ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER >>>>> Supported: outbound >>>>> Content-Type: application/sdp >>>>> Content-Length: 817 >>>>> >>>>> >>>>> ACK looks like >>>>> >>>>> ACK >>>>> sip:88290@toleivu2gdbh.invalid;transport=wss >>>>> SIP/2.0 >>>>> Via: SIP/2.0/UDP >>>>> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >>>>> From: >>>>> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>>> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >>>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>>> CSeq: 18326 ACK >>>>> Route: >>>>> sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>> Route: >>>>> sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>> Max-Forwards: 70 >>>>> User-Agent: Asterisk PBX 13.33.0 >>>>> Content-Length: 0 >>>>> >>>>> And Kamailio on *loose_route()* loops ACK to >>>>> itself. (with result of function == 1) >>>>> >>>>> In a case if in Record-Route/Route headers >>>>> just IP address of Kamailio present, all >>>>> works as expected, but it's not really >>>>> behavior I want to achieve. >>>>> >>>>> I've tried to play with >>>>> *record_route_preset("...")* specifying only >>>>> WSS part (as suggested in >>>>> https://skalatan.de/de/blog/kamailio-sbc-teams >>>>> https://skalatan.de/de/blog/kamailio-sbc-teams) >>>>> with FQDN, but no luck. >>>>> >>>>> Also wanted to try approach using >>>>> record_route_preset() function in branch >>>>> route, but it was working only with first >>>>> branch, not affecting others (but I assume >>>>> having different RR headers across branches >>>>> is not a good idea) >>>>> >>>>> -- >>>>> Regards, >>>>> Igor >>>>> >>>>> __________________________________________________________ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>>> Edit mailing list options or unsubscribe: >>>>> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> -- >>>> Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com >>>> www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >>>> Kamailio Advanced Training - Online >>>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >>>> *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ >>> >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>> Edit mailing list options or unsubscribe: >>> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> -- >> Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com >> www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >> Kamailio Advanced Training - Online >> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>> *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/
Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>-- Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
In a case, if someone will find this topic via search
is_first_hop() according to documentation is working only with IP addresses in a case of replies. So, it's fully correct behavior.
My bad.
Regards, Igor
On 10.05.2021 08:55, Igor Olhovskiy wrote:
Sergiu,
Actually, yes
Problem is in order of checking in this function
https://github.com/kamailio/kamailio/blob/02240711239149e2f5c4890a70ab158d10...
if (((ip = str2ip(&(puri.host))) == NULL) && ((ip = str2ip6(&(puri.host))) == NULL)) { LM_DBG("uri host is not an ip address\n"); return -1; }
So, it's checking if Record-Route is an IP address before actually calling *check_self()* function. I'll add an issue.
Regards, Igor On 08.05.2021 02:42, Sergiu Pojoga wrote:
May be related to a previous topic about is_first_hop() and 'myself'
https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html
On Fri, May 7, 2021 at 7:22 PM David Villasmil <david.villasmil.work@gmail.com mailto:david.villasmil.work@gmail.com> wrote:
Can you share a trace? On Fri, 7 May 2021 at 21:12, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Yes. It passesuri == myself condition on auth. Regards, Igor On 07.05.2021 17:32, David Villasmil wrote:Have you tried verifying Kamailio actually believes the FQDN is itself? Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: David, Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config. So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias Regards, Igor On 07.05.2021 16:07, David Villasmil wrote:Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead. On Fri, 7 May 2021 at 13:48, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Daniel, Seems to be it's really the case, but with other function With FQDN in RR |is_first_hop()| is not acting correctly for reply.For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching itBut in Record-Route we have "myself", but *is_first_hop()* returning 0. Thanks! Regards, Igor On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:OK, because looping was something that should not have happened in this case. Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses. Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:Ah, no, sorry, I was wrong at this one, This just is not sent with "unable to resolve address toleivu2gdbh.invalid". Sorry. Looping were something else during my tests, this just with *advertise* added Regards, Igor On 07.05.2021 14:02, Daniel-Constantin Mierla wrote:> > This looks like incoming ACK, because there is > only one Via header, so it is not what proxy > forwards -- that one is relevant to see what > headers were consumed and added. > > Cheers, > Daniel > > On 07.05.21 13:51, Igor Olhovskiy wrote: >> Sure. >> >> ACK >> sip:88290@toleivu2gdbh.invalid;transport=wss >> SIP/2.0 >> Via: SIP/2.0/UDP >> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >> From: >> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >> CSeq: 18326 ACK >> Route: >> sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >> Route: >> sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >> Max-Forwards: 70 >> User-Agent: Asterisk PBX 13.33.0 >> Content-Length: 0 >> >> >> By loop I meant, Kamailio just relaying it back >> to self and discard. >> >> Regards, >> Igor >> On 07.05.2021 13:48, Daniel-Constantin Mierla >> wrote: >>> >>> Can you paste the ACK that loops, after being >>> handled once by Kamailio? >>> >>> Cheers, >>> Daniel >>> >>> On 07.05.21 13:25, Igor Olhovskiy wrote: >>>> >>>> Daniel, >>>> >>>> Yes, it is. >>>> >>>> alias=... >>>> >>>> Also tried with >>>> >>>> listen = IP advertise FQDN >>>> >>>> same behavior, loose_route() stops acting >>>> correctly. >>>> >>>> PS: Forgot to add, Kamailio 5.4.3 / 5.4.4 >>>> >>>> Regards, >>>> Igor >>>> On 07.05.2021 13:21, Daniel-Constantin Mierla >>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> is the KAMAILIO_FQDN set as local domain for >>>>> Kamailio (via alias parameter or domain >>>>> module+register myself)? >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> On 07.05.21 11:17, Igor Olhovskiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I saw there are some topics on this already >>>>>> and carefully walked through all of them, >>>>>> but can't solve following issue. >>>>>> >>>>>> For a reason I do need that in Record-Route >>>>>> header sent to endpoint would present FQDN. >>>>>> If it matters, it's UDP/WSS conversion done >>>>>> on Kamailio. >>>>>> >>>>>> So, scheme is quite simple >>>>>> >>>>>> Enpoint A ->UDP-> Kamailio ->WSS-> Endpoint >>>>>> B (NAT) >>>>>> >>>>>> Main issue here, that if in Record-Route >>>>>> headers it's FQDN, but not IP addresses, on >>>>>> a new transactions with a dialog (ACK on >>>>>> 200, PRACK, BYE), Kamailio*loose_route()* >>>>>> function resolves address of destination >>>>>> not current dialog, but actual R-URI (or >>>>>> itself, if R-URI is something from WebRTC >>>>>> world) that is not correct due to NAT. >>>>>> >>>>>> If in RR headers IP addresses are present - >>>>>> all is working as expected. >>>>>> >>>>>> As an example (RR with FQDN) >>>>>> >>>>>> B answers 200 >>>>>> >>>>>> SIP/2.0 200 OK >>>>>> Record-Route: >>>>>> sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>> Record-Route: >>>>>> sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>> Via: SIP/2.0/UDP >>>>>> <A_IP_ADDRESS>:5060;received=A IP >>>>>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e >>>>>> To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 >>>>>> From: >>>>>> <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>>>> CSeq: 18326 INVITE >>>>>> Contact: >>>>>> sip:88290@toleivu2gdbh.invalid;transport=wss >>>>>> Allow: >>>>>> ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER >>>>>> Supported: outbound >>>>>> Content-Type: application/sdp >>>>>> Content-Length: 817 >>>>>> >>>>>> >>>>>> ACK looks like >>>>>> >>>>>> ACK >>>>>> sip:88290@toleivu2gdbh.invalid;transport=wss >>>>>> SIP/2.0 >>>>>> Via: SIP/2.0/UDP >>>>>> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >>>>>> From: >>>>>> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>>>> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >>>>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>>>> CSeq: 18326 ACK >>>>>> Route: >>>>>> sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>> Route: >>>>>> sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>> Max-Forwards: 70 >>>>>> User-Agent: Asterisk PBX 13.33.0 >>>>>> Content-Length: 0 >>>>>> >>>>>> And Kamailio on *loose_route()* loops ACK >>>>>> to itself. (with result of function == 1) >>>>>> >>>>>> In a case if in Record-Route/Route headers >>>>>> just IP address of Kamailio present, all >>>>>> works as expected, but it's not really >>>>>> behavior I want to achieve. >>>>>> >>>>>> I've tried to play with >>>>>> *record_route_preset("...")* specifying >>>>>> only WSS part (as suggested in >>>>>> https://skalatan.de/de/blog/kamailio-sbc-teams >>>>>> https://skalatan.de/de/blog/kamailio-sbc-teams) >>>>>> with FQDN, but no luck. >>>>>> >>>>>> Also wanted to try approach using >>>>>> record_route_preset() function in branch >>>>>> route, but it was working only with first >>>>>> branch, not affecting others (but I assume >>>>>> having different RR headers across branches >>>>>> is not a good idea) >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Igor >>>>>> >>>>>> __________________________________________________________ >>>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>>> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>>>> Edit mailing list options or unsubscribe: >>>>>> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> -- >>>>> Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com >>>>> www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >>>>> Kamailio Advanced Training - Online >>>>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >>>>> *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> *sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>> Edit mailing list options or unsubscribe: >>>> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> -- >>> Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com >>> www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >>> Kamailio Advanced Training - Online >>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >>> *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ > -- > Daniel-Constantin Mierla --www.asipto.com http://www.asipto.com > www.twitter.com/miconda http://www.twitter.com/miconda --www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda > Kamailio Advanced Training - Online > May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) > *https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/
-- Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) *https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
Kamailio - Users Mailing List - Non Commercial Discussions *sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
As an update, in the development version there is no is_first_hop(mode) and when mode is 1, it should skip checking for ip and matching src ip against it, so it should work with FQDN, expecting the config admin to restrict looping, etc... for accurate results.
Cheers, Daniel
On 13.05.21 17:04, Igor Olhovskiy wrote:
In a case, if someone will find this topic via search
is_first_hop() according to documentation is working only with IP addresses in a case of replies. So, it's fully correct behavior.
My bad.
Regards, Igor On 10.05.2021 08:55, Igor Olhovskiy wrote:
Sergiu,
Actually, yes
Problem is in order of checking in this function
https://github.com/kamailio/kamailio/blob/02240711239149e2f5c4890a70ab158d10...
if (((ip = str2ip(&(puri.host))) == NULL) && ((ip = str2ip6(&(puri.host))) == NULL)) { LM_DBG("uri host is not an ip address\n"); return -1; }
So, it's checking if Record-Route is an IP address before actually calling *check_self()* function. I'll add an issue.
Regards, Igor On 08.05.2021 02:42, Sergiu Pojoga wrote:
May be related to a previous topic about is_first_hop() and 'myself'
https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html https://lists.kamailio.org/pipermail/sr-users/2018-October/103261.html
On Fri, May 7, 2021 at 7:22 PM David Villasmil <david.villasmil.work@gmail.com mailto:david.villasmil.work@gmail.com> wrote:
Can you share a trace? On Fri, 7 May 2021 at 21:12, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Yes. It passesuri == myself condition on auth. Regards, Igor On 07.05.2021 17:32, David Villasmil wrote:Have you tried verifying Kamailio actually believes the FQDN is itself? Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: David, Yes, I did added it, means it was there, but is_first_hop() was blocking adding it. I think it's some leftovers from default config. So, my conclusion, that is_first_hop() is ok with IP addresses, but not ok with FQDN in route. Although FQDN is added as alias Regards, Igor On 07.05.2021 16:07, David Villasmil wrote:Did you add the handle_ruri_alias() as suggested by Daniel? I had something like this where I would get “unable to resolve blah blah blah" and it’s because the RURI is the actual wss “address” which is unresolvable, so executing the function forces kamailio to take the alias instead. On Fri, 7 May 2021 at 13:48, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote: Daniel, Seems to be it's really the case, but with other function With FQDN in RR |is_first_hop()| is not acting correctly for reply.For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching itBut in Record-Route we have "myself", but *is_first_hop()* returning 0. Thanks! Regards, Igor On 07.05.2021 14:22, Daniel-Constantin Mierla wrote:OK, because looping was something that should not have happened in this case. Then the problem is that you do not do nat-traversal-like processing for websocket/webrtc traffic. You have to use set_contact_alias() + handle_ruri_alias() because the webrtc endpoints do not set "valid" contact addresses. Cheers, Daniel On 07.05.21 14:13, Igor Olhovskiy wrote:> > Ah, no, sorry, I was wrong at this one, > > This just is not sent with "unable to resolve > address toleivu2gdbh.invalid". > > Sorry. Looping were something else during my > tests, this just with *advertise* added > > Regards, > Igor > On 07.05.2021 14:02, Daniel-Constantin Mierla wrote: >> >> This looks like incoming ACK, because there is >> only one Via header, so it is not what proxy >> forwards -- that one is relevant to see what >> headers were consumed and added. >> >> Cheers, >> Daniel >> >> On 07.05.21 13:51, Igor Olhovskiy wrote: >>> Sure. >>> >>> ACK >>> sip:88290@toleivu2gdbh.invalid;transport=wss >>> SIP/2.0 >>> Via: SIP/2.0/UDP >>> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >>> From: >>> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>> CSeq: 18326 ACK >>> Route: >>> sip:KAMAILIO_FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>> Route: >>> sip:KAMAILIO_FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>> Max-Forwards: 70 >>> User-Agent: Asterisk PBX 13.33.0 >>> Content-Length: 0 >>> >>> >>> By loop I meant, Kamailio just relaying it >>> back to self and discard. >>> >>> Regards, >>> Igor >>> On 07.05.2021 13:48, Daniel-Constantin Mierla >>> wrote: >>>> >>>> Can you paste the ACK that loops, after being >>>> handled once by Kamailio? >>>> >>>> Cheers, >>>> Daniel >>>> >>>> On 07.05.21 13:25, Igor Olhovskiy wrote: >>>>> >>>>> Daniel, >>>>> >>>>> Yes, it is. >>>>> >>>>> alias=... >>>>> >>>>> Also tried with >>>>> >>>>> listen = IP advertise FQDN >>>>> >>>>> same behavior, loose_route() stops acting >>>>> correctly. >>>>> >>>>> PS: Forgot to add, Kamailio 5.4.3 / 5.4.4 >>>>> >>>>> Regards, >>>>> Igor >>>>> On 07.05.2021 13:21, Daniel-Constantin >>>>> Mierla wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> is the KAMAILIO_FQDN set as local domain >>>>>> for Kamailio (via alias parameter or domain >>>>>> module+register myself)? >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> On 07.05.21 11:17, Igor Olhovskiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I saw there are some topics on this >>>>>>> already and carefully walked through all >>>>>>> of them, but can't solve following issue. >>>>>>> >>>>>>> For a reason I do need that in >>>>>>> Record-Route header sent to endpoint would >>>>>>> present FQDN. If it matters, it's UDP/WSS >>>>>>> conversion done on Kamailio. >>>>>>> >>>>>>> So, scheme is quite simple >>>>>>> >>>>>>> Enpoint A ->UDP-> Kamailio ->WSS-> >>>>>>> Endpoint B (NAT) >>>>>>> >>>>>>> Main issue here, that if in Record-Route >>>>>>> headers it's FQDN, but not IP addresses, >>>>>>> on a new transactions with a dialog (ACK >>>>>>> on 200, PRACK, BYE), >>>>>>> Kamailio*loose_route()* function resolves >>>>>>> address of destination not current dialog, >>>>>>> but actual R-URI (or itself, if R-URI is >>>>>>> something from WebRTC world) that is not >>>>>>> correct due to NAT. >>>>>>> >>>>>>> If in RR headers IP addresses are present >>>>>>> - all is working as expected. >>>>>>> >>>>>>> As an example (RR with FQDN) >>>>>>> >>>>>>> B answers 200 >>>>>>> >>>>>>> SIP/2.0 200 OK >>>>>>> Record-Route: >>>>>>> sip:KAMAILIO_FQDN:8089;transport=ws;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>>> Record-Route: >>>>>>> sip:KAMAILIO_FQDN;r2=on;lr=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>>> Via: SIP/2.0/UDP >>>>>>> <A_IP_ADDRESS>:5060;received=A IP >>>>>>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e >>>>>>> To: <sip:88290@<KAMAILIO_FQDN>>;tag=hvra7mj3q0 >>>>>>> From: >>>>>>> <sip:+XXXX7688881@<KAMAILIO_FQDN>>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>>>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>>>>> CSeq: 18326 INVITE >>>>>>> Contact: >>>>>>> sip:88290@toleivu2gdbh.invalid;transport=wss >>>>>>> Allow: >>>>>>> ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER >>>>>>> Supported: outbound >>>>>>> Content-Type: application/sdp >>>>>>> Content-Length: 817 >>>>>>> >>>>>>> >>>>>>> ACK looks like >>>>>>> >>>>>>> ACK >>>>>>> sip:88290@toleivu2gdbh.invalid;transport=wss >>>>>>> SIP/2.0 >>>>>>> Via: SIP/2.0/UDP >>>>>>> A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj8d05548a-91ef-4332-8617-32f8eeebf8f2 >>>>>>> From: >>>>>>> sip:88881@A_IP_ADDRESS;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d >>>>>>> To: sip:88290@KAMAILIO_FQDN;tag=hvra7mj3q0 >>>>>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb >>>>>>> CSeq: 18326 ACK >>>>>>> Route: >>>>>>> sip:FQDN;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>>> Route: >>>>>>> sip:FQDN:8089;transport=ws;lr;r2=on;ftag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d;nat=wss >>>>>>> Max-Forwards: 70 >>>>>>> User-Agent: Asterisk PBX 13.33.0 >>>>>>> Content-Length: 0 >>>>>>> >>>>>>> And Kamailio on *loose_route()* loops ACK >>>>>>> to itself. (with result of function == 1) >>>>>>> >>>>>>> In a case if in Record-Route/Route headers >>>>>>> just IP address of Kamailio present, all >>>>>>> works as expected, but it's not really >>>>>>> behavior I want to achieve. >>>>>>> >>>>>>> I've tried to play with >>>>>>> *record_route_preset("...")* specifying >>>>>>> only WSS part (as suggested in >>>>>>> https://skalatan.de/de/blog/kamailio-sbc-teams >>>>>>> https://skalatan.de/de/blog/kamailio-sbc-teams) >>>>>>> with FQDN, but no luck. >>>>>>> >>>>>>> Also wanted to try approach using >>>>>>> record_route_preset() function in branch >>>>>>> route, but it was working only with first >>>>>>> branch, not affecting others (but I assume >>>>>>> having different RR headers across >>>>>>> branches is not a good idea) >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Igor >>>>>>> >>>>>>> __________________________________________________________ >>>>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>>>> * sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>>>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>>>>> Edit mailing list options or unsubscribe: >>>>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>> -- >>>>>> Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com >>>>>> www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >>>>>> Kamailio Advanced Training - Online >>>>>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >>>>>> * https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ >>>>> >>>>> __________________________________________________________ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> * sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org >>>>> Important: keep the mailing list in the recipients, do not reply only to the sender! >>>>> Edit mailing list options or unsubscribe: >>>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> -- >>>> Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com >>>> www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >>>> Kamailio Advanced Training - Online >>>> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) >>>> * https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/ >> -- >> Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com >> www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda >> Kamailio Advanced Training - Online >> May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>> * https://www.asipto.com/sw/kamailio-advanced-training-online/ https://www.asipto.com/sw/kamailio-advanced-training-online/
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> -- Regards, David Villasmil email: david.villasmil.work@gmail.com <mailto:david.villasmil.work@gmail.com> phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Daniel-Constantin Mierla -
David Villasmil -
Igor Olhovskiy -
Sergiu Pojoga