Re: [SR-Users] SECSIPID Identity Decode

2021-06-30 Thread Daniel W. Graham
Here is an example, payload taken from Identity header.

Identity was added with secsipid_add_identity

Payload test:
$var(test) = 
"eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6I5ODkyODkyMjgwIl19LCJpYXQiOjE2MjUxMDk2MzQsIm9yaWciOnsidG4iOiI5ODk0MDA0MjMwIn0sIm9yaWdpZCI6IjNmYmE4NTg0LTRkNzMtNGU2NC04NDc5LTQ5MjU2ZGIyMWFhYSJ9";
xlogl("L_WARN", "$(var(test){s.decode.base64t})\n");

Result is:
{"attest":"A","dest":{"tn":#���#��##�#002%���&�#027B#�#023c#S#023#003�#023sB�&�&�r#��'F�#�#���C#003#003C#3#002'��&�&�v�B#�Vc�s#006f"�&6#026#022�CVCB�#023c3#022�3#0066#�#026#6#026S�r'

-dan


From: sr-users  on behalf of Daniel Graham 

Reply-To: "Kamailio (SER) - Users Mailing List" 
Date: Wednesday, June 30, 2021 at 5:32 PM
To: David Villasmil , "mico...@gmail.com" 
, "Kamailio (SER) - Users Mailing List" 

Subject: Re: [SR-Users] SECSIPID Identity Decode

That’s the same way I am doing it, I was just trying to do a verification that 
the identity header/payload was correct before activating new changes.

I will do further testing and share results. Just found it odd that the header 
would decode but payload wouldn’t.

Daniel W. Graham, CTO
CMSInter.net LLC
DIRECT (989) 400-4230

INTERNET | TELEPHONE | MANAGED IT


From: David Villasmil 
Date: Wednesday, June 30, 2021 at 4:06 PM
To: "mico...@gmail.com" , "Kamailio (SER) - Users Mailing 
List" 
Cc: Daniel Graham 
Subject: Re: [SR-Users] SECSIPID Identity Decode

I DO IT WITH:

# Break JWT
$var(jwt1) = $(hdr(Identity){s.select,0,.}{s.decode.base64t});
$var(jwt2) = $(hdr(Identity){s.select,1,.}{s.decode.base64t});


Regards,

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


On Wed, Jun 30, 2021 at 8:48 PM Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:

Hello,

not familiar with python functions, have you tried with Kamailio transformation?

https://www.kamailio.org/wiki/cookbooks/5.5.x/transformations#sdecodebase64url

Maybe you have to specify in Python that it is ASCII, I remember I had to do 
decoding when porting kamcli to work with Python3 -- had to change from using 
directly the variables received as parameter to a decoded value, something like:

prefix = tprefix.encode("ascii", "ignore").decode()

Also, if you can, share the identity header here to test with and see if can be 
reproduced.

Cheers,
Daniel
On 30.06.21 21:14, Daniel W. Graham wrote:
I am unable to base64url decode the json payload in identity header generated 
by secsipid.

(Using python for test)
decoded_payload = url64.decode(‘payload’)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 27: 
invalid continuation byte

Header decodes fine this way but not payload.

Is this an issue with the payload encoding?

Kamailio 5.5

Daniel W. Graham, CTO
CMSInter.net LLC
DIRECT (989) 400-4230

INTERNET | TELEPHONE | MANAGED IT





__

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 - 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
__
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] SECSIPID Identity Decode

2021-06-30 Thread Daniel W. Graham
That’s the same way I am doing it, I was just trying to do a verification that 
the identity header/payload was correct before activating new changes.

I will do further testing and share results. Just found it odd that the header 
would decode but payload wouldn’t.

Daniel W. Graham, CTO
CMSInter.net LLC
DIRECT (989) 400-4230

INTERNET | TELEPHONE | MANAGED IT


From: David Villasmil 
Date: Wednesday, June 30, 2021 at 4:06 PM
To: "mico...@gmail.com" , "Kamailio (SER) - Users Mailing 
List" 
Cc: Daniel Graham 
Subject: Re: [SR-Users] SECSIPID Identity Decode

I DO IT WITH:

# Break JWT
$var(jwt1) = $(hdr(Identity){s.select,0,.}{s.decode.base64t});
$var(jwt2) = $(hdr(Identity){s.select,1,.}{s.decode.base64t});


Regards,

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


On Wed, Jun 30, 2021 at 8:48 PM Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:

Hello,

not familiar with python functions, have you tried with Kamailio transformation?

https://www.kamailio.org/wiki/cookbooks/5.5.x/transformations#sdecodebase64url

Maybe you have to specify in Python that it is ASCII, I remember I had to do 
decoding when porting kamcli to work with Python3 -- had to change from using 
directly the variables received as parameter to a decoded value, something like:

prefix = tprefix.encode("ascii", "ignore").decode()

Also, if you can, share the identity header here to test with and see if can be 
reproduced.

Cheers,
Daniel
On 30.06.21 21:14, Daniel W. Graham wrote:
I am unable to base64url decode the json payload in identity header generated 
by secsipid.

(Using python for test)
decoded_payload = url64.decode(‘payload’)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 27: 
invalid continuation byte

Header decodes fine this way but not payload.

Is this an issue with the payload encoding?

Kamailio 5.5

Daniel W. Graham, CTO
CMSInter.net LLC
DIRECT (989) 400-4230

INTERNET | TELEPHONE | MANAGED IT




__

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 - 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
__
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] SECSIPID Identity Decode

2021-06-30 Thread David Villasmil
I DO IT WITH:

# Break JWT
$var(jwt1) = $(hdr(Identity){s.select,0,.}{s.decode.base64t});
$var(jwt2) = $(hdr(Identity){s.select,1,.}{s.decode.base64t});


Regards,

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


