date:20231128

Re: [OpenSIPS-Users] Debug logs show To tag which are actually From tag

2023-11-28 Thread Johan De Clercq

I agree, but it's very confusing.

Op di 28 nov 2023 om 10:35 schreef Bogdan-Andrei Iancu :

> Hi Robert,
>
> As from SIP perspective both TO and FROM hdrs have the same syntax,
> internally OpenSIPS uses the same function "parse_to()" for parsing both
> hdrs. So, we are all good here :)
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 23.11.2023 21:36, Robert Dyck wrote:
>
> While running opensips in debug mode I noticed that for initial requests
> of dialog creating methods the debug logs were showing a To tag where none
> actually exists. The tag displayed was actually the From tag.
>
> INVITE sip:8@192.168.1.2 SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.k7nLoQHpR;rport
> From: ;*tag=GSq6JzXiH *
> To: sip:8@192.168.1.2
> CSeq: 21 INVITE
> Call-ID: VCALnmUf8V
>
>
> Nov 23 11:02:32 [1131200] DBG:maxfwd:is_maxfwd_present: value = 70
> Nov 23 11:02:32 [1131200] *DBG:sipmsgops:has_totag: no totag *
> Nov 23 11:02:32 [1131200] Initial request, method is INVITE, URI is
> sip:8@192.168.1.2
>
> Nov 23 11:02:32 [1131200] DBG:core:check_self: host != me
> Nov 23 11:02:32 [1131200] DBG:core:parse_headers: flags=78
> Nov 23 11:02:32 [1131200] DBG:tm:t_lookup_request: start searching:
> hash=42361, isACK=0
> Nov 23 11:02:32 [1131200] DBG:tm:matching_3261: RFC3261 transaction
> matching failed
> Nov 23 11:02:32 [1131200] DBG:tm:t_lookup_request: no transaction found
> Nov 23 11:02:32 [1131200] *DBG:core:parse_to_param: tag=GSq6JzXiH *
> Nov 23 11:02:32 [1131200] DBG:core:parse_to_param: end of header reached,
> state=11
>
>
> PUBLISH sip:7@192.168.1.2 SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.myBdBZt3P;rport
> From: ;*tag=cbp~iz4fq*
> To: sip:7@192.168.1.2
> CSeq: 21 PUBLISH
> Call-ID: cRC6Gw590w
> Max-Forwards: 70
>
>
>
> Nov 23 11:07:08 [1133909] DBG:maxfwd:is_maxfwd_present: value = 70
> Nov 23 11:07:08 [1133909] *DBG:sipmsgops:has_totag: no totag*
> Nov 23 11:07:08 [1133909] Initial request, method is PUBLISH, URI is
> sip:7@192.168.1.2
>
>
>
> Nov 23 11:07:08 [1133909] DBG:core:check_self: host != me
> Nov 23 11:07:08 [1133909] DBG:core:parse_headers: flags=78
> Nov 23 11:07:08 [1133909] DBG:tm:t_lookup_request: start searching:
> hash=7222, isACK=0
> Nov 23 11:07:08 [1133909] DBG:tm:matching_3261: RFC3261 transaction
> matching failed
> Nov 23 11:07:08 [1133909] DBG:tm:t_lookup_request: no transaction found
> Nov 23 11:07:08 [1133909] *DBG:core:parse_to_param: tag=cbp~iz4fq*
> Nov 23 11:07:08 [1133909] DBG:core:parse_to_param: end of header reached,
> state=11
>
>
>
> SUBSCRIBE sip:rls@192.168.1.2 SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.OkkDHBafu;rport
> From: ;*tag=g2aNdkn4o *
> To: sips:rls@192.168.1.2
> CSeq: 21 SUBSCRIBE
> Call-ID: L9LKmnZVY7
> Max-Forwards: 69
>
>
> Nov 23 11:07:07 [1133909] DBG:maxfwd:is_maxfwd_present: value = 70
> Nov 23 11:07:07 [1133909] *DBG:sipmsgops:has_totag: no totag*
> Nov 23 11:07:07 [1133909] Initial request, method is SUBSCRIBE, URI is
> sip:rls@192.168.1.2
>
>
>
> Nov 23 11:07:07 [1133909] DBG:core:check_self: host != me
> Nov 23 11:07:07 [1133909] DBG:core:parse_headers: flags=78
> Nov 23 11:07:07 [1133909] DBG:tm:t_lookup_request: start searching:
> hash=33557, isACK=0
> Nov 23 11:07:07 [1133909] DBG:tm:matching_3261: RFC3261 transaction
> matching failed
> Nov 23 11:07:07 [1133909] DBG:tm:t_lookup_request: no transaction found
> Nov 23 11:07:07 [1133909] *DBG:core:parse_to_param: tag=g2aNdkn4o *
> Nov 23 11:07:07 [1133909] DBG:core:parse_to_param: end of header reached,
> state=1
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Scope of IMS in OpenSIPS - RFC

