subject:"Re\: \[SR\-Users\] loose

Re: [SR-Users] loose_route() and FQDN

2021-05-14 Thread Daniel-Constantin Mierla

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/02240711239149e2f5c4890a70ab158d10fa8187/src/modules/siputils/sipops.c#L183
>>
>>         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
>>> 
>>>
>>> On Fri, May 7, 2021 at 7:22 PM David Villasmil
>>> >> > wrote:
>>>
>>>
>>> Can you share a trace?
>>>
>>> On Fri, 7 May 2021 at 21:12, Igor Olhovskiy
>>> mailto:igorolhovs...@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.w...@gmail.com
 
 phone: +34669448337


 On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy
 mailto:igorolhovs...@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
>  > 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".

Re: [SR-Users] loose_route() and FQDN

2021-05-13 Thread Igor Olhovskiy


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/02240711239149e2f5c4890a70ab158d10fa8187/src/modules/siputils/sipops.c#L183

        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 



On Fri, May 7, 2021 at 7:22 PM David Villasmil 
> wrote:



Can you share a trace?

On Fri, 7 May 2021 at 21:12, Igor Olhovskiy
mailto:igorolhovs...@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.w...@gmail.com

phone: +34669448337


On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy
mailto:igorolhovs...@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
mailto:igorolhovs...@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:

;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0

Re: [SR-Users] loose_route() and FQDN

2021-05-10 Thread Igor Olhovskiy


Sergiu,

Actually, yes

Problem is in order of checking in this function

https://github.com/kamailio/kamailio/blob/02240711239149e2f5c4890a70ab158d10fa8187/src/modules/siputils/sipops.c#L183

        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 



On Fri, May 7, 2021 at 7:22 PM David Villasmil 
> wrote:



Can you share a trace?

On Fri, 7 May 2021 at 21:12, Igor Olhovskiy
mailto:igorolhovs...@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.w...@gmail.com

phone: +34669448337


On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy
mailto:igorolhovs...@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
mailto:igorolhovs...@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:

;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route:


Route:


Max-Forwards: 70
User-Agent: Asterisk PBX 13.33.0
Content-Length:  0

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Sergiu Pojoga

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.w...@gmail.com> wrote:

>
> Can you share a trace?
>
> On Fri, 7 May 2021 at 21:12, Igor Olhovskiy 
> 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.w...@gmail.com
>> phone: +34669448337
>>
>>
>> On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy 
>> 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 
>>> 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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
 To: ;tag=hvra7mj3q0
 Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
 CSeq: 18326 ACK
 Route:

 Route:

 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,

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread David Villasmil

Can you share a trace?

On Fri, 7 May 2021 at 21:12, Igor Olhovskiy  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.w...@gmail.com
> phone: +34669448337
>
>
> On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy 
> 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 
>> 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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
>>> To: ;tag=hvra7mj3q0
>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
>>> CSeq: 18326 ACK
>>> Route:
>>> 
>>> Route:
>>> 
>>> 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:
>>> 
>>> Record-Route:
>>> 
>>> Via: SIP/2.0/UDP :5060;received=A IP
>>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
>>> To:

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy


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.w...@gmail.com 


phone: +34669448337


On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy > 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
mailto:igorolhovs...@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:
;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route:


Route:


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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread David Villasmil

Have you tried verifying Kamailio actually believes the FQDN is itself?

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Fri, May 7, 2021 at 4:18 PM Igor Olhovskiy 
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 
> 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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
>> To: ;tag=hvra7mj3q0
>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
>> CSeq: 18326 ACK
>> Route:
>> 
>> Route:
>> 
>> 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:
>> 
>> Record-Route:
>> 
>> Via: SIP/2.0/UDP :5060;received=A IP
>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
>> To: >;tag=hvra7mj3q0
>> From: > >;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
>> CSeq: 18326 INVITE
>> Contact: 
>> 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:

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy


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 > 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:
;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route:


Route:


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:


Record-Route:


Via: SIP/2.0/UDP :5060;received=A IP
ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
To: >;tag=hvra7mj3q0
From:
>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 INVITE
Contact: 
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:
;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread David Villasmil

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  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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> To: ;tag=hvra7mj3q0
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 ACK
> Route:
> 
> Route:
> 
> 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:
> 
> Record-Route:
> 
> Via: SIP/2.0/UDP :5060;received=A IP
> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
> To: >;tag=hvra7mj3q0
> From:  >;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 INVITE
> Contact: 
> 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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> To: ;tag=hvra7mj3q0
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 ACK
> Route:
> 
> Route:
> 
> 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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy


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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 


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: 