On Wed, Jun 30, 2021 at 8:48 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> not familiar with python functions, have you tried with Kamailio
> transformation?
>
>
> https://www.kamailio.org/wiki/cookbooks/5.5.x/transformations#sdecodebase64url
>
> Maybe you have to specify in Python that it is ASCII, I remember I had to
> do decoding when porting kamcli to work with Python3 -- had to change from
> using directly the variables received as parameter to a decoded value,
> something like:
>
> prefix = tprefix.encode("ascii", "ignore").decode()
>
> Also, if you can, share the identity header here to test with and see if
> can be reproduced.
>
> Cheers,
> Daniel
> On 30.06.21 21:14, Daniel W. Graham wrote:
>
> I am unable to base64url decode the json payload in identity header
> generated by secsipid.
>
>
>
> (Using python for test)
>
> decoded_payload = url64.decode(‘payload’)
>
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 27:
> invalid continuation byte
>
>
>
> Header decodes fine this way but not payload.
>
>
>
> Is this an issue with the payload encoding?
>
>
>
> Kamailio 5.5
>
>
>
> Daniel W. Graham, CTO
>
> CMSInter.net LLC
>
> DIRECT (989) 400-4230
>
>
>
> INTERNET | TELEPHONE | MANAGED IT
>
>
>
> __
> 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.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
>
> __
> 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
>
__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Juha Heinanen
Shahid Hussain writes:

> Following are  the REGISTER and response messages. Is it possible to
> confirm the JSSIP client has full implementation of SIP outbound?

Looks like it if you define two sockets.

-- Juha

__
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] install stirshaken module by apt at Debian 10

2021-06-30 Thread Daniel-Constantin Mierla
Hello,

not all the modules are packaged on a distro because they may depend on
libraries not available in that distro.

It is also the case here, the stirshaken module depends on
libstirshaken, which is not available on debian.

Same is with secsipid module, which also offers STIR/SHAKEN features, it
depends on libsecsipid.

Victor Seva started packaging libsecsipid, might become available in the
next Debian stable (11), although it might be an older version that
latest libsecsipid -- probably some backports can be done once Debian 11
is release, not it is in hard freeze, afaik.

Practically, in this case you have to compile it yourself, or make a
build system to create the debs by yourself (e.g., using docker).

Cheers,
Daniel

On 30.06.21 17:37, Yuriy Nasida wrote:
> Hi,
>
> I know that it's possible to compile manually but what about apt
> method to install stirshaken module?
>
> I am checking the list of modules using:
> apt search kamailio
>
> But... Nothing looks like stirshaken. 
>
> Thus, only several modules available and for others we should compile
> manually ?
>
> Please advise
> Thanks
>
>
>
> __
> 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 - 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] Fwd: Possible memory leak on 5.5.x (new)?

2021-06-30 Thread Daniel-Constantin Mierla
Hello,

for the sake of completion: the autoexpire should clean the items if
they are not used during the expiration interval. If you want to get
them deleted after first expiration interval always, see the
updateexpire attribute for htable modparam.

Also, note that replication should be done only between Kamailio
instances with same major version, because there can be internal
differences between major versions that can lead to unexpected
behaviour. In other words, if you replicate, doing between two kamailio
with version 5.5.x or between two kamailio with version 5.4.x, but not
between a kamailkio 5.5.x and a kamailio 5.4.x.

The total amount of used memory in the stats file for 5.5 does not seem
to be high as a rough estimation. The highest by module is in htable,
but it is around 20MB. Maybe you took the stats too early, quickly after
a restart?

Cheers,
Daniel

On 30.06.21 17:20, George Diamantopoulos wrote:
> Hello Daniel,
>
> Thanks for the feedback. I think I might have been too quick to blame
> htable for this behaviour. In fact, version 5.4 seems to consume more
> memory than 5.5 (175129776 bytes vs 20581096), which makes sense since
> it has been running for longer (I missed the extra digit previously).
>
> So I'm not sure htable is to blame. On the other hand, I don't see any
> other modules using up too much of shmem either, so maybe memory stats
> can't provide the answer here?
>
> To answer your question, though, I do use DMQ and both tables that use
> it have autoexpire set to the same value on both 5.4 and 5.5:
>
> /etc/kamailio# grep dmq kamailio-module-params.cfg
> modparam("dmq", "server_address", "sip:172.30.43.1:5090
> ")
> modparam("dmq", "notification_address",
> "sip:dmq.services.mydomain.com:5090
> ")
> modparam("dmq", "multi_notify", 1)
> modparam("htable", "enable_dmq", 1)
> modparam("htable", "htable",
> 'cid2hi=>size=8;autoexpire=600;dmqreplicate=1')
> modparam("htable", "htable",
> 'xcid2count=>size=8;autoexpire=600;dmqreplicate=1')
>
> On Wed, 30 Jun 2021 at 17:43, Daniel-Constantin Mierla
> mailto:mico...@gmail.com>> wrote:
>
> Hello,
>
> do you replicate items in the htable via dmq? Does the htable have
> autoexpire value set?
>
> Cheers,
> Daniel
>
> On 30.06.21 13:54, George Diamantopoulos wrote:
>> Forwarding my reply to the list, using gmail's reply button set
>> Henning as the sole recipient :-\
>>
>> -- Forwarded message -
>> From: *George Diamantopoulos* > >
>> Date: Sat, 26 Jun 2021 at 02:25
>> Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
>> To: Henning Westerholt mailto:h...@skalatan.de>>
>>
>>
>> Hello Henning,
>>
>> Thanks for your reply. Here's what has come up after a few hours:
>>
>> shm55: https://pastebin.com/h9JCePmc 
>> shm54: https://pastebin.com/Nx5xEEnA 
>>
>> It seems to me htable is the culprit? Are you seeing anything
>> different? 54 has been running for 77020 seconds, 55 for 28521
>> (significantly less).
>>
>> I'm going to turn it off until we figure something out...
>>
>> BR,
>> George
>>
>> On Fri, 25 Jun 2021 at 18:17, Henning Westerholt > > wrote:
>>
>> Hello,
>>
>>  
>>
>> Good observation. Please run the memory statistics CLI
>> commands to get more hints about the module that might cause
>> it (as per below link). Then please report more details. If
>> you can point to a particular module, you can also open an
>> issue on our tracker.
>>
>>  
>>
>> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>> 
>>
>>  
>>
>> Cheers,
>>
>>  
>>
>> Henning
>>
>>  
>>
>> *From:* sr-users > > *On Behalf Of
>> *George Diamantopoulos
>> *Sent:* Friday, June 25, 2021 4:53 PM
>> *To:* Kamailio (SER) - Users Mailing List
>> > >
>> *Subject:* [SR-Users] Possible memory leak on 5.5.x (new)?
>>
>>  
>>
>> Hello all,
>>
>>  
>>
>> I'm still investigating the (most likely
>> non-kamailio-related) memory leak of my previous message to
>> the list, there have been no developments so far. I'll update
>> if anything changes.
>>
>>  
>>
>> This concerns a new finding which seems to affect kamailio
>> 5.5.x. I have two kamailio instances receiving the same
>> traffic via round-robin. I upgraded only one of them to 5.5.1
>> and left the other to 5.4.6 as I feared of any issues
>> arising. I was lucky to do so, because 

[SR-Users] install stirshaken module by apt at Debian 10

2021-06-30 Thread Yuriy Nasida
Hi,

I know that it's possible to compile manually but what about apt method to
install stirshaken module?

I am checking the list of modules using:
apt search kamailio

But... Nothing looks like stirshaken.

Thus, only several modules available and for others we should compile
manually ?

Please advise
Thanks
__
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] Fwd: Possible memory leak on 5.5.x (new)?