2023-11-28 Thread Bogdan-Andrei Iancu


Hi all,

(disclaimer : cross lists posting is not a good practice - we will do 
this only to catch the attention and get momentum with this initial topic)


As a first step here, is to work out the scope of the IMS implementation 
in OpenSIPS. IMS is a vast concept, with SIP and non-SIP components, and 
we want to understand and agree on which components of IMS may be 
subject of work from the OpenSIPS perspective. For example, we do 
consider the CSCF as a must here, but we may explore the HSS, AS, MGW or 
other components.


From the OpenSIPS perspective, we look for IMS components which are SIP 
related. At least as a starting point. So, the first obvious candidate 
is the *Call Session Control Function (CSCF)*. And here we need to look 
into and address the specific functionalities of each sub-component:

    * P-CSCF
    * I-CSCF
    * S-CSCF

Again, these are the pretty obvious components, still may look into and 
evaluate (if of an interest of the OpenSIPS IMS implementation) areas as:

    * HSS (from interconnection perspective)
    * MGCF / MGW  (from interconnection perspective)
    * SIP AS
    * others ?

Any feedback (with explanations and arguments) about what we should 
consider for our IMS implementation is more the welcome. I set here just 
a simple starting point, with no limitations or so. Feel free to 
contribute to the topic



Best regards,

--
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] IMS OpenSIPS Working Group - Kickoff

2023-11-28 Thread Bogdan-Andrei Iancu


Hi all,

As mentioned in the 3.5 planning 
, this 
release is IMS focused. And to deal with the complexity of this task, we 
have this new tool, the IMS OpenSIPS Working Group. 



And now it is the time to start its work 🙂. As starting point, we put 
together the Roadmap of the group and also some initial Technical 
Requirements (as guidance). All this info is available on the group WIKI 
page .


The main discussion channel is the group's mailing list 
. So, as a 
fist step, if interested to contribute to the IMS work, please subscribe 
to the list.


An now we have the official kick-off of the group by starting there the 
discussion on the *IMS scope in OpenSIPS*, so we need all hands on deck. 
Again, please subscribe to the mailing list; also check the list's 
archive to catch up with ongoing threads.


See you on the WG-IMS list ;)

--
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL handling issue

2023-11-28 Thread Bogdan-Andrei Iancu


:+1:

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 28.11.2023 11:53, nz deals wrote:

Hi Bogdan,

Looks like the upgrade has resolved the issue.

Regards,
Jason

On Tue, 28 Nov 2023 at 22:25, Bogdan-Andrei Iancu 
 wrote:


Hi,

I just made a simple test using only `advertised_address` and
calling from A to B and cancelling from A. The CANCEL from
OpenSIPS to B obeys the advertising. I used the latest 3.3 :
    version: opensips 3.3.8 (x86_64/linux)

Tested with both UDP and TCP, worked in both cases.

SO, try also the latest 3.3, to see if it works for you too. If
not, try to put together a minimal cfg to support user
registration + calls between users, cfg to show the problem.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 27.11.2023 13:44, nz deals wrote:

Hi Bogdan,
No other advertisement via socket definition or any script function.

Thank you

On Fri, 24 Nov 2023 at 05:47, Bogdan-Andrei Iancu
 wrote:

Just checking, only the `advertised_address` global param
[1], no other kind of advertising (via socket definition or
script function) ?

[1]

https://www.opensips.org/Documentation/Script-CoreParameters-3-3#advertised_address

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 10:47 PM, nz deals wrote:

Hi Bogdan,
My opensips version is opensips 3.3.5 (x86_64/linux)

