[Spce-user] EEA and nonEEA Calle/Caller Pattern differentiation for Peering Group in mr5.5.2

Wed Feb 14 17:35:56 EST 2018

I thought about it again and wrote all together:

* I only want to allow a particular Subscriber to make calls outside via 2 specific peering groups.

* Which of the 2 peers the subscriber uses should be matched against the source and destination number.

* If call with country code "43 or 49" and destination "43 or 49" then peer 1.

* If call with country code "43 or 49" and destination NOT "43 or 49" then peer 2.

* If call with country code NOT "43 or 49" then peer 2.

* All other subscribers should call outside via peer 3.

* If an emergency call comes with Callee prefix "emergency_", then the call should also be made via peer 3.

Although I can set it up by editing the Callee Pattern and the Caller Pattern, this will apply to all subscribers.

I need the ability of a peering group to say that it can only accept calls from that subscriber, as well as telling another peering group to accept all calls from subscribers other than a particular subscriber.

Idea 1:

I would solve this with a negative lookahead. => If the subscriber had the username 4311111, then that would be ^ sip: (?! (4311111)). + $

My problem now is that I can’t test against the username.

Idea 2:

I could now edit the proxy.cfg:

proxy.cfg:

> $ var (lcr_match_content) = "sip:" + $ avp (s: first_caller_cli_userprov) + "@" + $ avp (s: caller_domain_netprov);

> xlog ("L_NOTICE", "Load gws matching calling part '$ var (lcr_match_content)' and called user '$ rU' and called part '$ ru' - [% logreq -%] \ n");

> 

> Replace $ avp (s: first_caller_cli_userprov) with "$ avp (s: acc_caller_user)" in the lcr_match_content.

However, if I do that, I lose the caller pattern and can’t do my above comparison.

So I would need an extra field or hardcoden it somewhere, so I can define the username. => a "Caller Prefix / Username" field, so to speak.

Idea 3:

My idea was to alienate the field "callee prefix" = "$ var (lcr_rU)" for purpose and to rewrite it internally so that this queries just against the username.

In proxy.cfg this is currently defined as: "$ var (lcr_rU) = $ rU;" and change that to "$ var (lcr_rU) = $ avp (s: acc_caller_user);"

I do not know where else this field is interrogated or in use.

Also, I do not know what impact this has on calls with an "emergency_prefix".

If the "emergency_prefix" can also be read out of the "Called Part" field, then you could create a "Callee Pattern" for this, and thus do the emergency call routing to a specific peering, but I suspect that the "Callee Pattern" is not is preferred, because the priority of Outbound Routing Rules is queried on the basis of the "Callee Prefix" and if it should be empty, according to the priority of the Peering Group.

Say, with this solution, it would be good if you next to "Callee Prefix" queries the "Callee Pattern", before the Peering Group priority is preferred.

Idea 4:

An alternative would be to set an inbound callee rewrite rule for the subscriber and thus define a "callee prefix", which will then be used in a peering group. Thus, all calls through this subscriber would be forwarded there, but then I have the problem that I would have to provide the billing profile with this prefix, otherwise every call would stop the rate-o-mat. I also think that this is not a clean solution.

Idea 5:

One would have to be able to assign several peering groups to a subscriber directly, so that this only ever this use and otherwise none.

Or you just have to have an extra field in the Outbound Routing Rule where you can allow or deny a specific subscriber the use of this peering group.

What do you think about this? Is there any way to fix this?

Thank You for your help.

Von: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Hohl Matthias
Gesendet: Mittwoch, 14. Februar 2018 14:51
An: 'Rene Krenn' <rkrenn at sipwise.com>; 'Spce-user' <Spce-user at lists.sipwise.com>
Betreff: Re: [Spce-user] EEA and nonEEA Calle/Caller Pattern differentiation for Peering Group in mr5.5.2

Hello,

i validate it today with an online validator and it looks like booth is working:

Variant 1:   ^sip:(?!(43|49|3222)).+$

Variant 2:   ^sip:(?!43|49|3222).+$

But this not: ^sip:?!(43|49|3222).+$

it is necessary to add the “sip:” in front to identify, that the match pattern is directly on beginning of the number.

Do I also need a pattern in this format “sips:” for TLS calls? 

I tested it now with a simplier pattern, but found out another problem with the right peer routing and run out of order to find a solution…