2021-06-30 Thread George Diamantopoulos
Hello Daniel,

Thanks for the feedback. I think I might have been too quick to blame
htable for this behaviour. In fact, version 5.4 seems to consume more
memory than 5.5 (175129776 bytes vs 20581096), which makes sense since it
has been running for longer (I missed the extra digit previously).

So I'm not sure htable is to blame. On the other hand, I don't see any
other modules using up too much of shmem either, so maybe memory stats
can't provide the answer here?

To answer your question, though, I do use DMQ and both tables that use it
have autoexpire set to the same value on both 5.4 and 5.5:

/etc/kamailio# grep dmq kamailio-module-params.cfg
modparam("dmq", "server_address", "sip:172.30.43.1:5090")
modparam("dmq", "notification_address", "sip:dmq.services.mydomain.com:5090")

modparam("dmq", "multi_notify", 1)
modparam("htable", "enable_dmq", 1)
modparam("htable", "htable",
'cid2hi=>size=8;autoexpire=600;dmqreplicate=1')
modparam("htable", "htable",
'xcid2count=>size=8;autoexpire=600;dmqreplicate=1')

On Wed, 30 Jun 2021 at 17:43, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> do you replicate items in the htable via dmq? Does the htable have
> autoexpire value set?
>
> Cheers,
> Daniel
> On 30.06.21 13:54, George Diamantopoulos wrote:
>
> Forwarding my reply to the list, using gmail's reply button set Henning as
> the sole recipient :-\
>
> -- Forwarded message -
> From: George Diamantopoulos 
> Date: Sat, 26 Jun 2021 at 02:25
> Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
> To: Henning Westerholt 
>
>
> Hello Henning,
>
> Thanks for your reply. Here's what has come up after a few hours:
>
> shm55: https://pastebin.com/h9JCePmc
> shm54: https://pastebin.com/Nx5xEEnA
>
> It seems to me htable is the culprit? Are you seeing anything different?
> 54 has been running for 77020 seconds, 55 for 28521 (significantly less).
>
> I'm going to turn it off until we figure something out...
>
> BR,
> George
>
> On Fri, 25 Jun 2021 at 18:17, Henning Westerholt  wrote:
>
>> Hello,
>>
>>
>>
>> Good observation. Please run the memory statistics CLI commands to get
>> more hints about the module that might cause it (as per below link). Then
>> please report more details. If you can point to a particular module, you
>> can also open an issue on our tracker.
>>
>>
>>
>> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Henning
>>
>>
>>
>> *From:* sr-users  *On Behalf Of *George
>> Diamantopoulos
>> *Sent:* Friday, June 25, 2021 4:53 PM
>> *To:* Kamailio (SER) - Users Mailing List 
>> *Subject:* [SR-Users] Possible memory leak on 5.5.x (new)?
>>
>>
>>
>> Hello all,
>>
>>
>>
>> I'm still investigating the (most likely non-kamailio-related) memory
>> leak of my previous message to the list, there have been no developments so
>> far. I'll update if anything changes.
>>
>>
>>
>> This concerns a new finding which seems to affect kamailio 5.5.x. I have
>> two kamailio instances receiving the same traffic via round-robin. I
>> upgraded only one of them to 5.5.1 and left the other to 5.4.6 as I feared
>> of any issues arising. I was lucky to do so, because with identical
>> configuration, 5.5.x seems to run out of SHM very quickly. Here are links
>> to graphs produced by our monitoring system:
>>
>>
>>
>> Old kamailio (no memory leak): https://pasteboard.co/K8fVBiD.png
>>
>> New kamailio (possible leak): https://pasteboard.co/K8fVS9N.png
>>
>>
>>
>> The configuration uses mtree, htable, vars and vns extensively. Has
>> anyone come across anything similar? Let me know if I can provide any
>> further information to help disect this. Thanks!
>>
>>
>>
>> BR,
>>
>> George
>>
>
> __
> 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.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
>
>
__
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] Fwd: Possible memory leak on 5.5.x (new)?

2021-06-30 Thread Daniel-Constantin Mierla
Hello,

do you replicate items in the htable via dmq? Does the htable have
autoexpire value set?

Cheers,
Daniel