Regards,
Jason

On Thu, 23 Nov 2023 at 01:49, Bogdan-Andrei Iancu
 wrote:

What is your exact opensips version ( `opensips -V` ) ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 12:24 PM, nz deals wrote:

Thanks Bogdan,

It is due to receiving CANCEL from the caller. Yes
using an advertised_address globally. One of our public
addresses.

Thanks

On Wed, 22 Nov 2023 at 23:08, Bogdan-Andrei Iancu
 wrote:

Hi Jason,

The CANCEL generated by OpenSIPS, is it due to a
received CANCEL or due to an internal timeout /
forking? ALso do you use any advertising in your
setup? if yes, is it per socket, global or ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 7:04 AM, nz deals wrote:

Hi folks,

Is there any bug in the CANCEL handling in the
version 3.3.x?
I have a weird issue,
The INVITE have a VIA header as my private ip
Via: SIP/2.0/TCP 192.XX.XX.XX:5060;branch=XXX

But when i CANCEL the call, the CANCEL have my
public ip in the VIA header.
Via: SIP/2.0/TCP 104.xx.xx.xx:5060;branch=xxx

Anyway can I change the via in the cancel?

Regards,
Jason

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users








___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL handling issue

2023-11-28 Thread Bogdan-Andrei Iancu


I tried with UDP to TCP with the global advertising, still working.

Again: 1) upgrade to latest 3.3, 2) put together a way to reproduce.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 28.11.2023 11:48, Jehanzaib Younis wrote:

Hi Bogdan,

The only difference is, I am receiving traffic on UDP and sending on 
TCP socket.
sorry i forgot to mention before the advertised_address is 
globally defined (public ip)



Regards,
Jehanzaib


On Tue, Nov 28, 2023 at 10:26 PM Bogdan-Andrei Iancu 
 wrote:


Hi,

I just made a simple test using only `advertised_address` and
calling from A to B and cancelling from A. The CANCEL from
OpenSIPS to B obeys the advertising. I used the latest 3.3 :
    version: opensips 3.3.8 (x86_64/linux)

Tested with both UDP and TCP, worked in both cases.

SO, try also the latest 3.3, to see if it works for you too. If
not, try to put together a minimal cfg to support user
registration + calls between users, cfg to show the problem.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 27.11.2023 13:44, nz deals wrote:

Hi Bogdan,
No other advertisement via socket definition or any script function.

Thank you

On Fri, 24 Nov 2023 at 05:47, Bogdan-Andrei Iancu
 wrote:

Just checking, only the `advertised_address` global param
[1], no other kind of advertising (via socket definition or
script function) ?

[1]

https://www.opensips.org/Documentation/Script-CoreParameters-3-3#advertised_address

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 10:47 PM, nz deals wrote:

Hi Bogdan,
My opensips version is opensips 3.3.5 (x86_64/linux)

Regards,
Jason

On Thu, 23 Nov 2023 at 01:49, Bogdan-Andrei Iancu
 wrote:

What is your exact opensips version ( `opensips -V` ) ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 12:24 PM, nz deals wrote:

Thanks Bogdan,

It is due to receiving CANCEL from the caller. Yes
using an advertised_address globally. One of our public
addresses.

Thanks

On Wed, 22 Nov 2023 at 23:08, Bogdan-Andrei Iancu
 wrote:

Hi Jason,

The CANCEL generated by OpenSIPS, is it due to a
received CANCEL or due to an internal timeout /
forking? ALso do you use any advertising in your
setup? if yes, is it per socket, global or ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 7:04 AM, nz deals wrote:

Hi folks,

Is there any bug in the CANCEL handling in the
version 3.3.x?
I have a weird issue,
The INVITE have a VIA header as my private ip
Via: SIP/2.0/TCP 192.XX.XX.XX:5060;branch=XXX

But when i CANCEL the call, the CANCEL have my
public ip in the VIA header.
Via: SIP/2.0/TCP 104.xx.xx.xx:5060;branch=xxx

Anyway can I change the via in the cancel?

Regards,
Jason

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users








___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL handling issue

2023-11-28 Thread Jehanzaib Younis

I have the exact same issue. I am also not able to change the Via header.

Regards,
Jehanzaib