My biggest problem is that “callee prefix” identifying is the highest priority and that I can’t set this prefix directly on subscriber and need to greate a rewrite rule for that.

How do I set this “callee prefix” without breaking my rate-o-mat?

I tried with a rewrite rule on subscriber manipulating the “inbound rewrite rule for callee” and set there a prefix but this will break rate-o-mat.

Also I tried around a bit to find another solution, but if “callee_prefix” will be always be on highest priority I can’t use this peering group with a lower priority like my main peering group…

Can anybody can give me the right advice how I can force a subscriber to place calls primary over a specific peering?

Von: Rene Krenn [mailto:rkrenn at sipwise.com] 
Gesendet: Mittwoch, 14. Februar 2018 00:51
An: 'Hohl Matthias' <matthias.hohl at telematica.at <mailto:matthias.hohl at telematica.at> >; 'Spce-user' <Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com> >
Betreff: AW: [Spce-user] EEA and nonEEA Calle/Caller Pattern differentiation for Peering Group in mr5.5.2

>should I change it there also?

Yes. Also, the lookbehind should be delimited by enclosing parantheses.

^sip:(?!(43|49|32)).+$

Furthermore the lookbehind regexp-part is subject to some limitations, depending on the engine (see  https://www.regular-expressions.info/lookaround.html). It explicitly states alternation groups like above are possible but eg. perl seem to require egual-length substrings (which is fine for 43800, 43810, .. -> they all have a length of 5).

It‘s otherwise a good idea to try the regexp either in mariadb console or at an (online) tester.

regards

Von: Hohl Matthias [mailto:matthias.hohl at telematica.at] 
Gesendet: Mittwoch, 14. Februar 2018 00:29
An: 'Rene Krenn' <rkrenn at sipwise.com <mailto:rkrenn at sipwise.com> >; 'Spce-user' <Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com> >
Betreff: AW: [Spce-user] EEA and nonEEA Calle/Caller Pattern differentiation for Peering Group in mr5.5.2

Hey Rene,

Thank for confirmation… I will test it tomorrow… 

About “in front of”:

In our last conversation about negative lookahead in the billing profile, I also used it inside the capturing group… 

^(?!43800|43810|43820|43821|43900|43930|43901|43931|43939).+$

As I can remember, this also worked… should I change it there also?

Von: Rene Krenn [mailto:rkrenn at sipwise.com] 
Gesendet: Dienstag, 13. Februar 2018 23:08
An: 'Hohl Matthias' <matthias.hohl at telematica.at <mailto:matthias.hohl at telematica.at> >; 'Spce-user' <Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com> >
Betreff: AW: [Spce-user] EEA and nonEEA Calle/Caller Pattern differentiation for Peering Group in mr5.5.2

Hi,

basically sounding; the deny case is the interesting one, you should try to pull that negative lookahead in front of the the capturing group:

Callee Pattern: ^sip:?!(43|49|32).+$

regards

Von: Spce-user [mailto:spce-user-bounces at lists.sipwise.com] Im Auftrag von Hohl Matthias
Gesendet: Dienstag, 13. Februar 2018 22:48
An: 'Spce-user' <Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com> >
Betreff: [Spce-user] EEA and nonEEA Calle/Caller Pattern differentiation for Peering Group in mr5.5.2

Hello,

i need your REGEX help…

I need to allow and deny calls from a subscriber with a specific NPN to a peering group.

1.)    Allow:

Every call from a subscriber with a NPN beginning with country code 43, 49 or 32 calling a number in country 43, 49 or 32 should be allowed to place the call over this peering group.

Every other country code, for example +1 and +86, should NOT be allowed to place a call over this group.

Callee Pattern: ^sip:(43|49|32).+$

Caller Pattern: ^sip:(43|49|32).+$

2.)    Deny:

Every call from a subscriber with a NPN beginning with country code 43, 49 or 32 calling a number in country 43, 49 or 32 should NOT be allowed to place the call over this peering group.

Every other country code, for example +1 and +86, should be allowed to place a call over this group.

Callee Pattern: ^sip:(?!43|49|32).+$

Caller Pattern: empty

Are this the right pattern for my scenario?

Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20180214/c9d25252/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5532 bytes
Desc: not available
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20180214/c9d25252/attachment-0001.p7s>