Re: [OpenSIPS-Users] uac_replace_from in CANCEL

[Bogdan-Andrei Iancu]

The Contact hdr is not relevant for TM, still it is if you are using 
nathelper (for pinging) or dialog support with topo hiding (where the Ct 
must be retained).


Regards,

Bogdan-Andrei Iancu

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

On 15.01.2024 21:07, nz deals wrote:

Thank you Bogdan,

It seems that replacing remove_hf with uac_replace_from has resolved 
the issue.
Just a quick question: if I use remove_hf("Contact") during INVITE, 
will TM become aware of this change?




Regards,
Jason

On Fri, 5 Jan 2024 at 23:55, Bogdan-Andrei Iancu  
wrote:


Hi Jason,

For changing the FROM hdr (at INVITE time), better use the
uac_replace_from() function [1] - by doing this, the TM will
become aware of the change and reflect it into CANCEL too.


[1]
https://opensips.org/html/docs/modules/3.4.x/uac.html#func_uac_replace_from

Regards,

Bogdan-Andrei Iancu

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

On 24.12.2023 13:33, nz deals wrote:

Hi Bogdan,
Agreed that the RFC3261 CANCEL is truly built using INVITE. In my
case, somehow CANCEL is not the same as the initial INVITE. Due
to the complexity of my case I have hard times to fix the issue.
Let me explain a bit.
On the INVITE i change the From Header, which i can see has also
been changed during Authorization.
If i CANCEL then the From header is different (it's the same as i
have before making my change).

I am also using topology_hiding().


under the main route i change the From header for INVITE

        set_advertised_address("104.13.xx.xx "); # same as i have
used in the advertised_address
        # this is my cancel processing
        if (is_method("CANCEL")) {
                if (t_check_trans())
                        t_relay(8);
                exit;
        }
        if (has_totag()) {
            if(topology_hiding_match())  {
                                   # remove and add a custom one
 remove_hf("From");
                                   append_hf("From:
\"$fU\";tag=$ft\r\n");
 force_send_socket("tls:192.xx.xx.xx:5061");
             }
        }
My opensips version is 3.4.2
My listening socket is socket=tls:ens192:5061 tag ens192     (its
the same 192.xx.xx.xx IP that you see in the force_send_socket)
I am also using public ip as follows
advertised_address=104.13.xx.xx
alias=104.13.xx.xx

Regards,
Jason

On Thu, 21 Dec 2023 at 02:31, Bogdan-Andrei Iancu
 wrote:

Hi Jason,

In transactional stateful SIP, the CANCEL requests are hop by
hop - each hop in the path is generating its own CANCEL
requests to the next hop, which consumes it; there is no
actual relaying of the CANCELs. So, the replacing (which
works in relaying mode only) doesn't fit here.

Even more, the RFC3261 gives a rigorous way for building the
CANCEL requests, they are to be built 100% based on the
INVITE request only (nothing more). OpenSIPS internally
builds the CANCEL in accordance to the corresponding INVITE,
so you should not need any such changes.

May you detail why you think you need this FROM replacement?

Regards,

Bogdan-Andrei Iancu

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

On 20.12.2023 12:38, nz deals wrote:

Hi,
I've been attempting to modify the From header in the
CANCEL, but it seems the changes aren't taking effect. I've
also experimented with remove_hf and append_hf, but
unfortunately, these methods didn't work either. Could
someone kindly offer suggestions if I might be overlooking
something?