Record-Route: 

Via: SIP/2.0/UDP :5060;received=A IP 
ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e

To: >;tag=hvra7mj3q0
From: 
>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 INVITE
Contact: 
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: 
;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 


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:

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy


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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 


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: 

Record-Route: 

Via: SIP/2.0/UDP :5060;received=A IP 
ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e

To: >;tag=hvra7mj3q0
From: 
>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 INVITE
Contact: 
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: 
;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 


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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Daniel-Constantin Mierla

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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> To: ;tag=hvra7mj3q0
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 ACK
> Route:
> 
> Route:
> 
> 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:
> 
> Record-Route:
> 
> Via: SIP/2.0/UDP :5060;received=A IP
> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
> To: >;tag=hvra7mj3q0
> From:
> >;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 INVITE
> Contact: 
> 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:
> ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> To: ;tag=hvra7mj3q0
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 ACK
> Route:
> 
> Route:
> 
> 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 -

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy

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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 

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: 

Record-Route: 

Via: SIP/2.0/UDP :5060;received=A IP 
ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e

To: >;tag=hvra7mj3q0
From: 
>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 INVITE
Contact: 
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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 

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/
__
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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Daniel-Constantin Mierla

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:
>>> 
>>> Record-Route:
>>> 
>>> Via: SIP/2.0/UDP :5060;received=A IP
>>> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
>>> To: >;tag=hvra7mj3q0
>>> From:
>>> >;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
>>> CSeq: 18326 INVITE
>>> Contact: 
>>> 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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
>>> To: ;tag=hvra7mj3q0
>>> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
>>> CSeq: 18326 ACK
>>> Route:
>>> 
>>> Route:
>>> 
>>> 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/

__
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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy


Just made another test with TLS, not WSS. Same behavior

A -> Kamailio -> B


INVITE sip:2@KAMAILIO_FQDN:5060 SIP/2.0
Via: SIP/2.0/UDP 
A_IP_ADDRESS:5060;rport;branch=z9hG4bKPj84577fd7-611e-40ce-b095-835583310eab

From: ;tag=62ce37c8-b186-40d9-ae88-31321338031d
To: 
Contact: 
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: 
;tag=62ce37c8-b186-40d9-ae88-31321338031d

To: "TEST 2" ;tag=5AE57984-651CED77
CSeq: 597 INVITE
Call-ID: 8c9f68bf-1514-4dfa-8ba0-72cd8922a22b
Contact: 
Record-Route: 
, 


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:2@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: ;tag=62ce37c8-b186-40d9-ae88-31321338031d
To: ;tag=5AE57984-651CED77
Call-ID: 8c9f68bf-1514-4dfa-8ba0-72cd8922a22b
CSeq: 598 PRACK
Route: 

Route: 


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: 

Record-Route: 

Via: SIP/2.0/UDP :5060;received=A IP 
ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e

To: >;tag=hvra7mj3q0
From: 
>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 INVITE
Contact: 
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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 


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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Igor Olhovskiy


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: 

Record-Route: 

Via: SIP/2.0/UDP :5060;received=A IP 
ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e

To: >;tag=hvra7mj3q0
From: 
>;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d

Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 INVITE
Contact: 
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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
To: ;tag=hvra7mj3q0
Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
CSeq: 18326 ACK
Route: 

Route: 


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

Re: [SR-Users] loose_route() and FQDN

2021-05-07 Thread Daniel-Constantin Mierla

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:
> 
> Record-Route:
> 
> Via: SIP/2.0/UDP :5060;received=A IP
> ADDRESS;rport=5060;branch=z9hG4bKPj67fb6d86-97d7-4231-995b-e54b0f62881e
> To: >;tag=hvra7mj3q0
> From:
> >;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 INVITE
> Contact: 
> 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: ;tag=0a3e31a6-96ad-42d0-9310-81b35cedbd3d
> To: ;tag=hvra7mj3q0
> Call-ID: 46f44741-d155-4dd5-8fd8-78e540fc1acb
> CSeq: 18326 ACK
> Route:
> 
> Route:
> 
> 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

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

Re: [SR-Users] loose_route() and FQDN

17 matches

Site Navigation

Mail list logo

Footer information