On Tue, Nov 28, 2023 at 10:48 PM Jehanzaib Younis 
wrote:

> Hi Bogdan,
>
> The only difference is, I am receiving traffic on UDP and sending on TCP
> socket.
> sorry i forgot to mention before the advertised_address is
> globally defined (public ip)
>
>
> Regards,
> Jehanzaib
>
>
> On Tue, Nov 28, 2023 at 10:26 PM Bogdan-Andrei Iancu 
> wrote:
>
>> Hi,
>>
>> I just made a simple test using only `advertised_address` and calling
>> from A to B and cancelling from A. The CANCEL from OpenSIPS to B obeys the
>> advertising. I used the latest 3.3 :
>> version: opensips 3.3.8 (x86_64/linux)
>>
>> Tested with both UDP and TCP, worked in both cases.
>>
>> SO, try also the latest 3.3, to see if it works for you too. If not, try
>> to put together a minimal cfg to support user registration + calls between
>> users, cfg to show the problem.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 27.11.2023 13:44, nz deals wrote:
>>
>> Hi Bogdan,
>> No other advertisement via socket definition or any script function.
>>
>> Thank you
>>
>> On Fri, 24 Nov 2023 at 05:47, Bogdan-Andrei Iancu 
>> wrote:
>>
>>> Just checking, only the `advertised_address` global param [1], no other
>>> kind of advertising (via socket definition or script function) ?
>>>
>>> [1]
>>> https://www.opensips.org/Documentation/Script-CoreParameters-3-3#advertised_address
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   https://www.opensips-solutions.com
>>>   https://www.siphub.com
>>>
>>> On 11/22/23 10:47 PM, nz deals wrote:
>>>
>>> Hi Bogdan,
>>> My opensips version is opensips 3.3.5 (x86_64/linux)
>>>
>>> Regards,
>>> Jason
>>>
>>> On Thu, 23 Nov 2023 at 01:49, Bogdan-Andrei Iancu 
>>> wrote:
>>>
 What is your exact opensips version ( `opensips -V` ) ?

 Regards,

 Bogdan-Andrei Iancu

 OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

 On 11/22/23 12:24 PM, nz deals wrote:

 Thanks Bogdan,

 It is due to receiving CANCEL from the caller. Yes using an
 advertised_address globally. One of our public addresses.

 Thanks

 On Wed, 22 Nov 2023 at 23:08, Bogdan-Andrei Iancu 
 wrote:

> Hi Jason,
>
> The CANCEL generated by OpenSIPS, is it due to a received CANCEL or
> due to an internal timeout / forking? ALso do you use any advertising in
> your setup? if yes, is it per socket, global or ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 11/22/23 7:04 AM, nz deals wrote:
>
> Hi folks,
>
> Is there any bug in the CANCEL handling in the version 3.3.x?
> I have a weird issue,
> The INVITE have a VIA header as my private ip
> Via: SIP/2.0/TCP 192.XX.XX.XX:5060;branch=XXX
>
> But when i CANCEL the call, the CANCEL have my public ip in the VIA
> header.
> Via: SIP/2.0/TCP 104.xx.xx.xx:5060;branch=xxx
>
> Anyway can I change the via in the cancel?
>
> Regards,
> Jason
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>

>>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL handling issue

2023-11-28 Thread nz deals

Hi Bogdan,

Looks like the upgrade has resolved the issue.

Regards,
Jason

On Tue, 28 Nov 2023 at 22:25, Bogdan-Andrei Iancu 
wrote:

> Hi,
>
> I just made a simple test using only `advertised_address` and calling
> from A to B and cancelling from A. The CANCEL from OpenSIPS to B obeys the
> advertising. I used the latest 3.3 :
> version: opensips 3.3.8 (x86_64/linux)
>
> Tested with both UDP and TCP, worked in both cases.
>
> SO, try also the latest 3.3, to see if it works for you too. If not, try
> to put together a minimal cfg to support user registration + calls between
> users, cfg to show the problem.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 27.11.2023 13:44, nz deals wrote:
>
> Hi Bogdan,
> No other advertisement via socket definition or any script function.
>
> Thank you
>
> On Fri, 24 Nov 2023 at 05:47, Bogdan-Andrei Iancu 
> wrote:
>
>> Just checking, only the `advertised_address` global param [1], no other
>> kind of advertising (via socket definition or script function) ?
>>
>> [1]
>> https://www.opensips.org/Documentation/Script-CoreParameters-3-3#advertised_address
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 11/22/23 10:47 PM, nz deals wrote:
>>
>> Hi Bogdan,
>> My opensips version is opensips 3.3.5 (x86_64/linux)
>>
>> Regards,
>> Jason
>>
>> On Thu, 23 Nov 2023 at 01:49, Bogdan-Andrei Iancu 
>> wrote:
>>
>>> What is your exact opensips version ( `opensips -V` ) ?
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   https://www.opensips-solutions.com
>>>   https://www.siphub.com
>>>
>>> On 11/22/23 12:24 PM, nz deals wrote:
>>>
>>> Thanks Bogdan,
>>>
>>> It is due to receiving CANCEL from the caller. Yes using an
>>> advertised_address globally. One of our public addresses.
>>>
>>> Thanks
>>>
>>> On Wed, 22 Nov 2023 at 23:08, Bogdan-Andrei Iancu 
>>> wrote:
>>>
 Hi Jason,

 The CANCEL generated by OpenSIPS, is it due to a received CANCEL or due
 to an internal timeout / forking? ALso do you use any advertising in your
 setup? if yes, is it per socket, global or ?

 Regards,

 Bogdan-Andrei Iancu

 OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

 On 11/22/23 7:04 AM, nz deals wrote:

 Hi folks,

 Is there any bug in the CANCEL handling in the version 3.3.x?
 I have a weird issue,
 The INVITE have a VIA header as my private ip
 Via: SIP/2.0/TCP 192.XX.XX.XX:5060;branch=XXX

 But when i CANCEL the call, the CANCEL have my public ip in the VIA
 header.
 Via: SIP/2.0/TCP 104.xx.xx.xx:5060;branch=xxx

 Anyway can I change the via in the cancel?

 Regards,
 Jason

 ___
 Users mailing 
 listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users



>>>
>>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL handling issue

2023-11-28 Thread Jehanzaib Younis

Hi Bogdan,

The only difference is, I am receiving traffic on UDP and sending on TCP
socket.
sorry i forgot to mention before the advertised_address is globally defined
(public ip)


Regards,
Jehanzaib


On Tue, Nov 28, 2023 at 10:26 PM Bogdan-Andrei Iancu 
wrote:

> Hi,
>
> I just made a simple test using only `advertised_address` and calling
> from A to B and cancelling from A. The CANCEL from OpenSIPS to B obeys the
> advertising. I used the latest 3.3 :
> version: opensips 3.3.8 (x86_64/linux)
>
> Tested with both UDP and TCP, worked in both cases.
>
> SO, try also the latest 3.3, to see if it works for you too. If not, try
> to put together a minimal cfg to support user registration + calls between
> users, cfg to show the problem.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 27.11.2023 13:44, nz deals wrote:
>
> Hi Bogdan,
> No other advertisement via socket definition or any script function.
>
> Thank you
>
> On Fri, 24 Nov 2023 at 05:47, Bogdan-Andrei Iancu 
> wrote:
>
>> Just checking, only the `advertised_address` global param [1], no other
>> kind of advertising (via socket definition or script function) ?
>>
>> [1]
>> https://www.opensips.org/Documentation/Script-CoreParameters-3-3#advertised_address
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 11/22/23 10:47 PM, nz deals wrote:
>>
>> Hi Bogdan,
>> My opensips version is opensips 3.3.5 (x86_64/linux)
>>
>> Regards,
>> Jason
>>
>> On Thu, 23 Nov 2023 at 01:49, Bogdan-Andrei Iancu 
>> wrote:
>>
>>> What is your exact opensips version ( `opensips -V` ) ?
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>>
>>> OpenSIPS Founder and Developer
>>>   https://www.opensips-solutions.com
>>>   https://www.siphub.com
>>>
>>> On 11/22/23 12:24 PM, nz deals wrote:
>>>
>>> Thanks Bogdan,
>>>
>>> It is due to receiving CANCEL from the caller. Yes using an
>>> advertised_address globally. One of our public addresses.
>>>
>>> Thanks
>>>
>>> On Wed, 22 Nov 2023 at 23:08, Bogdan-Andrei Iancu 
>>> wrote:
>>>
 Hi Jason,

 The CANCEL generated by OpenSIPS, is it due to a received CANCEL or due
 to an internal timeout / forking? ALso do you use any advertising in your
 setup? if yes, is it per socket, global or ?

 Regards,

 Bogdan-Andrei Iancu

 OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

 On 11/22/23 7:04 AM, nz deals wrote:

 Hi folks,

 Is there any bug in the CANCEL handling in the version 3.3.x?
 I have a weird issue,
 The INVITE have a VIA header as my private ip
 Via: SIP/2.0/TCP 192.XX.XX.XX:5060;branch=XXX

 But when i CANCEL the call, the CANCEL have my public ip in the VIA
 header.
 Via: SIP/2.0/TCP 104.xx.xx.xx:5060;branch=xxx

 Anyway can I change the via in the cancel?

 Regards,
 Jason

 ___
 Users mailing 
 listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users



