Setting explicitly SCCPCallingGT and SCCPCalledGT via MProc

[faizann]

SCCPCallingDigits Currently SCCPCallingGT is set by copying the digits from ServiceCenterGT. In some cases like OCCompliance, the ServiceCenterGT holds more information by suffixing MNCMCC of originating operator. The SCCPCallingGT in this case is the actual GT that can be used for routing and hence the difference between 2 GTs in MAP and SCCP layers.

SCCPCalledDigits There are also cases where the SRI/MTFSM needs to be directed to a specific HLR/MSC. We already have that handled via networkID where hlrDestinationAddress of a SRI can be setup. This works well for smaller routing cases but having that field overridden by MProc rule would give a lot more flexibility to business logic and control over routing.

[faizann]

What I propose here is setting following fields via MProc

localsccpgt localsccptt

remotesccpgt remotesccptt

[vetss]

Hello @faizann

thanks for opening of an issue and provided info.

Now we have a limited implementation for MT only and only mtlocalgt and mtremotett (https://github.com/RestComm/smscgateway/issues/252). This implementation means that service center address in MAP part is not changed after any updates. Calling (for GT digits) and called (for TT) party addresses are updated in case of mproc rules applying. This affects MT procedure (for both local originated dialogs SRI and MT).

I see you want to add of processing of called (for GT digits) and calling (for TT). Another question which other dialogs except of I described in MT procedure we need to affect. We have also MO and HR procedures, but only HR "sending a SRI request to a local HLR" dialog is a local originated. I mean that other dialogs are remote originated and SccpAddresses are specified by a peer. Please explain how we need to process HR / MO. Let's discuss it in short time so we can create a proper syntax of CLI.

[faizann]

Hi @vetss

My idea would be to have mtlocalgt for both serviceCenterGT in MAP and callingSccp in SCCP layer unless localcallingsccpgt is not null/empty. So, it is kind of a lower level control if someone wants it for setting SCCP layer GTs.

callingGT overriding via MProc would affect all outbound SRI and MTFSM. This applies for HR and SRI and MT SBBs. I don't think we need to set callingGT/calledGT for remote originated dialogs. This is all for LOCAL originated dialogs.

[vetss]

Hello @faizann

For MT procedure:

a) SRI request SCCP part:

• callingParty TT / calledParty TT - we can change it localsccptt / remotesccptt
• callingParty GT digits (== SMSC GW GT) - we can change it localsccpgt
• calledParty GT digits (== MSISDN) - do we really need to update it ?

b) SRI request MAP part:

• MSISDN - do we really need to update it ?
• ServiceCentreAddress - we can change it localsccpgt (so we need to chage both "callingParty GT" + "ServiceCentreAddress") by the same parameter

c) MT request SCCP part:

• callingParty TT / calledParty TT - we can change it localsccptt / remotesccptt
• callingParty GT digits (== SMSC GW GT) - we can change it localsccpgt
• calledParty GT digits (== MSISDN) - do we really need to update it ?

d) MT request MAP part:

• SM_RP_OA.serviceCentreAddressOA - we can change it localsccpgt (also same parameter localsccpgt ?)

Not clear for me to what will affect remotesccpgt parameter.

ok, so as for your explanation:

• we affect only outgoing dialogs (SRI and MT for MT procedire and outgoing SRI for HR procedure)
• we affects both MAP and

For HR procedure:

We do the same as for SRI in MT procedure, correct ? Also we need to uderstand that no mproc rule trigger can be used for this update. HrSri trigger occures already after we have sent SRI in a HR procedure. So implementation will far more complicated IMO.

Please commant if I am right in my description. What is "localcallingsccpgt" parameter that you mentioned ?

[faizann]

For this discussion localscgt is the value that is set for ServiceCenterAddress in MAP layer by mproc. localsccpgt is the value that can be set from mproc for callingSccpGt in SCCP layer. remotesccpgt is the value that is set as calledSccpGt in SCCP layer by mproc.

For MT procedure:

a) SRI request SCCP part:

• callingParty TT / calledParty TT - we can change it localsccptt / remotesccptt
• callingParty GT digits (== SMSC GW GT) - we can change it localsccpgt
• calledParty GT digits (== MSISDN) - do we really need to update it ?
  [Faizan] remotesccpgt. Yes we do. This is useful for sending SRI to a specific HLR. This is very common in routing where HLR GT is already known and is used for sending of outbound SMS instead of sending to the end operator directly.

b) SRI request MAP part:

• MSISDN - do we really need to update it ? I don't think we need to update the MSISDN.
• ServiceCentreAddress - we can change it localsccpgt (so we need to chage both "callingParty GT" + "ServiceCentreAddress") by the same parameter.
  [Faizan] I don't think this helps. The idea is to have different addresses in SCCP and MAP layers. So, localscgt will have to be a different parameter. For example, customer SMSC GT is 5551234 but they are asked to provide our SCGT as OC Compliant. Then in this case our ServiceCenterGT will have MNCMCC suffixed. ServiceCenterAddress will become 555123420406 (upto the max digits allowed in the protocol). Hence, we need separate fields to control localsccpgt and localscgt.

c) MTFSM request SCCP part:

• callingParty TT / calledParty TT - we can change it localsccptt / remotesccptt
• callingParty GT digits (== SMSC GW GT) - we can change it localsccpgt
• calledParty GT digits (== MSISDN) - do we really need to update it ?
  [Faizan] This is not really needed for typical MT SMS request but I have seen one situation where this applied in combination with IMSI in M2M messaging. In such cases the MSC and IMSI was taken from a local DB in M2M SMS and hence no SRI is needed. I am ok if we take this case later as a separate issue. We can ignore remotesccpgt for this case.

d) MTFSM request MAP part:

• SM_RP_OA.serviceCentreAddressOA - we can change it localsccpgt (also same parameter localsccpgt ?).
  [Faizan] I think we should keep localsccpgt separate and call everything that goes here as localscgt. The rule to use the field from mproc would look like this
  

  set mapdialog.callingSccpGt = localscgt<br>
  if localsccpgt is not empty then <br>
  set mapdialog.callingSccpGt = localsccpgt<br>
  endif

ok, so as for your explanation:

we affect only outgoing dialogs (SRI and MT for MT procedire and outgoing SRI for HR procedure) we affects both MAP and
[Faizan] Yes give access to both MAP and SCCP. For HR procedure:

We do the same as for SRI in MT procedure, correct ?
[Faizan] YES

Also we need to uderstand that no mproc rule trigger can be used for this update. HrSri trigger occures already after we have sent SRI in a HR procedure. So implementation will far more complicated IMO.
[Faizan] This is true that HR does outbound SRI directly and there is no MProc rule invoked in the flow. We should add an MProc PreImsiRequest where we get control on the SRI. This is also useful for rejecting the SMS at SRI level instead of MTFSM.

Please commant if I am right in my description. What is "localcallingsccpgt" parameter that you mentioned ?
[Faizan] I meant localsccpgt the GT that can be set for SCCPCallingGT for outbound SRI/MTFSM.

[Faizan] I know I am asking for a lot of flexibility in routing via MProc but all the scenarios I have shown are from real world experience.

[vetss]

Hello @faizann

Here is my summary for parameters and actions, please check and confurm that they are proper described :

For MT procedure:

New mproc actions : mtlocalscgt is the value that is set for ServiceCenterAddress in MAP layer by mproc. mtlocalsccpgt is the value that can be set from mproc for callingSccpGt in SCCP layer. mtremotesccpgt is the value that is set as calledSccpGt in SCCP layer by mproc. mtlocalsccptt is the value that can be set from mproc for callingSccp TT in SCCP layer. mtremotesccptt is the value that is set as calledSccp TT in SCCP layer by mproc.

a) SRI request SCCP part:

• callingParty TT / calledParty TT - we can change it by mtlocalsccptt / mtremotesccptt
• callingParty GT digits (== SMSC GW GT) - we can change it by mtlocalsccpgt
• calledParty GT digits (== MSISDN) - we can change it by mtremotesccpgt

b) SRI request MAP part:

• MSISDN - we will not update it
• ServiceCentreAddress - we can change it by mtlocalscgt

c) MTFSM request SCCP part:

• callingParty TT / calledParty TT - we can change it by mtlocalsccptt / mtremotesccptt
• callingParty GT digits (== SMSC GW GT) - we can change it by mtlocalsccpgt
• calledParty GT digits (== MSC/VLR GT) - we will not update it

d) MTFSM request MAP part:

• SM_RP_OA.serviceCentreAddressOA - we can change it by mtlocalscgt

We affect only outgoing dialogs (SRI and MT for MT procedire and outgoing SRI for HR procedure)

IMPORTANT: I suppose that all parameters (like mtlocalscgt and others) will affect BOTH SRI and MTFSM outgoing requests. I mean we do not need a separate for example mtlocalscgt parameter for SRI and MTFSM messages. Please confirm that I am right.

For HR procedure:

New mproc actions : hrlocalscgt is the value that is set for ServiceCenterAddress in MAP layer by mproc. hrlocalsccpgt is the value that can be set from mproc for callingSccpGt in SCCP layer. hrremotesccpgt is the value that is set as calledSccpGt in SCCP layer by mproc. hrlocalsccptt is the value that can be set from mproc for callingSccp TT in SCCP layer. hrremotesccptt is the value that is set as calledSccp TT in SCCP layer by mproc.