This is in the main request route

        if (is_method("CANCEL")) {
                uac_replace_from("","sip:t...@test.com
");
                if (t_check_trans())
                        t_relay(8);
                exit;
        }



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

[OpenSIPS-Users] opensips 3.4 documentation event_routing example 1.6.1 - push notification

[rvg]

Hi openSIPS team,

I do not understand the documentaion (opensips version 3.4 manual) on the 
event_routing module.

The example given 1.6.1 push notification does not seem to do just that.

It says:
"
1.6.1. Push Notification


We use*notify_on_event*to capture the events on new contact registrations for 
callee. Once the call is sent to callee, based on the notification (for new 
contacts) we inject the newly registered contacts as new branches in the 
ongoing transaction.



Schematics : when we send a call to a user, we subscribe to see any new 
contacts being registered by the user. On such a notification, we add the new 
contact as a new branch to the ongoing transaction (ringing) to user.

"
It seems this has to do with notify_on_event.
It may be that the new branches are be added with device information for the 
push notification, but I do not see that in the example given.

Please advise,

Regards,

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

Re: [OpenSIPS-Users] Removing header by contents

[Ihor Olkhovskyi]

Thanks,

I've tried to use them, but seems they are taking for both expressions, 
regex and glob not looking in Header values, but names only


When looking at the code, my suspicion getting stronger

https://github.com/OpenSIPS/opensips/blob/224a3236cbeaeb06a897cb3beab8c3a0c3d5903f/modules/sipmsgops/sipmsgops.c#L425

Le 15/01/2024 à 15:03, Alexey a écrit :

Hello Igor,

these functions - isn't it what you need?

remove_hf_re(hname_expr) [1]
remove_hf_glob(hname_pattern) [2]

1. https://opensips.org/docs/modules/3.4.x/sipmsgops.html#func_remove_hf_re
2. https://opensips.org/docs/modules/3.4.x/sipmsgops.html#func_remove_hf_glob




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

Re: [OpenSIPS-Users] uac_replace_from in CANCEL

[nz deals]

Thank you Bogdan,

It seems that replacing remove_hf with uac_replace_from has resolved the
issue.
Just a quick question: if I use remove_hf("Contact") during INVITE, will TM
become aware of this change?



Regards,
Jason

On Fri, 5 Jan 2024 at 23:55, Bogdan-Andrei Iancu 
wrote:

> Hi Jason,
>
> For changing the FROM hdr (at INVITE time), better use the
> uac_replace_from() function [1] - by doing this, the TM will become aware
> of the change and reflect it into CANCEL too.
>
>
> [1]
> https://opensips.org/html/docs/modules/3.4.x/uac.html#func_uac_replace_from
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>   https://www.siphub.com
>
> On 24.12.2023 13:33, nz deals wrote:
>
> Hi Bogdan,
> Agreed that the RFC3261 CANCEL is truly built using INVITE. In my case,
> somehow CANCEL is not the same as the initial INVITE. Due to the complexity
> of my case I have hard times to fix the issue. Let me explain a bit.
> On the INVITE i change the From Header, which i can see has also been
> changed during Authorization.
> If i CANCEL then the From header is different (it's the same as i have
> before making my change).
>
> I am also using topology_hiding().
>
>
>
> under the main route i change the From header for INVITE
>
> set_advertised_address("104.13.xx.xx "); # same as i have used in
> the advertised_address
> # this is my cancel processing
> if (is_method("CANCEL")) {
> if (t_check_trans())
> t_relay(8);
> exit;
> }
> if (has_totag()) {
> if(topology_hiding_match())  {
># remove and add a custom one
>remove_hf("From");
>append_hf("From: \"$fU\"
> ;tag=$ft\r\n");
>
>  force_send_socket("tls:192.xx.xx.xx:5061");
>  }
> }
>
> My opensips version is 3.4.2
> My listening socket is socket=tls:ens192:5061 tag ens192 (its the same
> 192.xx.xx.xx IP that you see in the force_send_socket)
> I am also using public ip as follows
> advertised_address=104.13.xx.xx
> alias=104.13.xx.xx
>
>
> Regards,
> Jason
>
> On Thu, 21 Dec 2023 at 02:31, Bogdan-Andrei Iancu 
> wrote:
>
>> Hi Jason,
>>
>> In transactional stateful SIP, the CANCEL requests are hop by hop - each
>> hop in the path is generating its own CANCEL requests to the next hop,
>> which consumes it; there is no actual relaying of the CANCELs. So, the
>> replacing (which works in relaying mode only) doesn't fit here.
>>
>> Even more, the RFC3261 gives a rigorous way for building the CANCEL
>> requests, they are to be built 100% based on the INVITE request only
>> (nothing more). OpenSIPS internally builds the CANCEL in accordance to the
>> corresponding INVITE, so you should not need any such changes.
>>
>> May you detail why you think you need this FROM replacement?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>>   https://www.siphub.com
>>
>> On 20.12.2023 12:38, nz deals wrote:
>>
>> Hi,
>> I've been attempting to modify the From header in the CANCEL, but it
>> seems the changes aren't taking effect. I've also experimented with
>> remove_hf and append_hf, but unfortunately, these methods didn't work
>> either. Could someone kindly offer suggestions if I might be overlooking
>> something?
>>
>> This is in the main request route
>>
>> if (is_method("CANCEL")) {
>> uac_replace_from("","sip:t...@test.com");
>> if (t_check_trans())
>> t_relay(8);
>> exit;
>> }
>>
>>
>>
>>
>> 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] pn push notifications

[rvg]

hi all,

for your information:
**Sending a push notification to an iOS device using a Bash script**
https://medium.com/@egzon.arifi/sending-a-push-notification-to-an-ios-device-using-a-bash-script-96c056c1544c

I hope the pn in opensips only requires the route to the apn:
https://api.development.push.apple.com/. dev
https://api.push.apple.com/ opp

but I fear it does not.

Regards,

Ronald



January 15, 2024 at 10:57 AM, "Alexey"  wrote:


> 
> Hello,
> 
> there are two tutorials in the official blog:
> 
> part I : 
> https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/
> 
> part II : 
> https://blog.opensips.org/2020/06/03/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-ii/
> 
> -- 
> best regards, Alexey
> https://alexeyka.zantsev.com/
> 
> ___
> 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] pn push notifications