>>>
>>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debug logs show To tag which are actually From tag

2023-11-28 Thread Bogdan-Andrei Iancu


Hi Robert,

As from SIP perspective both TO and FROM hdrs have the same syntax, 
internally OpenSIPS uses the same function "parse_to()" for parsing both 
hdrs. So, we are all good here :)


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 23.11.2023 21:36, Robert Dyck wrote:


While running opensips in debug mode I noticed that for initial 
requests of dialog creating methods the debug logs were showing a To 
tag where none actually exists. The tag displayed was actually the 
From tag.



INVITE sip:8@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.k7nLoQHpR;rport
From: ;*tag=GSq6JzXiH *
To: sip:8@192.168.1.2
CSeq: 21 INVITE
Call-ID: VCALnmUf8V


Nov 23 11:02:32 [1131200] DBG:maxfwd:is_maxfwd_present: value = 70
Nov 23 11:02:32 [1131200] *DBG:sipmsgops:has_totag: no totag *
Nov 23 11:02:32 [1131200] Initial request, method is INVITE, URI is 
sip:8@192.168.1.2


Nov 23 11:02:32 [1131200] DBG:core:check_self: host != me
Nov 23 11:02:32 [1131200] DBG:core:parse_headers: flags=78
Nov 23 11:02:32 [1131200] DBG:tm:t_lookup_request: start searching: 
hash=42361, isACK=0
Nov 23 11:02:32 [1131200] DBG:tm:matching_3261: RFC3261 transaction 
matching failed

Nov 23 11:02:32 [1131200] DBG:tm:t_lookup_request: no transaction found
Nov 23 11:02:32 [1131200] *DBG:core:parse_to_param: tag=GSq6JzXiH *
Nov 23 11:02:32 [1131200] DBG:core:parse_to_param: end of header 
reached, state=11



PUBLISH sip:7@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.myBdBZt3P;rport
From: ;*tag=cbp~iz4fq*
To: sip:7@192.168.1.2
CSeq: 21 PUBLISH
Call-ID: cRC6Gw590w
Max-Forwards: 70

Nov 23 11:07:08 [1133909] DBG:maxfwd:is_maxfwd_present: value = 70
Nov 23 11:07:08 [1133909] *DBG:sipmsgops:has_totag: no totag*
Nov 23 11:07:08 [1133909] Initial request, method is PUBLISH, URI is 
sip:7@192.168.1.2


Nov 23 11:07:08 [1133909] DBG:core:check_self: host != me
Nov 23 11:07:08 [1133909] DBG:core:parse_headers: flags=78
Nov 23 11:07:08 [1133909] DBG:tm:t_lookup_request: start searching: 
hash=7222, isACK=0
Nov 23 11:07:08 [1133909] DBG:tm:matching_3261: RFC3261 transaction 
matching failed

Nov 23 11:07:08 [1133909] DBG:tm:t_lookup_request: no transaction found
Nov 23 11:07:08 [1133909] *DBG:core:parse_to_param: tag=cbp~iz4fq*
Nov 23 11:07:08 [1133909] DBG:core:parse_to_param: end of header 
reached, state=11


SUBSCRIBE sip:rls@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK.OkkDHBafu;rport
From: ;*tag=g2aNdkn4o *
To: sips:rls@192.168.1.2
CSeq: 21 SUBSCRIBE
Call-ID: L9LKmnZVY7
Max-Forwards: 69