On 30.06.21 13:54, George Diamantopoulos wrote:
> Forwarding my reply to the list, using gmail's reply button set
> Henning as the sole recipient :-\
>
> -- Forwarded message -
> From: *George Diamantopoulos*  >
> Date: Sat, 26 Jun 2021 at 02:25
> Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
> To: Henning Westerholt mailto:h...@skalatan.de>>
>
>
> Hello Henning,
>
> Thanks for your reply. Here's what has come up after a few hours:
>
> shm55: https://pastebin.com/h9JCePmc 
> shm54: https://pastebin.com/Nx5xEEnA 
>
> It seems to me htable is the culprit? Are you seeing anything
> different? 54 has been running for 77020 seconds, 55 for 28521
> (significantly less).
>
> I'm going to turn it off until we figure something out...
>
> BR,
> George
>
> On Fri, 25 Jun 2021 at 18:17, Henning Westerholt  > wrote:
>
> Hello,
>
>  
>
> Good observation. Please run the memory statistics CLI commands to
> get more hints about the module that might cause it (as per below
> link). Then please report more details. If you can point to a
> particular module, you can also open an issue on our tracker.
>
>  
>
> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
> 
>
>  
>
> Cheers,
>
>  
>
> Henning
>
>  
>
> *From:* sr-users  > *On Behalf Of
> *George Diamantopoulos
> *Sent:* Friday, June 25, 2021 4:53 PM
> *To:* Kamailio (SER) - Users Mailing List
> mailto:sr-users@lists.kamailio.org>>
> *Subject:* [SR-Users] Possible memory leak on 5.5.x (new)?
>
>  
>
> Hello all,
>
>  
>
> I'm still investigating the (most likely non-kamailio-related)
> memory leak of my previous message to the list, there have been no
> developments so far. I'll update if anything changes.
>
>  
>
> This concerns a new finding which seems to affect kamailio 5.5.x.
> I have two kamailio instances receiving the same traffic via
> round-robin. I upgraded only one of them to 5.5.1 and left the
> other to 5.4.6 as I feared of any issues arising. I was lucky to
> do so, because with identical configuration, 5.5.x seems to run
> out of SHM very quickly. Here are links to graphs produced by our
> monitoring system:
>
>  
>
> Old kamailio (no memory leak): https://pasteboard.co/K8fVBiD.png
> 
>
> New kamailio (possible leak): https://pasteboard.co/K8fVS9N.png
> 
>
>  
>
> The configuration uses mtree, htable, vars and vns extensively.
> Has anyone come across anything similar? Let me know if I can
> provide any further information to help disect this. Thanks!
>
>  
>
> BR,
>
> George
>
>
> __
> 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 - 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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Juha Heinanen
Due to other tests, I had missed baresip account's ;outbound paramater.
Once I added it, also reg-id was added.

-- Juha

WSS 192.168.43.160:50442 -> 192.168.43.160:5061
REGISTER sip:test.tutpro.com SIP/2.0
Via: SIP/2.0/WSS 127.0.0.1:9;branch=z9hG4bK5a4ad01f9164d358;rport
Contact: 
;expires=30;+sip.instance="";q=0.5;reg-id=1
Max-Forwards: 70
Route: 
To: 
From: "Test Account" ;tag=904f27750c59fc5b
Call-ID: 69f4eea174d327eb
CSeq: 29225 REGISTER
User-Agent: baresip v1.1.0 (x86_64/linux)
Supported: gruu, outbound, path
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER
Content-Length: 0

__
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


[SR-Users] Kamailio + RTPEngine - Destinations Behind NAT

2021-06-30 Thread Edward Romanenco
Hi everyone,

I'm using Kamailio (Ver 5.5.1, Public IP X.X.X.11, Private IP 172.18.0.20) + 
RTPEngine (Ver 9.4.1.1, Public IP X.X.X.7, Private IP 172.18.0.50) alongside 
Freeswitch (Private IP 172.18.0.40) in my backend and delivering calls to a 
mobile application (call flow is Freeswitch -> Kamailio + RTPEngine -> 
Applicaiton). While calls made to NATted destination generally works fine - 
from time to time, we've experiencing one-sided audio due to the rtpengine 
sending the media stream to the remote end's private IP instead of his public 
one. For instance, in the attached logs - media was sent towards 192.168.1.93 
instead of 79.179.1.2, which is the expected destination. Problem appears 
almost randomly; I can make 20 fine calls in a row for the same destination 
until experiencing it, and I didn't find any difference as it comes to the SIP 
invite exchange between the two. Has anyone ever experienced the same behavior 
and can share some general instructions on how to troubleshoot it?

Relevant Kamailio config section is attached.

Invite Kamailio->Device

INVITE sip:972587102881@79.179.1.2:56308;transport=TLS;ob SIP/2.0
Record-Route: 
Record-Route: 
Via: SIP/2.0/TLS 
X.X.X.11:443;branch=z9hG4bK24bf.52b1dd68e26010ba103bd8d6fdb53cf4.0
Via: SIP/2.0/UDP 
172.18.0.40;received=172.18.0.40;rport=5060;branch=z9hG4bKH234Q58HpHNKK
Max-Forwards: 66
From: "972522149596" ;tag=cvcHy5UcS9pjj
To: 
Call-ID: be55bd1e-537d-123a-65a9-0242ac120028
CSeq: 37932220 INVITE
Contact: 

User-Agent: 
FreeSWITCH-mod_sofia/1.10.6-release+git~20210325T131609Z~1ff9d0a60e~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, 
REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 567
X-SESSION-ID: 721533765
X-INCOMING: PSTN
X-from-freeswitch: +972522149596
X-FS-Support: update_display,send_info
Remote-Party-ID: "972522149596" 
;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1624937621 1624937622 IN IP4 X.X.X.7
s=FreeSWITCH
c=IN IP4 X.X.X.7
t=0 0
m=audio 30018 RTP/AVP 102 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=3; maxplaybackrate=48000; 
ptime=20; minptime=10; maxptime=40
a=rtpmap:101 telephone-event/48000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:30019
a=ptime:20
a=ice-ufrag:bKPZt0dW
a=ice-pwd:H4qyL7mPUOvoiAjosiLasXAdzj
a=candidate:41sXGEsTafxHi8ms 1 UDP 2130706431 X.X.X.7 30018 typ host
a=candidate:41sXGEsTafxHi8ms 2 UDP 2130706430 X.X.X.7 30019 typ host