[rvg]

Adrian, thank you for the explanation. It is clear to me now. I will firstly go 
with a solution completely within openSIPS.

Regards,

Ronald



January 15, 2024 at 8:59 AM, "Adrian Georgescu"  wrote:


> 
> OpenSIPS handles the SIP traffic, of course. The push server just handles 
> multiple combinations of apps/ push services in an easier way. You could do a 
> lot or all that its needed just from within OpenSIPS but as the number of 
> combinations of apps and services grow another layer of abstraction make it 
> easier to manage, plus you eliminate another possible blocking item from your 
> routes as the works are down asynchronously outside OpenSIPS.
>  
> 
> —
> Adrian
> 
> > 
> > On 14 Jan 2024, at 20:33, r...@rvgeerligs.nl wrote:
> > 
> > Thank you very much, Adrian, 
> > 
> > I noticed it allready. It seems this is a dedicated push server.
> > Does it handle the normal SIP traffic as well?
> > 
> > Regards,
> > 
> > Ronald
> > 
> > January 14, 2024 at 3:13 PM, "Adrian Georgescu"  
> > wrote:
> > 
> > > 
> > > There are many ways of implementing push notifications with OpenSIPS. 
> > > This is how we implemented it.
> > > 
> > > https://github.com/AGProjects/sylk-pushserver/blob/master/config/opensips.cfg
> > > 
> > > —
> > > Adrian
> > > 
> > > > 
> > > > On 13 Jan 2024, at 17:37, r...@rvgeerligs.nl wrote:
> > > >  
> > > >  Hi All,
> > > >  
> > > >  
> > > >  I am trying to implement an opensips server 3.4 with pn support. 
> > > > Primarily apple push notifications. Later I will try google.
> > > >  
> > > >  Does any one have this implemented yet?
> > > >  
> > > >  Where can I find an example cfg for opensips?
> > > >  
> > > >  Any help is appreciated.
> > > >  
> > > >  
> > > >  Regards,
> > > >  
> > > >  
> > > >  Ronald Geerligs
> > > >  ___
> > > >  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] pn push notifications

[rvg]

Hi Alexey,

I noticed those too, but I do not understand the following code:

event_route [E_UL_CONTACT_REFRESH]
{
 route(PN_SEND, $(param(uri){param.value,pn-provider}),
 $(param(uri){param.value,pn-prid}),
 $(param(uri){param.value,pn-param}));
}

# $param(1) - PN provider
# $param(2) - PN PRID
# $param(3) - PN param
What is this doing? Is the contents of this part lacking? Is it the normal 
routing code, but the actual pn send is lacking? How do i write exec(what 
client) or rest_client?

route [PN_SEND]
{
 # send a PN using, for example, **exec** or **rest_client**
}
# how do we actually send the PN?


Regards,

Ronald



January 15, 2024 at 10:57 AM, "Alexey"  wrote:


> 
> Hello,
> 
> there are two tutorials in the official blog:
> 
> part I : 
> https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/
> 
> part II : 
> https://blog.opensips.org/2020/06/03/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-ii/
> 
> -- 
> best regards, Alexey
> https://alexeyka.zantsev.com/
> 
> ___
> 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] Removing header by contents