Nov 23 11:07:07 [1133909] DBG:maxfwd:is_maxfwd_present: value = 70
Nov 23 11:07:07 [1133909] *DBG:sipmsgops:has_totag: no totag*
Nov 23 11:07:07 [1133909] Initial request, method is SUBSCRIBE, URI is 
sip:rls@192.168.1.2


Nov 23 11:07:07 [1133909] DBG:core:check_self: host != me
Nov 23 11:07:07 [1133909] DBG:core:parse_headers: flags=78
Nov 23 11:07:07 [1133909] DBG:tm:t_lookup_request: start searching: 
hash=33557, isACK=0
Nov 23 11:07:07 [1133909] DBG:tm:matching_3261: RFC3261 transaction 
matching failed

Nov 23 11:07:07 [1133909] DBG:tm:t_lookup_request: no transaction found
Nov 23 11:07:07 [1133909] *DBG:core:parse_to_param: tag=g2aNdkn4o *
Nov 23 11:07:07 [1133909] DBG:core:parse_to_param: end of header 
reached, state=1



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CANCEL handling issue

2023-11-28 Thread Bogdan-Andrei Iancu


Hi,

I just made a simple test using only `advertised_address` and calling 
from A to B and cancelling from A. The CANCEL from OpenSIPS to B obeys 
the advertising. I used the latest 3.3 :

    version: opensips 3.3.8 (x86_64/linux)

Tested with both UDP and TCP, worked in both cases.

SO, try also the latest 3.3, to see if it works for you too. If not, try 
to put together a minimal cfg to support user registration + calls 
between users, cfg to show the problem.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
  https://www.siphub.com

On 27.11.2023 13:44, nz deals wrote:

Hi Bogdan,
No other advertisement via socket definition or any script function.

Thank you

On Fri, 24 Nov 2023 at 05:47, Bogdan-Andrei Iancu 
 wrote:


Just checking, only the `advertised_address` global param [1], no
other kind of advertising (via socket definition or script function) ?

[1]

https://www.opensips.org/Documentation/Script-CoreParameters-3-3#advertised_address

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 10:47 PM, nz deals wrote:

Hi Bogdan,
My opensips version is opensips 3.3.5 (x86_64/linux)

Regards,
Jason

On Thu, 23 Nov 2023 at 01:49, Bogdan-Andrei Iancu
 wrote:

What is your exact opensips version ( `opensips -V` ) ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 12:24 PM, nz deals wrote:

Thanks Bogdan,

It is due to receiving CANCEL from the caller. Yes using an
advertised_address globally. One of our public addresses.

Thanks

On Wed, 22 Nov 2023 at 23:08, Bogdan-Andrei Iancu
 wrote:

Hi Jason,

The CANCEL generated by OpenSIPS, is it due to a
received CANCEL or due to an internal timeout / forking?
ALso do you use any advertising in your setup? if yes,
is it per socket, global or ?

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 11/22/23 7:04 AM, nz deals wrote:

Hi folks,

Is there any bug in the CANCEL handling in the version
3.3.x?
I have a weird issue,
The INVITE have a VIA header as my private ip
Via: SIP/2.0/TCP 192.XX.XX.XX:5060;branch=XXX

But when i CANCEL the call, the CANCEL have my public
ip in the VIA header.
Via: SIP/2.0/TCP 104.xx.xx.xx:5060;branch=xxx

Anyway can I change the via in the cancel?

Regards,
Jason

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users






___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Debug logs show To tag which are actually From tag

[OpenSIPS-Users] Scope of IMS in OpenSIPS - RFC

[OpenSIPS-Users] IMS OpenSIPS Working Group - Kickoff

Re: [OpenSIPS-Users] CANCEL handling issue

Re: [OpenSIPS-Users] CANCEL handling issue

Re: [OpenSIPS-Users] CANCEL handling issue

Re: [OpenSIPS-Users] CANCEL handling issue

Re: [OpenSIPS-Users] CANCEL handling issue

Re: [OpenSIPS-Users] Debug logs show To tag which are actually From tag

Re: [OpenSIPS-Users] CANCEL handling issue

10 matches

Site Navigation

Mail list logo

Footer information