| MSISDNHeaderPrefixConvert for recipient addresses |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through April 05, 2007 ⬆ |
◄ ► |
| Author | Message | |||
| Dziugas Baltrunas New member Username: Menulis Post Number: 13 Registered: 02-2006 |
Hi, I'm recalling last year's thread (http://support.nowsms.com/discus/messages/485/15769.html) regarding MSISDNHeaderPrefixConvert. Are there any plans to implement (or adopt similar configuration option for recipient addresses in NowSMS 2006? I would expect this option to be identical in syntax with MSISDNHeaderPrefixConvert but handle only recipient MSISDNs and most probably happen after (or before, but switchable) normalization (internationalization) of recipient address according to country code present X-MSISDN WAP header. Thanks, Dziugas | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6929 Registered: 10-2002 |
Hi Dziugas, It would probably help to work through some real world examples, but I think everything is working properly in NowSMS 2006, at least with all versions since v2006.06.23 when a change was made related to the thread that you reference. 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 -bn | |||
| Dziugas Baltrunas New member Username: Menulis Post Number: 14 Registered: 02-2006 |
Hi, Bryce, Indeed, having MSISDNHeaderLocalPrefix=8 set things now work correctly. And actually it's not necessary to have MSISDNHeaderDefaultCountryCode=370 since country code is coming from WAP gateway's MSISDN header. However, configuration is not suitable when you are serving different countries. Let me introduce with an example (having MSISDNHeaderLocalPrefix set to 8): Sender: +37061111111 Recipient: 860000000 Result: +37060000000 (correct) Sender: +37121111111 Recipient: 81234567 Result: +3711234567 (incorrect, should be +37181234567, since 8 in Latvia is not a “local prefix”) NowSMS internationalization based on sender address is not a bad thing, but since different countries might have different rules, I would propose to implement an option for defining more generic recipient address translation rules. As far as I understand, currently MSISDNHeaderLocalPrefix works in a simple way: if recipient address in not in international format and begins with MSISDNHeaderLocalPrefix, it is being removed. Then goes an internationalization based on sender address (or MSISDNHeaderDefaultCountryCode, if sender’s MSISDN provided by WAP GW is not in international format). Furthermore, at the moment address translation never happens if MMS message comes from VASP, i.e. it’s only applied for MM1 requests. Thus there is no possibility to “correct” recipient addresses for MM4 or other traffic. My proposal is to define general address translation rules based on both source and destination addresses and for all possible (i.e. MM1, MM4, MM7) requests. Suggested several options: 1. MSISDNRecipientPrefixConvert=xxx:yyy:zzz, where xxx – sender prefix, yyy – recipient prefix, zzz – modified recipient prefix. Wildcards or placeholders might be accepted. 2. Separate address translation callback similar to routing callback except that script would be called for every MMS send attempt from any source and should return modified recipient (and possibly sender) address, i.e.: To=+37061234567. 3. Add recipient number translation to existing PreAuth callbacks. Proposal is not yet complete but I think that most of us would benefit from dynamic callback-based solution since it would eliminate the need of many configuration directives: LocalNumberPrefix, LocalNumberMaxLength, ShortCodeMaxLength, MSISDNHeaderDefaultCountryCode, MSISDNHeaderLocalPrefix, MSISDNHeaderDNCode, MSISDNHeaderDNOffsetMin, MSISDNHeaderDNOffsetMax and probably some others. Regards, Dziugas Baltrunas | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6936 Registered: 10-2002 |
Hi Dziugas, Yes, it is a problem if you are handling separate countries. Indeed, we have adapted a variety of different settings to accomodate different customer requirements. For example, an operator in the US had the requirement for dealing with US area/city codes. To call a user in the same area/city code, the user is typically not required to enter the area/city code, just the local number. So we have some settings and rules to handle this, determining the appropriate destination number based upon the area/city code of the sender. We also have customers dealing with multiple country codes. But this does require that each country code have the same local prefix. There is definitely a problem if you are supporting multiple countries with different local prefixes (or one that doesn't typically use a local dialing prefix, and one that does). You've made some good suggestions, but I've got to balance them with a thought toward what can we implement quickly to address the underlying problem, without introducing a change that could impact other customers. The callback, in particular, is a great idea, minimal impact on others (would be active only if configured), but I don't think it could be turned around real quickly from development. What I think could be implemented real quickly is this ... Multiple MSISDNHeaderLocalPrefix settings that can vary by country. For you, it would work like this: MSISDNHeaderLocalPrefix370=8 MSISDNHeaderLocalPrefix371=0 or if there is not a local prefix used in Latvia: MSISDNHeaderLocalPrefix370=8 MSISDNHeaderLocalPrefix371= (Technically the second entry isn't really necessary, but it is good to include for clarity, as if "MSISDNHeaderLocalPrefixCCC" is not found, the "MSISDNHeaderLocalPrefix" setting would be used.) You are correct that the conversions are only applied to MM1 traffic ... not to MM4 or MM7. It would be more difficult to apply for those protocols. In MM4, the recipient should already be internationalised by the submitting system. In MM7, it is more difficult as it is very likely that the sender will be a short code, so we would likely require another VASP parameter to indicate the default country code for the VASP. Let's have more dialog on the MM4/MM7 issue. Meanwhile, I hope we'll have an update to add support for the per-country code local prefix settings in the next day or two. -bn | |||
| Nelson New member Username: Nelson Post Number: 14 Registered: 01-2006 |
Hi Bryce, Sorry to jump into the middle of this thread, but can you explain the relevant settings for this setup: For example, an operator in the US had the requirement for dealing with US area/city codes. To call a user in the same area/city code, the user is typically not required to enter the area/city code, just the local number. So we have some settings and rules to handle this, determining the appropriate destination number based upon the area/city code of the sender. I am working with a client where I believe this will be an issue. Cheers, nelson | |||
| Dziugas Baltrunas New member Username: Menulis Post Number: 15 Registered: 02-2006 |
Hi, Bryce, Thanks for the answer. To note, for now it is not an issue for us, since in Latvia there is no national prefix. So at least from our side there is no hurry for a quick workaround at the moment. Therefore I would better vote for solution which would be more generic one (such as callbacks) and feasible in long-term period. Thanks, Dziugas Baltrunas | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6959 Registered: 10-2002 |
Hi Dziugas, As long as Latvia doesn't have any mobile numbers that start with "8", you will be ok. We did implement an update with the logic that I described above. But I won't post that for now ... and we'll look at the possibility of implementing a callback in the future. -bn | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6960 Registered: 10-2002 |
Hi Nelson, The particular setting that I referenced is probably only going to work for the US ... although I guess it would also apply to other territories in North America that are part of country code "1". It only works if the city/area code has a fixed length. (And I know in a lot, if not most countries, this is not a fixed length.) The following settings in MMSC.INI enable this logic for country code 1: CityCodeLength=3 LocalNumberMaxLength=7 MSISDNHeaderDefaultCountryCode=1 When "CityCodeLength" is set, if an MMS message sender sends a message to a recipient of exactly "LocalNumberMaxLength" digits, the MMSC will parse "CityCodeLength" digits after the country code from the sender address, and apply the city code and country code to the recipient. As I think about it, this is all pretty specific to the country code "1" numbering plan, and probably has limited applicability outside of the plan. If you have a different scenario that this does not address, I'd like to hear the details. -bn | |||