Parameters will affect to outgoing SRI requests to a local HLR.

We should add a new MProc trigger HrPreSri where we get control on the SRI. (This trigger is also useful for rejecting the SMS at SRI level instead of MTFSM, we can add also this action).

We need to make a HR update as a separate step because it is much more complicated.

[faizann]

Hi @vetss

Yes this look very good to me and as to your question, there is indeed no need for separate parameter names for SRI and MTFSM.

HR Mproc we can do separate.

Do you want me to pick this issue?

[vetss]

Hello @faizann

Do you want me to pick this issue?

Yes, please. Let me also finish the first issue so you will be able to provide your update on the top of this. I mean #252

[vetss]

Hello @faizann

I have some doubts for the case when we are going to change any parameters in SRI messages. We may have several messages for a single dest address and for some of such messages we may have updated mtlocalscgt or other mtsccp parameters. SMSC GW sends a single SRI address for all pending MT messages (because of all messages belongs to a same networkID). Which parameters to use for a SRI request in this case ? We can reuse of a parameters of a first SMS in a queue. Is it good enouph ?

PS: changing of logic when we will send a new SRI befor a next MT message if parameters for a next message was different as compared with a first one is a rather compicated task (:

[faizann]

Hi @vetss

Indeed changing that logic is too much work and seems unnecessary. SRI can be only once and MT can use the SRI cached info.

You might think that why we even need calledGt to be different for MTFSM since that is taken from SRI response.

Here, I have actually mixed 2 issues and I should have explained better I wanted to keep this issue clean. I have had a case in M2M messaging where SRI is not needed at all. The MTFSM needs 2 pieces of information. IMSI and MSC(calledGT). This information was available pre-hand from another source and hence only MTFSM was enough to deliver the SMS without SRI, thus reducing the overall SS7 traffic. I have not mentioned setting of IMSI in any tickets yet.

So, this means we still need the ability to change mtremotesccpgt for both SRI and MTFSM depending on the case. The SRI caching of course should be used as it is and no logic change is needed.

Thanks

[vetss]

@faizann

I suppose we do not take into account a case when "SRI is not needed at all" for this issue, so we send SRI in any case. Do I understnd you properly ?

"we still need the ability to change mtremotesccpgt for both SRI and MTFSM depending on the case" - AFAIR mtremotesccpgt parameter does not affect MT message (only a SRI message) - check my pevious message. Can you explain more how should it work ? For SRI it means that we change calledPartyMessage digits from MSISDN to some value. For MT message - do you mean we need to ignore SRI response with MSC/VLR address too ?

For one SRI for several MT messages to the same destination address. "SRI can be only once and MT can use the SRI cached info." Let imagine a case when we changed only mtlocalsccpgt for a message 1 and for message 2 to diffferent addresses (x1 and x2). Then the messageflow may be: SRI: with callingPartyAddress x1 MT 1: with callingPartyAddress x1 MT 2: with callingPartyAddress x2 Both MT 1 and 2 requests reuse SRI results (IMSI / VLR address) or SRI 1: with callingPartyAddress x1 MT 1: with callingPartyAddress x1 SRI 2: with callingPartyAddress x2 MT 2: with callingPartyAddress x2 What is a desired approach ?

As for SMSC GW current implamenation we do not really have a "SRI cache". SMSC GW takes a set of messages for a single destination address (==SmsSet) then sends one SRI for them and then sends a set of MT messages. If a new message to same dest address comes some time later then a new SRI will be made.

[faizann]

Hi @vetss

Yes we send SRI in this case always.

In the case of 2 messageFlows you mentioned the first one is the desired one even if it looks a bit odd. I see it as an option to the Mproc rule creator to use it like that or not touch the callingParty for MTFSM at all. I expect that in a typical SMS flow most people will only want to change the callingParty for SRI only and MTFSM will just use the one that was used for the SRI.

By SRI cache I meant the 60 second SRI Response cache that is used for all SMS in the SMSSet to avoid sending SRI again in short time. That will not need to be touched at all.

[vetss]

@faizann

if you think we can chanfe an address for SRI or MT or SRI+MT then we need to have different settings for mt and sri like mtremotesccpgt and sriremotesccpgt. Do I understand you properly ? If yes we need to checnge a desctiption of an issue.

And from your description of SRI requests sending I understand that responses from SRI requests may be reused for any other further MTFSM requests (for same MSISDN (dest address) of cause) and it does not matter if for SRI some changes of sccp addresses or other parameters was made. I still have some doubts if it is true for all cases (not sure here). Can we anasyse several use cases to be sure that this is true.

The reusage of same SRI request for several MT messages is easier to implement instead of caching of SRI responses for different SRI setting for the same dest address.