Response Device->Kamailio

SIP/2.0 200 OK
Via: SIP/2.0/TLS 
X.X.X.11:443;received=X.X.X.11;branch=z9hG4bK24bf.52b1dd68e26010ba103bd8d6fdb53cf4.0
Via: SIP/2.0/UDP 
172.18.0.40;rport=5060;received=172.18.0.40;branch=z9hG4bKH234Q58HpHNKK
Record-Route: 
Record-Route: 
Call-ID: be55bd1e-537d-123a-65a9-0242ac120028
From: "972522149596" ;tag=cvcHy5UcS9pjj
To: ;tag=5f75877e-58c2-44f3-a5b3-43f8786c42a1
CSeq: 37932220 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS
Contact: 
Supported: replaces, 100rel, timer, norefersub
Content-Type: application/sdp
Content-Length:   348

v=0
o=- 3833960833 3833960834 IN IP4 192.168.1.93
s=pjmedia
b=AS:117
t=0 0
a=X-nat:0
m=audio 4002 RTP/AVP 96 120
c=IN IP4 192.168.1.93
b=TIAS:96000
a=rtcp:4003 IN IP4 192.168.1.93
a=sendrecv
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:120 telephone-event/48000
a=fmtp:120 0-16
a=ssrc:816694098 cname:72cdb5f53fc2e8fb

Kamailio NAT Detect/Manage Routes


# Caller NAT detection