[Alexey]

Hello Igor,

these functions - isn't it what you need?

remove_hf_re(hname_expr) [1]
remove_hf_glob(hname_pattern) [2]

1. https://opensips.org/docs/modules/3.4.x/sipmsgops.html#func_remove_hf_re
2. https://opensips.org/docs/modules/3.4.x/sipmsgops.html#func_remove_hf_glob


-- 
best regards, Alexey
https://alexeyka.zantsev.com/

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

Re: [OpenSIPS-Users] pn push notifications

[Alexey]

Hello,

there are two tutorials in the official blog:

part I :  
https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/

part II : 
https://blog.opensips.org/2020/06/03/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-ii/

-- 
best regards, Alexey
https://alexeyka.zantsev.com/

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

Re: [OpenSIPS-Users] pn push notifications

[Adrian Georgescu]

OpenSIPS handles the SIP traffic, of course. The push server just handles 
multiple combinations of apps/ push services in an easier way. You could do a 
lot or all that its needed just from within OpenSIPS but as the number of 
combinations of apps and services grow another layer of abstraction make it 
easier to manage, plus you eliminate another possible blocking item from your 
routes as the works are down asynchronously outside OpenSIPS.
 
—
Adrian




> On 14 Jan 2024, at 20:33, r...@rvgeerligs.nl wrote:
> 
> Thank you very much, Adrian,
> 
> I noticed it allready. It seems this is a dedicated push server.
> Does it handle the normal SIP traffic as well?
> 
> Regards,
> 
> Ronald
> January 14, 2024 at 3:13 PM, "Adrian Georgescu"  >
>  wrote:
> 
> There are many ways of implementing push notifications with OpenSIPS. This is 
> how we implemented it.
> 
> https://github.com/AGProjects/sylk-pushserver/blob/master/config/opensips.cfg
> 
> —
> Adrian
> 
> 
> 
> 
> On 13 Jan 2024, at 17:37, r...@rvgeerligs.nl  
> wrote:
> Hi All,
> I am trying to implement an opensips server 3.4 with pn support. Primarily 
> apple push notifications. Later I will try google.
> Does any one have this implemented yet?
> Where can I find an example cfg for opensips?
> Any help is appreciated.
> Regards,
> Ronald Geerligs
> ___
> 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] DNS could not resolve hostname in dispatcher

[guillaume . desgeorge]

Hi Bogdan,
Thanks for your answer.
Issue opened : #3285
Regards,

  Guillaume Desgeorge


De : Bogdan-Andrei Iancu 
Envoyé : mercredi 10 janvier 2024 17:28
À : OpenSIPS users mailling list ; DESGEORGE 
Guillaume INNOV/IT-S 
Objet : Re: [OpenSIPS-Users] DNS could not resolve hostname in dispatcher

Hi Guillaume,

Indeed, a weird one, not marking the destination as failed upon failure to ping 
it. I checked the drouting module and it is doing such disable, so it might be 
a overlook in the dispatcher module. Please open a bug report on the github 
tracker, so we can address this issue.

Regards,


Bogdan-Andrei Iancu



OpenSIPS Founder and Developer

  https://www.opensips-solutions.com

  https://www.siphub.com
On 09.01.2024 11:32, 
guillaume.desgeo...@orange.com wrote:
Hi everyone,

We are facing a problem with Opensips 3.3 (but I've done tests on opensips 2.4 
and it was the same).

In the dispatcher, if we have a name instead of an IP address in "destination", 
and that the DNS falls down, we have an error "could not resolve hostname" in 
the log. Then, Opensips can't resolve the name, there is no more OPTIONS 
message sent to the destination but the state stays as 0 and if a call arrives, 
Opensips still route the INVITE to the last known IP address.

I find that's strange :

  1.  Either Opensips consider that the DNS is down but the destination may be 
still up with the last IP address he knows and he could still send OPTIONS 
messages to the last known IP address
  2.  Either Opensips consider that the DNS is down and doesn't send OPTIONS 
message but in that case he should not send INVITE to the old IP address.

I work with a product that has his own DNS and removes the name of the server 
in the DNS when the machine is down. So everytime the server is down, Opensips 
can't resolve the name and still send calls to that server...

Is there any parameters I can use to change that way of working ?

Regards,

Guillaume
Orange Restricted




Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.



___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users