Recepient Prefix Conversion

Recepient Prefix Conversion SearchSearch
Author Message
sam
Posted on Sunday, December 27, 2009 - 03:36 pm:   

Hi

Refering to post http://support.nowsms.com/discus/messages/485/20148.html. The following settings should work properly for your configuration (NowSMS v2006.06.23 or later):

MSISDNHeaderDefaultCountryCode=370
MSISDNHeaderLocalPrefix=8

The following are example conversions:

37061234567 ==> +37061234567
861234567 ==> +37061234567
+37061234567 ==> +37061234567

I see that the above is not applied to the recepient/receivers mobile number. If a mms is sent to a number without the country code and leading zero (061234567) then the recepient/receivers mobile number processed by nowmms is still 061234567. In my case I have used MSISDNHeaderLocalPrefix=0. I belive this should be 37061234567. Is this assumption correct? Following are my settings:

MSISDNHeaderDefaultCountryCode=370
MSISDNHeaderLocalPrefix=0

Or the above 2 settings only apply to Incomming MSISDN values only and not on recepient/receivers mobile number?

Kindly let me know

Thanks
Sam
stefan venter
New member
Username: 0725214357

Post Number: 1
Registered: 12-2009
Posted on Thursday, December 31, 2009 - 08:28 am:   

I want to be able to read my mms
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1617
Registered: 08-2008
Posted on Monday, January 04, 2010 - 04:22 pm:   

Hi Sam,

Are you referring to the same installation as that other thread? Or is this a different installation with similar settings?

If the recipient address is not being converted at all (no international prefix added), then this suggests that the sender address is not being internationalised ... that the MMSC is having a problem decoding the sender address.

Can I see the complete MMSC.INI?

Also, a few lines from MMSC-yyyymmdd.LOG showing some send attempts.

From those lines in the MMSC log file, indicate how you believe the phone numbers should have been converted.

--
Des
NowSMS Support
sam
New member
Username: Samdsouza

Post Number: 2
Registered: 08-2006
Posted on Wednesday, January 06, 2010 - 12:13 pm:   

Hi Des

Thanks for the inputs. After going through the discussion board messages have figured this one out. I guess this conversions also factor the Incomming MSISDN values.

Basically what i wanted to test is that suppose a MMS is submitted with a leading/prefix "0" (which people would generally add/keep the local/country specific mobile numbers) then this leading/prefix 0 should be replaced by the country code so that the receipient number is handled correctly for the wap/mms push connection.

Also wanted to understand what would be the best way for 2 nowmms to talk to each other? Via mm7 or smtp?

Kindly let me know

Thanks
Sam
sam
New member
Username: Samdsouza

Post Number: 3
Registered: 08-2006
Posted on Thursday, January 07, 2010 - 06:21 am:   

Hi Des

I belive the best way would be MM4 for connectivity between multiple MMSCs. Kindly correct me if am wrong.

Also there is one issue which is puzzling me. Am not able to send and receive MMS via the default WAP APN of the Operator.

Strangely I can browse/access the MMS notifications on the browser using the same default WAP APN of the Operator.

That means the IP/Domain of nowmms is working on the default WAP APN of the Operator on the browser. Why then it doesnt allow to send/receive MMS via the handset? Is there some settings to be done on nowmms to resolve this?

The Internet APN works fine for both sending and receving mms on the handset.

Kindly let me know

Thanks
Sam
sam
New member
Username: Samdsouza

Post Number: 4
Registered: 08-2006
Posted on Thursday, January 07, 2010 - 12:04 pm:   

Hi Des,

I think have figured out the above issue. Had MSISDNHeaderGateways active on the MMSC.ini which didnt allow the wap apn IPs to access the nowmms gateway. After i removed MSISDNHeaderGateways the wap apn was able to access the nowmms gateway.

The issue is that if i disable MSISDNHeaderGateways then spoofing is possible right? "This is to prevent forged requests, where another gateway or application inserts an MSISDN header to attempt to fool the MMSC. "

How can i prevent this if possible?

Kindly let me know

Sam
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 1637
Registered: 08-2008
Posted on Thursday, January 07, 2010 - 08:28 pm:   

Hi Sam,

Sorry I've been slow on responding.

Let me catch up on some of your questions.


quote:

I believe the best way would be MM4 for connectivity between multiple MMSCs.




That is correct.

Regarding the use of different APNs, and the MSISDNHeaderGateways setting, a lot depends on the specifics of your configuration.

Let me explain ...

For IP based services, the WAP gateway is responsible for matching up an IP address with the device MSISDN.

The WAP gateway knows this because it receives a RADIUS accounting feed from the access server which tells it everytime a user connects or disconnects from the APN. (With multiple APNs, you may have multiple access servers with different accounting feeds.)

When someone sends an MMS message, the WAP gateway inserts an MSISDN header into the data stream so that the MMSC can identify who sent the message.

The MSISDNHeaderGateways setting tells the MMSC which gateways are trusted for sending the MSISDN header.

If the MMSC is well firewalled, so that only your WAP gateways can connect to it, you could skip using this setting.

If it's not firewalled, and it is possible for mobile devices to connect directly to the MMSC, then it's a good idea to use MSISDNHeaderGateways as an additional layer of protection against forging.

The MSISDNHeaderGateways setting can have a comma delimited list, and it can also include wildcards in any of the IP address positions ... for example:

MSISDNHeaderGateways=10.20.2.*

or

MSISDNHeaderGateways=10.20.2.2,10.20.3.2,10.20.3.3

Hopefully this helps explain it?

--
Des
NowSMS Support
sam
New member
Username: Samdsouza

Post Number: 5
Registered: 08-2006
Posted on Thursday, January 14, 2010 - 07:30 am:   

Hi Des

Thanks for your inputs. The support provided here on the Discussion Board has been excellent and very informative. Hats off to you people.

Regards
Sam