route[NATDETECT] {
#!ifdef WITH_NAT
xinfo("NATDETECT: Adding the rport parameter to the first Via header of the 
received message\n");
   force_rport();
   xinfo("NATDETECT: Trying to guess if client's request originated behind a 
nat. Testing 19.\n");
   if (nat_uac_test("19")) {
  if (is_method("REGISTER")) {
  xinfo("NATDETECT: REGISTER request. Creating a URI consisting of the 
source IP, port, and protocol and storing the URI in an 
Attribute-Value-Pair.\n");
 fix_nated_register();
  } else {
 if(is_first_hop()) {
 xinfo("NATDETECT: Adding an ;alias=ip~port~transport parameter to 
the contact URI containing the received ip, port, and transport protocol.\n");
set_contact_alias();
 }
  }
   xinfo("NATDETECT: Setting flag FLT_NATS.\n");
  setflag(FLT_NATS);
   } else {
   xinfo("NATDETECT: Didn't detect natted request by any of the given 
heuristics\n");
   }
#!endif
   return;
}

# RTPProxy control and signaling updates for NAT traversal
route[NATMANAGE] {
#!ifdef WITH_NAT
   if (is_request()) {
  if(has_totag()) {
 if(check_route_param("nat=yes")) {
xinfo("NATMANAGE: This is a request with to-tag that has 'nat=yes', 
setting branch flag FLB_NATB.\n");
setbflag(FLB_NATB);
 }
  }
   }

   if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) {
   xinfo("NATMANAGE: No 

[SR-Users] Kamailio + RTPEngine - Destinations Behind NAT

2021-06-30 Thread Edward Romanenco
Hi everyone,

I'm using Kamailio (Ver 5.5.1, Public IP X.X.X.11, Private IP 172.18.0.20) + 
RTPEngine (Ver 9.4.1.1, Public IP X.X.X.7, Private IP 172.18.0.50) alongside 
Freeswitch (Private IP 172.18.0.40) in my backend and delivering calls to a 
mobile application (call flow is Freeswitch -> Kamailio + RTPEngine -> 
Applicaiton). While calls made to NATted destination generally works fine - 
from time to time, we've experiencing one-sided audio due to the rtpengine 
sending the media stream to the remote end's private IP instead of his public 
one. For instance, in the attached logs - media was sent towards 192.168.1.93 
instead of 79.179.1.2, which is the expected destination. Problem appears 
almost randomly; I can make 20 fine calls in a row for the same destination 
until experiencing it, and I didn't find any difference as it comes to the SIP 
invite exchange between the two. Has anyone ever experienced the same behavior 
and can share some general instructions on how to troubleshoot it?

Relevant Kamailio config section is attached.

Invite Kamailio->Device

INVITE sip:972587102881@79.179.1.2:56308;transport=TLS;ob SIP/2.0
Record-Route: 
Record-Route: 
Via: SIP/2.0/TLS 
X.X.X.11:443;branch=z9hG4bK24bf.52b1dd68e26010ba103bd8d6fdb53cf4.0
Via: SIP/2.0/UDP 
172.18.0.40;received=172.18.0.40;rport=5060;branch=z9hG4bKH234Q58HpHNKK
Max-Forwards: 66
From: "972522149596" ;tag=cvcHy5UcS9pjj
To: 
Call-ID: be55bd1e-537d-123a-65a9-0242ac120028
CSeq: 37932220 INVITE
Contact: 

User-Agent: 
FreeSWITCH-mod_sofia/1.10.6-release+git~20210325T131609Z~1ff9d0a60e~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, 
REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 567
X-SESSION-ID: 721533765
X-INCOMING: PSTN
X-from-freeswitch: +972522149596
X-FS-Support: update_display,send_info
Remote-Party-ID: "972522149596" 
;party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1624937621 1624937622 IN IP4 X.X.X.7
s=FreeSWITCH
c=IN IP4 X.X.X.7
t=0 0
m=audio 30018 RTP/AVP 102 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=3; maxplaybackrate=48000; 
ptime=20; minptime=10; maxptime=40
a=rtpmap:101 telephone-event/48000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:30019
a=ptime:20
a=ice-ufrag:bKPZt0dW
a=ice-pwd:H4qyL7mPUOvoiAjosiLasXAdzj
a=candidate:41sXGEsTafxHi8ms 1 UDP 2130706431 X.X.X.7 30018 typ host
a=candidate:41sXGEsTafxHi8ms 2 UDP 2130706430 X.X.X.7 30019 typ host

Response Device->Kamailio

SIP/2.0 200 OK
Via: SIP/2.0/TLS 
X.X.X.11:443;received=X.X.X.11;branch=z9hG4bK24bf.52b1dd68e26010ba103bd8d6fdb53cf4.0
Via: SIP/2.0/UDP 
172.18.0.40;rport=5060;received=172.18.0.40;branch=z9hG4bKH234Q58HpHNKK
Record-Route: 
Record-Route: 
Call-ID: be55bd1e-537d-123a-65a9-0242ac120028
From: "972522149596" ;tag=cvcHy5UcS9pjj
To: ;tag=5f75877e-58c2-44f3-a5b3-43f8786c42a1
CSeq: 37932220 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS
Contact: 
Supported: replaces, 100rel, timer, norefersub
Content-Type: application/sdp
Content-Length:   348

v=0
o=- 3833960833 3833960834 IN IP4 192.168.1.93
s=pjmedia
b=AS:117
t=0 0
a=X-nat:0
m=audio 4002 RTP/AVP 96 120
c=IN IP4 192.168.1.93
b=TIAS:96000
a=rtcp:4003 IN IP4 192.168.1.93
a=sendrecv
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:120 telephone-event/48000
a=fmtp:120 0-16
a=ssrc:816694098 cname:72cdb5f53fc2e8fb

Kamailio NAT Detect/Manage Routes


# Caller NAT detection

route[NATDETECT] {
#!ifdef WITH_NAT
xinfo("NATDETECT: Adding the rport parameter to the first Via header of the 
received message\n");
   force_rport();
   xinfo("NATDETECT: Trying to guess if client's request originated behind a 
nat. Testing 19.\n");
   if (nat_uac_test("19")) {
  if (is_method("REGISTER")) {
  xinfo("NATDETECT: REGISTER request. Creating a URI consisting of the 
source IP, port, and protocol and storing the URI in an 
Attribute-Value-Pair.\n");
 fix_nated_register();
  } else {
 if(is_first_hop()) {
 xinfo("NATDETECT: Adding an ;alias=ip~port~transport parameter to 
the contact URI containing the received ip, port, and transport protocol.\n");
set_contact_alias();
 }
  }
   xinfo("NATDETECT: Setting flag FLT_NATS.\n");
  setflag(FLT_NATS);
   } else {
   xinfo("NATDETECT: Didn't detect natted request by any of the given 
heuristics\n");
   }
#!endif
   return;
}

# RTPProxy control and signaling updates for NAT traversal
route[NATMANAGE] {
#!ifdef WITH_NAT
   if (is_request()) {
  if(has_totag()) {
 if(check_route_param("nat=yes")) {
xinfo("NATMANAGE: This is a request with to-tag that has 'nat=yes', 
setting branch flag FLB_NATB.\n");
setbflag(FLB_NATB);
 }
  }
   }

   if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) {
   xinfo("NATMANAGE: No 

Re: [SR-Users] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Juha Heinanen
Olle E. Johansson writes:

> Full support for SIP outbound (using REG-id when registering etc).
> Last time I looked we did not have all nuts and bolts for it, but
> let’s give it a try.

Yes, reg-id is missing from contact.  It would be good to add so that
sip proxy can detect if registration is a new one or refreshes the old
one.

But if a connection oriented transport is used and connection breaks,
kamailio should unregister the contact.  If it does, missing of reg-id
does cause a problem.

For redundancy support, instance-id is needed and it is there.

-- Juha

__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Juha Heinanen
Olle E. Johansson writes:

> > Have you checked baresip?
> 
> I don’t recall baresip having a full SIP outbound implementation.

baresip is able to register with two outbound proxies and supports gruu
(below). What else is needed?

-- Juha

#
TLS 192.168.43.160:49556 -> 192.168.43.160:5061
REGISTER sip:test.tutpro.com SIP/2.0
Via: SIP/2.0/TLS 127.0.0.1:5047;branch=z9hG4bK305c4adf9d548df2;rport
Contact: 
;expires=600;+sip.instance="";q=0.5
Max-Forwards: 70
To: 
From: "Test Account" ;tag=f2465ebef6a435a2
Call-ID: ea13feabfb0effd8
CSeq: 1420 REGISTER
User-Agent: baresip v1.1.0 (x86_64/linux)
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER
Content-Length: 0
#
TLS 192.168.43.160:5061 -> 192.168.43.160:49556
SIP/2.0 200 OK
Via: SIP/2.0/TLS 
127.0.0.1:5047;branch=z9hG4bK305c4adf9d548df2;rport=49556;received=192.168.43.160
To: ;tag=75fad08a1e94bbeeabf349d4bd14beda.b29c1116
From: "Test Account" ;tag=f2465ebef6a435a2
Call-ID: ea13feabfb0effd8
CSeq: 1420 REGISTER
Contact: 
;q=0.5;expires=600;received="sip:192.168.43.160:49556;transport=tls";+sip.instance=""
Supported: outbound
Server: OpenSIPg SIP Proxy (5.6.0-0b02 (x86_64/linux))
Content-Length: 
#
TLS 192.168.43.160:49556 -> 192.168.43.160:5061
INVITE sip:f...@test.tutpro.com SIP/2.0
Via: SIP/2.0/TLS 127.0.0.1:5047;branch=z9hG4bK5b8f364c3b95c0b1;rport
Contact: 
Max-Forwards: 70
To: 
From: "Test Account" ;tag=ffb1ab9552ce5a91
Call-ID: 1a70eaa0d9e358bb
CSeq: 2779 INVITE
User-Agent: baresip v1.1.0 (x86_64/linux)
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER
Supported: gruu
Content-Type: application/sdp
Content-Length: 995

__
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


[SR-Users] Fwd: Possible memory leak on 5.5.x (new)?

2021-06-30 Thread George Diamantopoulos
Forwarding my reply to the list, using gmail's reply button set Henning as
the sole recipient :-\

-- Forwarded message -
From: George Diamantopoulos 
Date: Sat, 26 Jun 2021 at 02:25
Subject: Re: [SR-Users] Possible memory leak on 5.5.x (new)?
To: Henning Westerholt 


Hello Henning,

Thanks for your reply. Here's what has come up after a few hours:

shm55: https://pastebin.com/h9JCePmc
shm54: https://pastebin.com/Nx5xEEnA

It seems to me htable is the culprit? Are you seeing anything different? 54
has been running for 77020 seconds, 55 for 28521 (significantly less).

I'm going to turn it off until we figure something out...

BR,
George

On Fri, 25 Jun 2021 at 18:17, Henning Westerholt  wrote:

> Hello,
>
>
>
> Good observation. Please run the memory statistics CLI commands to get
> more hints about the module that might cause it (as per below link). Then
> please report more details. If you can point to a particular module, you
> can also open an issue on our tracker.
>
>
>
> https://www.kamailio.org/wiki/tutorials/troubleshooting/memory
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* sr-users  *On Behalf Of *George
> Diamantopoulos
> *Sent:* Friday, June 25, 2021 4:53 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* [SR-Users] Possible memory leak on 5.5.x (new)?
>
>
>
> Hello all,
>
>
>
> I'm still investigating the (most likely non-kamailio-related) memory leak
> of my previous message to the list, there have been no developments so far.
> I'll update if anything changes.
>
>
>
> This concerns a new finding which seems to affect kamailio 5.5.x. I have
> two kamailio instances receiving the same traffic via round-robin. I
> upgraded only one of them to 5.5.1 and left the other to 5.4.6 as I feared
> of any issues arising. I was lucky to do so, because with identical
> configuration, 5.5.x seems to run out of SHM very quickly. Here are links
> to graphs produced by our monitoring system:
>
>
>
> Old kamailio (no memory leak): https://pasteboard.co/K8fVBiD.png
>
> New kamailio (possible leak): https://pasteboard.co/K8fVS9N.png
>
>
>
> The configuration uses mtree, htable, vars and vns extensively. Has anyone
> come across anything similar? Let me know if I can provide any further
> information to help disect this. Thanks!
>
>
>
> BR,
>
> George
>
__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Juha Heinanen
Olle E. Johansson writes:

> Full implementation of SIP outbound is the only solution close to
> solving this problem in the IETF standards. 
> However, I have seen no single SIP client that have implemented this,
> even though Kamailio supports 
> it on the server side. The idea is that you always have two TCP
> connections to two active servers.

Have you checked baresip?

-- Juha

__
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


[SR-Users] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Juha Heinanen
Shahid Hussain writes:

> Would like to know what is the recommended solution for this problem using
> alias or is it a limitation of using alias?

Maybe a limitation.  Try with SIP User Agents that support gruu and thus
identify themselves using sip.instance.

-- Juha

__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Shahid Hussain
I am using a JSSIP client and they claim to be implemented RFC-5626.
Following are  the REGISTER and response messages. Is it possible to
confirm the JSSIP client has full implementation of SIP outbound?
If it supports fully then I can debug outbound and gruu functionality at
Kamailio(I have it enabled but it didn't work, have to see if I need to
enable any more settings).

REGISTER sip:sip.engageio.com SIP/2.0
Via: SIP/2.0/WSS 5qfe1k7uvuaf.invalid;branch=z9hG4bK563864
Max-Forwards: 69
To: 
From: "123456543" ;tag=em9kvbdqg2
Call-ID: 071s1uno9bk7ie1hf0p3dn
CSeq: 1 REGISTER
Contact: ;+sip.ice;reg-id=1;+sip.instance="";expires=600
Expires: 600
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: path,gruu,outbound
User-Agent: JsSIP 3.7.5
Content-Length: 0


SIP/2.0 200 OK
Via: SIP/2.0/WSS
5qfe1k7uvuaf.invalid;branch=z9hG4bK563864;received=172.27.6.98
To: ;tag=211517f31d5fe3f765e28c150e460fc3.0b7e
From: "123456543" ;tag=em9kvbdqg2
Call-ID: 071s1uno9bk7ie1hf0p3dn
CSeq: 1 REGISTER
Contact: ;expires=600;pub-gruu="sip:123456543_28i...@sip.engageio.com
;gr=urn:uuid:b7d40d83-b1f4-4419-bced-4c464507dea6";temp-gruu="
sip:uloc-60dc6c8a-7464-1-2dfe...@sip.engageio.com
;gr";+sip.instance="";reg-id=1
Require: outbound
Supported: outbound
Server: kamailio (5.3.2 (x86_64/linux))
Content-Length: 0



On Wed, Jun 30, 2021 at 4:11 PM Juha Heinanen  wrote:

> Due to other tests, I had missed baresip account's ;outbound paramater.
> Once I added it, also reg-id was added.
>
> -- Juha
>
> WSS 192.168.43.160:50442 -> 192.168.43.160:5061
> REGISTER sip:test.tutpro.com SIP/2.0
> Via: SIP/2.0/WSS 127.0.0.1:9;branch=z9hG4bK5a4ad01f9164d358;rport
> Contact:  ;transport=wss>;expires=30;+sip.instance="";q=0.5;reg-id=1
> Max-Forwards: 70
> Route: 
> To: 
> From: "Test Account" ;tag=904f27750c59fc5b
> Call-ID: 69f4eea174d327eb
> CSeq: 29225 REGISTER
> User-Agent: baresip v1.1.0 (x86_64/linux)
> Supported: gruu, outbound, path
> Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER
> Content-Length: 0
>
> __
> 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
>
__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Daniel-Constantin Mierla


On 30.06.21 09:28, Juha Heinanen wrote:
> Shahid Hussain writes:
>
>> Would like to know what is the recommended solution for this problem using
>> alias or is it a limitation of using alias?
> Maybe a limitation.  Try with SIP User Agents that support gruu and thus
> identify themselves using sip.instance.

Relying on GRUU would be ok, but most of the UAs I had to deal with lack
its implementation.

What I have seen as an alternative (e.g., linphone, iirc) is sending
re-INVITE with the new contact address and then a new alias will be
generated as well. It is not enough for the UA to send a new REGISTER,
that is for receiving new calls. In making calls is not restricted to
registered devices, therefore when an UA changes is local
states/coordinates, it has to send a re-INVITE. Contact can be changed
within dialog (also, just for sake of completion, dialog module should
save new Contact values), only Record-Route/Route headers are fixed for
active calls (as far as I remember right now).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda


__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Olle E. Johansson


> On 30 Jun 2021, at 10:14, Juha Heinanen  wrote:
> 
> Olle E. Johansson writes:
> 
>>> Have you checked baresip?
>> 
>> I don’t recall baresip having a full SIP outbound implementation.
> 
> baresip is able to register with two outbound proxies and supports gruu
> (below). What else is needed?

Full support for SIP outbound (using REG-id when registering etc).
Last time I looked we did not have all nuts and bolts for it, but let’s give it 
a try.

/O
__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Olle E. Johansson


> On 30 Jun 2021, at 09:49, Juha Heinanen  wrote:
> 
> Olle E. Johansson writes:
> 
>> Full implementation of SIP outbound is the only solution close to
>> solving this problem in the IETF standards. 
>> However, I have seen no single SIP client that have implemented this,
>> even though Kamailio supports 
>> it on the server side. The idea is that you always have two TCP
>> connections to two active servers.
> 
> Have you checked baresip?

I don’t recall baresip having a full SIP outbound implementation.

SIP outbound seems to be an elegant solution to a non-problem. Maybe it’s 
coming back on the radar now, several years later and we need to start working 
on it as more and more SIP moves to TCP/TLS or WebSocket and network operators 
implement CGnat and other middleboxes that do strange stuff to open flows.

Without SIP outbound a SIP UA using TLS needs to have a server cert and accept 
incoming TLS connections, which of course does not work over NAT, so if we want 
to be RFC compliant, we should at least copy the RFC for SIP over WebSocket 
“half-outbound” requirement to SIP/TLS and SIP/TCP.

I have started discussions about this “half-outbound” concept a few times, but 
haven’t gotten much support in the SIPcore IETF group. Meanwhile, Kamailio 
actually breaks the RFC by sending outbound requests on the inbound TLS 
connection. It works, but it’s not RFC compliant.

Cheers,
/O
__
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] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Olle E. Johansson


> On 30 Jun 2021, at 09:10, Shahid Hussain  wrote:
> 
> Hi,
> Websocket module documentation has a code reference to use aliases for SIP 
> routing. However, aliases will not work in the following setup and situation.
> 1. Kamailio is configured with active and standby node
> 2. Ping is implemented from webclient and kamailio responds with pong.
> 3. Two clients ClinetA and ClientB registered themselves to Kamailio.
> 4. After SIP negotiation (INVITE-200OK) each client learnt about below 
> aliases.
> Alias of ClientA:
> alias=172.27.6.98~58336
> Alias of ClientB:
> alias=172.27.6.98~58342
>  
> So normally if ClientB wants to send SIP message to ClientA, SIP URI from 
> ClientB looks like below
> ACK sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws 
> SIP/2.0
>  4. Call is in a connected state.
> 
> Following is the issue.
> i.  Switchover (or network lost or reboot) at Kamailio happened
> ii.  Due to ping pong both the clients detected network loss individually and 
> re-registered themselves.
> iii.  Aliases of both the clients got changed.
> New Alias of ClientA:
> alias=172.27.6.98~ 58346
>  
> New Alias of ClientB:
> alias=172.27.6.98~ 58348
>  
> iv.   But ClientB doesn’t know that ClientA also re-registered and ClientA’s 
> alias got changed and vice-versa
> v.Because of this ClientB still sends BYE with Initial alias
> BYE sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws 
> SIP/2.0
> 
> Would like to know what is the recommended solution for this problem using 
> alias or is it a limitation of using alias?

Full implementation of SIP outbound is the only solution close to solving this 
problem in the IETF standards.
However, I have seen no single SIP client that have implemented this, even 
though Kamailio supports
it on the server side. The idea is that you always have two TCP connections to 
two active servers.

https://datatracker.ietf.org/doc/rfc5626/ 


Having said that, SIP outbound enables registration survival and always being 
reachable, but it does not handle dialog survival. It was something we 
discussed for a while at the latest Kamailio dev meeting.

Hopefully the actual RTP streams can survive the failover and the call can go 
on, but if it depends on SIP signalling there’s no other way (that i know of) 
to survive and move the call to a new server with a new TCP connection. I have 
struggled with similar problems and made possible call survival in the case of 
lost SIP signalling path. It requires SIP uas that doesn’t implement any 
keepalive or SIP timer that will hangup if SIP signalling is dead.

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


[SR-Users] Websocket In-dialoge SIP routing failed post network loss due to aliases

2021-06-30 Thread Shahid Hussain
Hi,
Websocket module documentation has a code reference to use aliases for SIP
routing. However, aliases will not work in the following setup and
situation.
1. Kamailio is configured with active and standby node
2. Ping is implemented from webclient and kamailio responds with pong.
3. Two clients ClinetA and ClientB registered themselves to Kamailio.
4. After SIP negotiation (INVITE-200OK) each client learnt about below
aliases.
Alias of ClientA:
alias=172.27.6.98~58336
Alias of ClientB:
alias=172.27.6.98~58342

So normally if ClientB wants to send SIP message to ClientA, SIP URI from
ClientB looks like below
ACK sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws
SIP/2.0
 4. Call is in a connected state.

Following is the issue.
i.  Switchover (or network lost or reboot) at Kamailio happened
ii.  Due to ping pong both the clients detected network loss individually
and re-registered themselves.
iii.  Aliases of both the clients got changed.
New Alias of ClientA:
alias=172.27.6.98~ 58346

New Alias of ClientB:
alias=172.27.6.98~ 58348

iv.   But ClientB doesn’t know that ClientA also re-registered and
ClientA’s alias got changed and vice-versa
v.Because of this ClientB still sends BYE with Initial alias
BYE sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws
SIP/2.0

Would like to know what is the recommended solution for this problem using
alias or is it a limitation of using alias?

Thanks & Regards,
Shahid
__
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