| SMPP Bind Error & SMPP Invalid Password Error |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through January 23, 2007 ⬆ |
◄ ► |
| Author | Message | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 72 Registered: 04-2005 |
Hello Bryce, I have two problems which are making troubles these days mostly: 1. First problem: As you can see below on the attached txt SMPPDEBUG Log file, NowSMS gateway is keeping try binding even the SMPP connection is up, and I am getting as SMPPBind & SMPPUnbind from the SMSC of mobile operator, so How can I disable these SMPPUnbind & SMPPBind when the SMPP is up? Because this mobile operator is getting over traffic request from NowSMS and told me to solve this problem. 2. Second Problem, as you can see on the attached Print screen, I have one SMPP account within 3 months, but I am getting Invalid Password Error. My Mobile operator is telling me that my account is working fine and he tested it from another SMPP client. He changes my account 3 times and I change server to server to see but I am getting same error, how can I know really where there are the Problem? Because telnet is working fine on the SMPP specified port. Your help Bryce will be highly appreciated. Salim
 | |||||||
| Darek Chorazewicz New member Username: Daro Post Number: 45 Registered: 03-2004 |
Hi. According to second question. shouldn't you use Isys and 5Isys5 as username and password? | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 73 Registered: 04-2005 |
Hi, No, thank you, they were separate Usernames & Passwords as two SMPP accounts. But I got solution now, the problem was from the Mobile Operator itself from their SMSC settings regarding my SMPP account TON & NPI. For the first question what I am suspecting is may be that NowSMS is losing the SMPP connection to the SMSC, so it's trying to bind again, but why it binding even the connection is existing, this what it's making me think alot. Regards, Salim | |||||||
| Darek Chorazewicz New member Username: Daro Post Number: 47 Registered: 03-2004 |
Hi. Could you tell what TOP/NPI were valid for you bcoz I have the same SMPP error - bind failed and I'm looking for a reason why. | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 74 Registered: 04-2005 |
Hi Darek, TON and NPI are using in SMPP "Advanced Settings". There are some thread already available and you can read more as below links: http://support.nowsms.com/discus/messages/1/16578.h tml http://support.nowsms.com/discus/messages/1/16578.h tml http://support.nowsms.com/discus/messages/1/16578.h tml http://support.nowsms.com/discus/messages/1/16578.h tml any way, if still you din't get more and clear explanation, give some details for which kind of problem you are facing, we can share our experience with NowSMS. Regards, Salim | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 75 Registered: 04-2005 |
Hi Bryce, I have one problem, I read in the forum how to add extra parameter in SMPPOptions in NowSMS to send a Billing code inside the SMS Submission URL to the mobile operator SMSC. in smsgw.ini I add: [SMPPOptions] SMPPOption_BillingCode=0402,String,5 in my SMS Submission URL I add like below: http://192.168.0.13:8900/?PhoneNumber=%2B962799701223&charset=iso-8859-6&SMPPOpt ion_BillingCode=ISTTS&Text=Billing%20Tes&Sender=95020&ContentType=text/plain The really problem, my Mobile Opertor when I send the SMS request, it's not going with the Billing code parameter. How can I inlude this parameter in my SMS URL with NowSMS? Regards, Salim | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6215 Registered: 10-2002 |
Hi Salim, Apologies, as I was on holiday last week, and everytime I do that, it takes me several more days to get caught back up on the discussion board when I return. Regarding the bind/unbind issue ... I don't really have enough information from the SMPPDEBUG.LOG. I'd need to see an SMSDEBUG.LOG that covered the same time period. It is not normal for the gateway to bind/unbind regularly during operation. In particular, it is very odd for the gateway to be sending an unbind to terminate this connection, as it normally only does this when it shuts down. That said, the gateway also performs a bind/unbind when you edit or test the connection settings. That's why I want to see the SMSDEBUG.LOG file as well. I want to make sure that the reason for this bind/unbind sequence is not simply that you are editing the connection details. Regarding the password problem ... I don't know what to tell you. The service provider is returning an error code that equates to "Invalid Password". I have seen some providers return an error like this if they think you already have an active connection (and it may take the provider a short period of time to recognise a previous connection has terminated), so this could be related to the mysterious bind/unbind issue. All I could suggest is that you go into the "Advanced Settings" and enable the "Single Connection/Transceiver" setting. By default, NowSMS will create 2 connections to the provider, one for sending and one for receiving. Some providers prefer that you use a single connection. (I see in your screen shot that "Receive SMS" is not checked, which would mean that only a single connection is used. But in the debug log, one of the bind/unbind connections is definitely using 2 connections.) -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6216 Registered: 10-2002 |
Salim, Regarding this billing code ... did the operator tell you that this was a parameter that you can use? Or did you only see it referenced in another thread here? The reason I ask, is because this is not a standard option. But if they do support a billing code parameter under an SMPP optional parameter tag of 0402, then what you would do is this ... In SMSGW.INI: [SMPPOptions] BillingCode=0402,String,5 Then you could use this in the URL to set the parameter: http://192.168.0.13:8900/?PhoneNumber=%2B962799701223&charset=iso-8859-6&SMPPOpt ion_BillingCode=ISTTS&Text=Billing%20Tes&Sender=95020&ContentType=text/plain And you can set a default value for this parameter by including a DefaultSMPPOptions setting under the [SMPP - server:port] section of SMSGW.INI, like this: DefaultSMPPOptions=BillingCode=ISTTS -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 77 Registered: 04-2005 |
Hi Bryce, Welcome back, we really miss you! I will try to give numbers to track the pending issues like your best way of working with us all. I really try to read and search over the Internet Google, Yahoo, MSN, Altavista for all my problems, I finish to come back on our discussion Board Of NowSMS where I spent alot of my time to solve many problems. 1#Regarding the password problem, I solved it by myself, but still I couldn't understant still. The problem was with the TON and NPI, he gave me wrong and when I change them into 1,1,1,1 it working fine, I am sending/receiving SMS as it has to be and the SMPP is up and as you guess it, I am using tranceiver setup. 2#Regarding the bind/unbind issue, for me it's headach, I couldn't understand why it occur just after finishing one service running for the World Cup, NowSMS was playing a best game before and sudden last day of final, problem start, see the SMPPDEBUG how it's keeping within one mn. I desabled my self the connection until I found a solution. Yemen SMSC supports guys are warning me that I am over trafic their SMSC server, so please give some solution. 3#Regarding this billing code, that is my concern, I have a risk to lose this market, I success everything just the vital issue of charging is pending. we success to run an HTTP post to check the mobile credit, after then depending on the STATUS=1 or 6 we are sending SMS which it has to charge the Mobile User with a Billing code like ISTTS. when they told me to send an extra parameter in my SMS submission URL, I read many threads you was talking this issue with Malbox, and I use similar solution, but Unfortunatly they are telling me that the SMS is gone without the billing code, and I check in my SMPPDEBUG I am seeing the URL exactly as I am running, I don't know what to do. So, of course you could get caught because many things are pending on the discussion board and you know that you are the only one who is always helping us. So, I am waiting please your suggestions Regards, Salim
| |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 79 Registered: 04-2005 |
Hi Bryce, Please, Take a look above issues we are pending and I try my best but still I am hesitate once again. Regards, Salim | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6295 Registered: 10-2002 |
Hi Salim, 1# - I guess it is a good idea to always question whether or not your provider has given you correct information on account settings, and to try different settings. 2# - As I mentioned before, I really need to see an SMSDEBUG.LOG that covers the same time period as an SMPPDEBUG.LOG where there is this connect/disconnect sequencing. Why I want to see this is because the disconnect sequence that I see in the SMPPDEBUG.LOG makes no sense. This sequence looks like NowSMS is being shutdown and then restarted, because the termination of the SMPP connections is orderly. Any error conditions would result in less than orderly connection termination. Are you shutting down and restarting the NowSMS services? This is why I want to see SMSDEBUG.LOG for the same time period, because I want to understand why this is happening. 3# - You need more information from the mobile operator. They are telling you to add an extra parameter to your SMS submission URL. However, you are not submitting to them via a URL, you are submitting to them via SMPP. Ask them where this extra parameter is specified if you are connecting to them via SMPP. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 80 Registered: 04-2005 |
Hi Bryce, Thank you very much. 1# everything is stable now, and we are in implementation step. 2# I enabled the SMPP connection now again, but I am getting strange: 14:33:08:362 (00000150) 172.18.83.195 --: SMPPEnquireLink: Sending enquire_link 14:33:08:721 (00000150) 172.18.83.195 --: SMPPEnquireLink: Response received for enquire_link 14:33:27:799 (00000130) 195.94.1.181 --: SMPPEnquireLink: Sending enquire_link 14:33:28:299 (00000130) 195.94.1.181 --: SMPPEnquireLink: Response received for enquire_link Please check attached Log and give me your advice, because this mobile operator may desable my SMPP Account, if I didn't get solution. 3# really we are pending still on it, they are telling the same way you are guessing but mostly as one of their support is telling it's has to be in the System Type facilities for billing purpose. the strange is that I am using SMPP System type as smpp from them. So I don't know how can we submit this billing code via SMPP to their SMSC to harge the mobile User.
Regard, Salim | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6301 Registered: 10-2002 |
Hi Salim, 2# - This is normal behaviour ... most providers want to see a enquire link periodically so that they can see you are connected. If you don't send one within their timeout, they disconnect you. Usually they require every 60 seconds, sometimes 120 ... one customer of ours has to send every 3 seconds. There is a configuration parameter for how often in the properties for the SMPP conection ... we call it KEEP-ALIVE interval there. 3# - Maybe they mean the service type value. System type is only sent once at login...but service type can be set individually with each message. HTTP parameter ServiceType= can set this value. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 81 Registered: 04-2005 |
Hi Bryce, The more I work with you, the more I appreciate your helpful ideas & solutions. 2# KEEP-ALIVE I have to setup it in the below SMPP settings, right? or my Mobile operator has to do it from their SMSC? 3# I have not yet the exact words to express how happy I am, when I used the ServiceType=ISTTS in my SMS submission URL, my mobile operator inform me that I success to submit in right manner the billing code before I ask them. So, Bryce, what the difference between SMPPOption and this ServiceType? is this last solution is a standard to be understood by all SMSC? Really I need to know to be aware for next time. Regards, Salim | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6309 Registered: 10-2002 |
Hi Salim, 2# - You set a value on your end for how often you send an enquire link (keep alive) to the server. But your provider also will have a timeout value and if you don't send frequently enough, they will disconnect you. Our default of 58 seconds is usually good, but some providers do want even lower timeouts. Your provider might want it higher, but you should ask, as if you set it too high this will cause a lot of disconnect/reconnect. When you first mentioned your problem, this is why I wanted to see your log...but your disconnects looked normal, not forced. Try asking your provider about recommended enquire link interval. 3# - Hooray! This is one common way of passing this type of code, but unfortunately every provider is a bit different. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 82 Registered: 04-2005 |
Hi Bryce, After keeping track both solutions,It seems that everything is fine. 2# - I kept as default and whenever I explained our mobile Operator the scenario as you mentioned above, they seem be convinced and we are running fine the SMPP like before. 3# - Hoorary me too, even the meaning seem new for me, really & honestly it was a great pending problem for us, spending more than 3 months, and we success it, that why I am happy as solution. 4# - I have one new MMS setting from Vodafone, they are using Ericson MM7, and I see that NowSMS is supporting it but seem to be like annyway non standard, is there any main setting I have to request correctly to be aware? Please advice..... Salim | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6406 Registered: 10-2002 |
Hi Salim, 4# - I cannot think of any special considerations for Ericsson MM7. You will normally have both a "VASP ID" and "VAS ID" parameter. (Usually no "Login Name"/"Password"/"ServiceCode") Aside from selecting the Ericsson option for the MM7 non-standard variation, other options can be left at their defaults. (Although it is a good idea to set "Connection Type" to be "To MMSC (submit format)". -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 83 Registered: 04-2005 |
Hi Bryce, 4# By the way, I got unexpecting scenario. my mobile Operator send me only as below: URL: http://172.18.88.25:9800/mm7adapter Username: isys Password: isys This is API not Ericson, right? I try to guess many options between VASID, VASPID with Username & Password, I am getting strange fail responses. I met them on MSN, and they sent me one XML/SOAP attached from one VAS provider which was success. So Bryce, by checking also my attached Isys MMSCDEBUG log which kind of update I have to do? because your suggestions are always helpful. My below shema is correct, they are telling me that I am submitting wrong format? [VASP] Protocol=MM7 Server=http://172.18.88.25:9800/mm7adapter mm7SubmitReq=Yes ForceSenderAddress=Yes UserName=isys Password=isys UseDial=No VASPID=isys VASID=isys MM7Schema=http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 Regards, Salim
| |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 84 Registered: 04-2005 |
Hi Bryce, 4# following and keep testing find my last MMSCDEBUG, and I really need your suggestion..
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6423 Registered: 10-2002 |
Salim, I'm guessing that this might be a Comverse MMSC, and I know we had a problem where the Comverse MMSC couldn't understand: <mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0" env:mustUnderstand="1"> They would only understand: <TransactionID xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0" env:mustUnderstand="1"> The latest patch for NowSMS 2006 includes that change. But I see you are running v5.51k. In that case, I'd suggest trying the dejan.zip patch that is referenced in the following thread: http://support.nowsms.com/discus/messages/485/14447.html He is seeing a different error in that thread, but I this patch includes the change for the Comverse MMSC. (It might also help if you could find out what MMSC the provider is using.) -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 85 Registered: 04-2005 |
Hi Bryce, I make the update of the Converse as you suggest, I attached the MMSCDEBUG, and I also ask them to provide to me details about their MMSC as provider and my today submission log from their MMSC. But yesterday, one of their VAS team sent to me one FH_API_Complete_Lib and inside many java class files, methods, and I take the Message Router MMS Java_API_v3.4_Development_Guide v1.4.pdf, you can just take a look, because the zip is around 4.5 MB. So, whenever they feed back to me, I will make you update (Mon Frere)in ordewr to see what we can do for this probleme... Regards, Salim
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6433 Registered: 10-2002 |
Hi Salim, Ok ... so it looks like they are using an MMS message router in front of their MMSC from "First Hop". Argh ... I don't have any idea why this First Hop message router thinks the XML is invalid. If only these vendors would test their products before releasing them... I notice that the XML in their response has no "white space" in it. Have you tried checking the configuration option in NowSMS for "Remove White Space from MM7 XML"? That other example that you gave me did have white space in it ... so I doubt this is the issue. But it's the only idea I can think of right now. -bn | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6435 Registered: 10-2002 |
Hi again Salim, Ok ... the only other idea that I can think of is to try to make all of the headers and XML look as close to their example as practical. I've uploaded a special update to MMSC.EXE for NowSMS v5.51x to the link http://www.nowsms.com/download/salim.zip. (Backup your current copy of MMSC.EXE before using this one, in case you need to go back to the older version.) Edit VASPOUT\isys\VASP.INI, and under the [VASP] header, add FirstHop=Yes Let's see if those changes make any difference. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 86 Registered: 04-2005 |
Hi Bryce, Thank you for your full help, What is the easy way to remove :"White Space from MM7 XML"? I install the update, and I can see some change but still the Unknown error. That is right, they are using message router. Before, we were using NowSMS to pull SMS from this message router, and then we were processing these SMS to speech as Talky MMS from charamel, but the service was not appreciated and we cancelled the deal. And now we decide to use NowSMS as MMS/SMS over our MMS services with them like MTC Kuwait ones. this message router was using for session ID purpose in their billing scenario, so the Content provider wasn't able to get any mobile number from them, and that session was getting time out after some time. But for now, they told us that MMS can be sent directly to mobile in subscription services, and I will also ask them what the need of this message router. I am still waiting them and I have one more thing I missed to ask you, Vodafone Bahrain may use the same MMS interface of MTC Vodafone Kuwait, should I add Annyway=yes, as non standard (Bahrain are in 3G network) or you don't think so, they are in week like us, and I will get details from tomorrow.... I attached also the MMSCDEBUG, and I am sorry because I am keeping too much these days, but we are solving many pending issues with you...... Regards, Salim
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6438 Registered: 10-2002 |
Hi Salim, The responses don't look like what we could see with the AnnyWay problem. So I don't think they are using the AnnyWay MMSC. As I recall, the AnnyWay MMSC used several different XML elements and referenced a non-existant MM7 schema. Everything that I've seen here is referencing a real MM7 schema. And the "Other VAS Success MMS MT" log that you got from the mobile operator looks like standard MM7. There were a few minor differences that should not be of any consequence, and we were trying to emulate those subtle differences with the FirstHop=Yes setting. But apparently those subtle differences were not the issue. I've got another idea, so I've updated http://www.nowsms.com/download/salim.zip with another update to try. Regarding "Remove white space from MM7 XML", you will find this as a checkbox when defining the MM7 connection under "MMSC Routing". -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 87 Registered: 04-2005 |
Hi Bryce, Really I am so sorry, this problem is making us spending time once again. I made the above update and settings, see my today MMSCDEBUG Log, and still my Bahrain Vodafone VAS Guys didn't reply yet, I do calling and send email to follow up, they promised to feed back me soon.... Thank you Bryce really, and honestly I have no the words to express it... Regards//Salim.
| |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 88 Registered: 04-2005 |
Hi again Bryce, I worked lively with Bahrain VAS Team, and they send to me two files; one for the message router and the other one is for the MMSC log. I attached them to see and I attached also my MMSC Log for this snoop...
| |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 89 Registered: 04-2005 |
Hi Bryce, The Bahrain MMSC supplier studied my Submission log and they sent me the below comment following above attached log files: The problem is the schemaLocation attribute. Now the message has following schemaLocation attribute: xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/soap-envelope.xsd" and that is in wrong format. Schema location attribute value should be the pair of values separated with space. The first value is the namespace and second value is the schema file in local directory. Below is the snip from specification: --- "The schemaLocation attribute contains pairs of values: The first member of each pair is the namespace for which the second member is the hint describing where to find to an appropriate schema document. The schemaLocation attribute value consists of one or more pairs of URI references, separated by white space. The first member of each pair is a namespace name, and the second member of the pair is a hint describing where to find an appropriate schema document for that namespace. The presence of these hints does not require the processor to obtain or use the cited schema documents, and the processor is free to use other schemas obtained by any suitable means, or to use no schema at all." ---- So the space should be added before file name "soap-envelope.xsd". Below is the corrected schemaLocation attribute: xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ soap-envelope.xsd" The space should be added before file name "soap-envelope.xsd". So, what do you suggest as solution to follow? Regards, Salim. | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6449 Registered: 10-2002 |
Hi Salim, We can try that. I don't know why we have to include this parameter in the first place. Normally we do not include it at all. (And this schema is not referenced subsequently in the XML at all.) We added it as a "guess" for when that "FirstHop=Yes" parameter is set, because we were trying to copy the working example that you provided earlier in this thread. That example did have a space character. We just assumed it was added due to word wrap as the log was posted here as that happens sometimes. So we'll try it ... hopefully it will make a difference. I am hopeful, but not optimistic. Same URL before http://www.nowsms.com/download/salim.zip. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 90 Registered: 04-2005 |
Hi Bryce, We success it Man, I was sure that you will solve it as many times with best solution, and now I contact Bahrain Vodafone guys, they are telling me that it's gone, but it fail in their MMSC, they will check and give me feed back, because I am believinbg that it was success and now that's their problem, right? So please, see the MMSCDEBUG and the MMSC log.. Thank you very very much, Today is a case of new scenario with the capabilities flexible of NowSMS mostly from you Bryce, but where were exactly the problem, can explain me little bit ??? .... Salim.
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6465 Registered: 10-2002 |
Hi Salim, That is strange. But hopefully the people in charge of the MMSC can figure out if there is some sort of routing problem between this FirstHop message router and their actual MMSC. You might want to try removing the "FirstHop=Yes" parameter from VASP.INI, and see if the original error returns. There were a couple of very minor tweaks that we made in the normal MM7 XML, in addition to some tweaks that were specific to this "FirstHop=Yes" parameter. Specific differences when the "FirstHop=Yes" parameter is used are as follows: 1.) "start=" parameter in the "Content-Type:" header, and "Content-ID:" header for the MM7 XML part of the MIME message are different. There are no angle brackets around the "start=" parameter value (my reading of the specs is that the angle brackets should be present, but we removed them because the example the operator gave us did not have them present). 2.) Differences in the name spaces and schemas associated with the envelope. Normal: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> With "FirstHop=Yes": <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ soap-envelope.xsd"> My guess is that #1 was not the problem, but that #2 is what made the difference. And I don't know why these extra parameters should be required by this message router. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 91 Registered: 04-2005 |
Hi Bryce, I do working early today with those guys, and still the problem is located between the message router and their MMSC. we make some snoop and they send me also to see, mainwhile their supplier will study the log. I attached for you, I just open it by Notepade, and I don't see any problem on that submission on my level, but may be you, you will, sure ! But you know the strange also, I removed the FirstHope=yes, the MMS was not submitted, and whenever I put it, the MMS was submitted successfully, so what do you think on that, you may need my MMSCLOG too. Salim...........
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6476 Registered: 10-2002 |
Hi Salim, I think we need to wait to see what the Mmsc guys can tell us.  -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 92 Registered: 04-2005 |
Hi Bryce, That's great then, I believe that they should give us good news next coming days, because they are in holidays thursday and tomorrow friday like here in Kuwait, hopefully saturday sunday, I will keep you update for every details lively even.... Salim.... | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 93 Registered: 04-2005 |
Hi Bryce, The Bahrain supplier response regarding many snoops we made together, and please see below their comments, I also attached the 2 files they sent to me: ******************************************************************** The SOAP requests we analyzed from the snoops is far from being valid regarding to 3GPP 23.140! - The multipart/related header incl. boundary is missing - The content-lenght from the XML-Content part of the message is used as HTTP length, so that the HTTP requests ends after the XML part ******************************************************************** Kindly make sure that you are adhering to 3GPP specifications. For your reference, you may use the attached sample MM7-MT (mms_mt.txt). so, which suggestion you advice? Regards, Salim
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6584 Registered: 10-2002 |
Hi Salim, Maybe they are looking at different snoops than the data that you have sent me. I'm looking at ISYS_MMS-MT (generated by NowSMS), not MMS-MT.
I disagree, it is present. The inner message containing the MMS content is "multipart/mixed" instead of "multipart/related" because no SMIL file is included. So the MMS message content in this case is "multipart/mixed" instead of "multipart/related". The multipart boundaries are correct. And if you want it to be "multipart/related" instead of "multipart/mixed", then you need to include a SMIL file.
I disagree. In this example, there are exactly 1392 bytes following the HTTP header (up to and including that final boundary marker). And that is the value of the "Content-length:" header. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 94 Registered: 04-2005 |
Hi Bryce, Thank you for your Effort to support us. before I give you my understanding of the Bahrain Problem, I need your great help: Here in Kuwait, the sending MMS is going as Bcc as you was giving us the update. now whenever we setup MMSFrom=ISYS parameter as sender, the MMS is coming on the mobile as From=+965113003 and this is the Vas Code of our Sharawi MMS account, we call MTC support and they are telling us that this parameter is missing and then their MMSC is taking by default the VAS code, I try my best Bryce, change VAS code itself, Senderfrom, MMSFrom no way, same +965112003, so I need your help, because they request us to remove this number, and even if we can hide the sender it can be good, we can use the MMSSubject=ISYS which is fine going. For the Bahrain issue, do you suggest us to send the MMS with smil to see the delivery? Regards, Salim. | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6594 Registered: 10-2002 |
Hi Salim, For Bahrain, try including a SMIL file. I don't know that it will make a difference or not, but if they are complaining that "multipart/related" is missing, then that might help. For the other ... the MMSFROM field must contain either a phone number or an e-mail address. A string of "ISYS" is not valid. That is likely what is causing the problem. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 95 Registered: 04-2005 |
Hi Bryce, I do work hardly whole this morning and I am still on the trying and trying but no advance on both MMS issue: For Bahrain, I include a smil/audio/picture on the request and I can see on the log Multipart/related. I send to my personal number 00965xxxxxx and the second to Bahrain VAS guy number 00972xxxxxx, but still I didn't get any thing, I inform Bahrain guy to check. I attached to you the bahrain MMSDEBUG and the bahrain MMSC-28092006 log. For Kuwait issue, I try to put the Field MMSFROM=96900 to see, still it's taking the default vas code +96511003 from MTC MMSC side. I am guessing that may be they didn't allow sender address overwite, I don't know, because we have one MMS service stopped by this problem, and we need even hide the sender from if we cannot use alphanumeric as MTC requested. what you suggest on both issues? Regards, Salim.
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6604 Registered: 10-2002 |
Hi Salim, The Bahrain situation is bizarre. From our perspective, the operator accepts the MMS message ... as before, we get a success response. But something seems to be going wrong in their system after they accept the message. They are using this FirstHop adapter in front of their actual MMSC, so I can only figure that something is wrong in how those two components interact with each other. I didn't expect the inclusion of a SMIL file to make a difference. I only suggested trying it because they made the comment "The multipart/related header incl. boundary is missing". Including a SMIL file causes us to indicate that the content is "multipart/related" ... without a SMIL file, we indicate "multipart/mixed". So it was worth a try. But overall, I disagreed with the assessments provided back by the mobile operator. Neither of their comments were valid in refering to potential problems in the submitted message ... so I'm not sure what data they were looking at. Regarding the Kuwait issue, I don't know what to tell you. We submit the message with "96900" as the sender address. If the message is actually being sent out with a different sender address, then the operator MMSC is changing it. I don't understand what else we could possibly try. You can configure the sender address for the "MMSC Routing" in NowSMS to be an alpha string. We will submit it that way. However, it is invalid from an MMS protocol standpoint. The sender address needs to be either a number or an e-mail address. Have you tried putting in a dummy e-mail address? -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 96 Registered: 04-2005 |
Hi Bryce, Thank you for your direction issues. >> For Kuwait, I was working this morning with one of their VAS Guys, and he find some change on the expected MMS request from our submission as below: Your application is submitting the Sender address this way: <SenderAddress><Number>96900</Number></SenderAddress> Where our MMSC accepts: <SenderAddress>96900</SenderAddress> So can we follow this format? and how can we remove the tag <Number>...</Number> ? >> For Bahrain, I do keep contacting those guys and one of their Guys send me below comment: Please take note that you are submitting to our messaging gateway (Firsthop) only. Then upon billing, our gateway will send this to MMSC for the actual delivery of MMS to the subscribers. The problem is actually happening between our messaging gateway and MMSC. MMSC is rejecting the MMS because of invalid format. FYI, other content providers can submit MMS successfully. Once again, I’m attaching a working sample of MM7 for your reference. If you could follow the format of this sample, I’m quite sure that we can have a successful sending of MMS. So I attach to you the sample he is talking about, and see what we can do on this bizaree problem. regards, Salim.
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6610 Registered: 10-2002 |
Hi Salim, Kuwait:
This suggests that they are using the MM7 Rel5 1.0 schema (REL-5-MM7-1-0). So you would select this in the "MM7 Schema" dropdown box. HOWEVER, is this the AnnyWay MMSC that you are connecting to here? Judging by the MM7 format in your logs, I'm thinking that it is. I'm not sure that this setting will apply when you have the AnnyWay variant enabled. We can make a change so that this setting would force the alternate SenderAddress format when using the AnnyWay variant, just like it does in standard MM7. I'll try making this change in the updated MMSC.EXE found at the link http://www.nowsms.com/download/salim2.zip. Bahrain: As far as I can see, we are following the same format as the example that they are providing. The only differences that I see are: 1.) We are stripping the white space (line breaks) from the XML ... but that is a configuration option that can be disabled (I believe that I had recommended at one point that you try enabling the option to strip white space, but it doesn't appear to have made a difference). 2.) A few optional headers are not included: MessageClass, TimeStamp, EarliestDeliveryTime, ExpiryDate, DeliveryReport, ReadReply, ChargedParty. (None of these headers should be required.) 3.) Optional parameter allowAdaptations="true" included in "content" attribute in operator supplied example. Not present in NowSMS submission. (I see no reason this optional parameter would be required.) 4.) There is no sender address in our submission, presumably because it has been left blank in the configuration. I hope that this issue is not as simple as the MMSC requring a sender address to be present. (According to the MM7 specs, the sender address is optional.) Have you tried submitting a message with a non-blank sender address? 5.) Even if there is only one content object, we always submit the MMS message content as a multipart object (multipart/related if SMIL is present, multipart/mixed if no SMIL is present). The example supplied by the operator contains only a MIDI file, and it is not submitted as a multipart object. By contrast, all examples (and associated description) in the MM7 specification show the MMS message content being encoded as multipart/related or multipart/mixed ... so I find it unlikely that this operator's MMSC would not accept multipart MMS message content. #1 is under your control. Uncheck the setting to strip white space characters from the XML. I don't expect this to make a difference, because I seem to recall earlier suggesting that you try checking this setting to see if it makes a difference. (But it might make things more readable to your operator contact.) Also, #4, including a sender address, is something that you can try. It's too time consuming to test to see if any of the optional attributes are actually required by this provider. At least with actual program code modifications. I think we'd be better off trying some experimental posts to the MMSC. And then if we find something that works, we can apply what we've learned. I've uploaded a ZIP file to http://www.nowsms.com/download/salim-test.zip. This ZIP file contains 7 text files with test posts for you to make to your operator MMSC. Here's how to use them ... Note that you might have to run these tests from the PC that is actually running NowSMS, as it is likely that the mobile operator is configured to only accept connections from the IP address that you supplied them. Open the first test, test1.txt with Notepad. Use Edit/Select All from the menu, then Edit/Copy. Run TELNET from a command window prompt or Start Menu - Run. Inside of TELNET, type the following: open 172.18.83.194 9800 <press Enter> The cursor should move to the upper left corner of the Telnet window. Press Alt-Spacebar, and select Edit/Paste. This will cause the text that you copied from Notepad to be sent via Telnet. You should see something like this returned back: HTTP/1.1 200 OK Date: Thu, 28 Sep 2006 10:54:01 GMT Server: Jetty/4.2.11 (SunOS/5.9 sparc java/1.4.1_01a) Connection: close Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="UTF-8"?> <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ soap-envelope.xsd"><soap-env:Header><TransactionID soap-env:mustUnderstand="1" xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1 -0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schem a/REL-5-MM7-1-0 mm7_with_mustUnderstand.xsd">20060928135403-8D75437C-x40x-192.168.0.3</Transacti onID></soap-env:Header><soap-env:Body><SubmitRsp xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1 -0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schem a/REL-5-MM7-1-0 mm7_with_mustUnderstand.xsd"><MM7Version>5.3.0</MM7Version><Status><StatusCode>1 000</StatusCode><StatusText>Success</StatusText><Details><Description>Request processed successfully.</Description></Details></Status><MessageID>1159440841973-mm7adapte r-172.18.83.194</MessageID></SubmitRsp></soap-env:Body></soap-env:Envelope> If you don't see something like that coming back, then something has gone wrong with the test. Use the QUIT command to exit Telnet. Repeat this test with each of the 7 text files that I included in the ZIP. They are 7 test MMS submissions, with some slight variations, and different subject lines, so if any of them work, we can see which messages made it to the handset. Hopefully at least one of these tests will work, to provide us with some clue as to what is going on. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 97 Registered: 04-2005 |
Hi Bryce, Nice to hear you honestly. For Kuwait issue, the MM7 Rel5 1.0 schema (REL-5-MM7-1-0) was not enough, but whenever I change the old mmsc.exe to the new above (salim2) one, everything is going fine, and now every MMS service, we will use its name as sender address... Mabrook(congratulations in kuwaiti) Bryce, see the below log: <SenderIdentification> <VASPID>AcmeISYS</VASPID> <VASID>Subp_shara</VASID> <SenderAddress>MTC-Vodafone</SenderAddress> </SenderIdentification> <Recipients> <Bcc> <Number>009659703008</Number> <Number>009659880303</Number> <Number>009657983931</Number> </Bcc> exactly what we needed and the marketing department really appreciate the features facilities. For Bahrain issue, the above url (http://www.nowsms.com/download/salim-test.zip ) it's giving me :"page can not be found", please check the url, in order to make the telnet test. there are some thing I found now: I Unchecked the setting to strip white space characters as you said. in the dropdown box of 3GP MMS version as 5.2.0, the MMS was not oubound, and whenever I dropdown as 5.3.0, the MMS was going as normal, but still fail to reach the mobile phone, this all by keeping schema as REL-5-MM7-1-0. whenever the above url is updated, I will make the telnet test as you suggested above. once again, Thank you very much Bryce... regards, Salim | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6621 Registered: 10-2002 |
Hi Salim, For Kuwait ... ok ... the normal logic for the REL-5-MM7-1-0 schema was not being applied if the AnnyWay protocol variant was selected (only for standard MM7). So I'm glad the update resolved this for you. On the other ... oops ... I had a typo in the file name when I uploaded it. The URL above for the test files will now work. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 98 Registered: 04-2005 |
Hi Bryce, For kuwait every thing is going fine and once again thank you for your great effort and courage to help us. For Bahrain, I send the data through Telnet as you showed me stepped above, and Only the test5.txt file was successfully send as you showed me above also. the other files as you said something wrong was there, just lost the connection at the last. For the test5.txt result, I attached it to you. I send two times the same file, you will see two results inside the txt file. Result 01: HTTP/1.1 200 OK Date: Wed, 04 Oct 2006 15:54:56 GMT Server: Jetty/4.2.11 (SunOS/5.9 sparc java/1.4.1_01a) Connection: close5 Content-Type: text/xml; charset="utf-8" p<?xml version="1.0" encoding="UTF-8"?> <soap-env:Envelope xmlns:soap-env="http:/ /schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema L-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ soap-e nvelope.xsd"><soap-env:Header><TransactionID soap-env:mustUnderstand="1" xmlns=" Vhttp://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0" xm lns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://w ww.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 mm7_with_mus mitRsp xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL- -MM7-1-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLoca tion="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1- 70 mm7_with_mustUnderstand.xsd"><MM7Version>5.3.0</MM7Version><Status><StatusCod e>1000</StatusCode><StatusText>Success</StatusText><Details><Description>Request x processed successfully.</Description></Details></Status><MessageID>11599772965 69-mm7adapter-172.18.83.194</MessageID></SubmitRsp></soap-env:Body></soap-env:En gvelope> Result 02: dHTTP/1.1 200 OK Date: Wed, 04 Oct 2006 16:05:04 GMTQ Server: Jetty/4.2.11 (SunOS/5.9 sparc java/1.4.1_01a) Connection: close ConteTnt-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="UTF-8"?> O<soap-env:Envelope xmlns:soap-env="http:/ /schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ soap-en Zvelope.xsd"><soap-env:Header><TransactionID soap-env:mustUnderstand="1" xmlns=" http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0" xml ww.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 mm7_with_mus 4tUnderstand.xsd">vastest-5</TransactionID></soap-env:Header><soap-env:Body><Sub mitRsp xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL- 5-MM7-1-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocat cion="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1- 0 mm7_with_mustUnderstand.xsd"><MM7Version>5.3.0</MM7Version><Status><StatusCode >1000</StatusCode><StatusText>Success</StatusText><Details><Description>Request processed successfully.</Description></Details></Status><MessageID>115997790455 H6-mm7adapter-172.18.83.194</MessageID></SubmitRsp></soap-env:Body></soap-env:En velope> and I can say no big difference of both results, right? Regards, Salim.
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6625 Registered: 10-2002 |
Hi Salim, That is not good. Well, it is good that at least one of the tests worked. But it is not good that this suggests that your mobile operator's MMSC is braindead. I would be very curious if you could find out from your mobile operator what vendor's MMSC product they are using. Based upon these tests, it would appear that the MMSC does not understand multipart content for the body of the MMS message (or if they do, they do not support it in the correct way). Section 8.7.8.1.1 of the 3GPP MMS specification (TS 23.140) provides a diagram that shows that the MMS content is supplied as a separate multipart SOAP attachment. There is an outer multipart structure for the HTTP POST itself, and an inner multipart structure for the SOAP attachment. Section 8.7.9 of the specification shows an example. In our tests, all of our examples failed until we changed the SOAP attachment to be a single part object (in the case of test5, the single object was a JPEG). So now we need to figure out what to do next. It is not a good solution if only a single content object can be sent. So I want to try one more test. I want to try sending 3 pieces of content (SMIL, JPEG and AMR) like in the other tests ... but we will try encoding them all within the outer level multipart. I've updated the URL from before (http://www.nowsms.com/download/salim-test.zip) to include 4 more tests. Tests 8, 9, 10 and 11 try to send more than one piece of content. Test 8 tries to send a SMIL file, JPEG and AMR. Tests 9 and 10 try only SMIL and JPEG in different orders. Test 11 tries to send a JPEG and AMR without SMIL. Let me know how these tests work, and whether or not all of the content seems to be present in the message. (It may be difficult for tests 9 and 10 to determine whether or not SMIL is present, but note if the receiving phone processes these messages any differently from test 5.) -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 99 Registered: 04-2005 |
Hi Bryce, I was working this morning on that Bahrain issue: For the 4 tests, only test9 and test10 were successfully sent, and I attached also the response which I send three time each test, but I put only two response inside the files. When I asked Bahrain Operator Guys, he provided to me: "We are using MMSC provided by Materna from Germany" and he sent me API documentation (((As what I have explained to you, our setup is kind of a complicated one. Actually, your application is submitting the MMS to our messaging gateway (Firsthop) which is not really our MMSC. The problem is occurring when our messaging gateway is submitting your MMS to our real MMSC (Materna). This problem only occurs for your MMS, other MMS from content providers are fine. Anyway, I'm attaching here the Firsthop API. Some of our content providers are using this API and all of their MMS are being forwarded successfully to our MMSC. I hope this can help us closing this issue))) he include in his email, the files are in web and jar files library. I will try to upload the zip, if it failed I will upload the API pdf came together and if you need the complete zip I will send it by email... Regards, Salim.
| |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6632 Registered: 10-2002 |
Hi Salim, Did the SMIL seem to be included on the phone for these tests 9 and 10? Did you notice any difference in presentation between as to how this was received on the phone comparing with test 5? I am wondering if the MMSC actually used the SMIL that was included in tests 9 and 10. I am wondering if test 8 and 11 failed because the MMSC did not understand or support the type "audio/amr" ... because otherwise it makes no sense why these tests would fail. In any event, the tests suggest to me that the MMSC that the operator is using does not understand the proper MM7 message structure ...specifically, not understanding that the SOAP attachment is supposed to be multipart content, as referenced in Section 8.7.8.1.1 of the 3GPP MMS specification, and as shown in the example in Section 8.7.9. It is insane that mobile operators buy non conforming products, and then blame us when something doesn't work. One thing I don't understand is that Materna = AnnyWay. AnnyWay is what the mobile operator is using in Kuwait. And you're not seeing this problem there. So at this point, I am very confused. I can only figure that the two operators are using different versions of the Materna software, which have different problems. My current theory is that the MMSC does not understand a multipart SOAP attachment, and that it expects there to be only the outer-level multipart (instead a multi-level multipart). However, this theory does not explain why the tests that included AMR files would fail. We will try to produce an option which does not produce a multipart SOAP attachment for MM7. But I have to emphasize that this is extremely non-standard ... and unfortunately, a considerable amount of development effort. It will likely take 1 to 2 weeks before I can send you such an update. I'm sorry that this is the case, but based upon these test results, I am led to believe that there is something seriously wrong with the MM7 implementation on that MMSC. -bn | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 100 Registered: 04-2005 |
Hi Bryce, Thank you for your efforts. All the tes5, test9 and test10, no one of them reach the mobile. it was my mobile phone, and I used three numbers also for Bahrain Users, and still it failed in the Bahrain MMSC. may be we should test as Materna=Annyway, because MTC Bahrain is a part of MTC Kuwait, may be the Version is diffrent. whenever I asked the VAS team of Bahrain, they send me the API documentation and said Materna Germany.... I will wait your suggestion, if I can test the AnyWay enabling update and see the difference... if the Bahrain MMSC don't support Multipart definitions, how can we send AMR, picture and SMIL together or how will be in MMS video case? it's wrong then, or may be some misconfiguration of the MM7 inside their MMSC.... Regards, Salim | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 103 Registered: 04-2005 |
Hi Bryce, For Bahrain I try Annyway update, but the MMS is going even, I setup the FirstHop still same, So, I really believe that you are right. we will be waiting your feed back... For Yemen, i got solution on the pending prolem by trying many mixed settings. at last, I used Annyway enabling and the Bcc one, now I Success to send MMS all types to Spacetel Yemen, great really and it reached successfully the mobile phone.... Thank you for your efforts and support. Salim... | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6714 Registered: 10-2002 |
Hi Salim, Sorry for the delay. We have been preparing a more formal maintenance release ... and it took almost exactly as long as the high end of my estimate above to complete. I have not had a chance to study your updated comments yet. But I do have something for you to try. I have an updated MMSC.EXE in http://www.nowsms.com/download/salim.zip to further test my theory about this multi-level multipart issue. Edit VASPOUT\accountname\VASP.INI, and under the [MMSC] header, add SingleLevelMultipart=Yes. When this setting is present for any type of MM7 connection, we construct a single level "multipart/related" HTTP POST for the MM7 submission. (The MM7 standard calls for the actual MMS content to be a second "multipart/related" SOAP attachment inside of the "multipart/related" HTTP POST ... giving multiple layers of multipart encoding.) Let's see how that goes. Try it with some simple content initially ... like just a GIF file ... as based upon the results of the test experiments above, I'm not sure that this particular operator MMSC understands AMR content. -bn | |||||||
| Stephen Spence New member Username: Stephen Post Number: 1 Registered: 10-2006 |
Hello Bryce, I think you are doing a good job. I hope you will be able to help me with a problem I am having. 1) I have NOWSMS 2006 and several customer accounts. When my customers send their text messages many times the person receiving the message replys. However the reply is not routed back to the customer. How do I send these replys to the appropriate customer??? They would want to get the reply sent to an email address. I have gone through and read all I can but I just cant seem to get this done, please help me. | |||||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6724 Registered: 10-2002 |
For Stephen's posting here, see follow-up at http://support.nowsms.com/discus/messages/1/18385.html. | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 109 Registered: 04-2005 |
Hi Bryce, We were in holiday last week, but I was working on this issue especially, the delay was on the Bahrain Mobile operators response side. I setup the update MMSC.exe and edit the VASPOUT as you mentionned. everything is seeming gone successfully, either jif, amr and also video files. My Mobile operator reply to me that still, the MMS was rejected by their MMSC reach the Mobile phone, really I cannot understand, because we got solution last week with yemen and kuwait is running well... Please check the MMSCDEBUG log if we can move ahead further more. Regards, Salim.
| |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 111 Registered: 04-2005 |
Hi Bryce, I believe that you have done your level best to help us, but unofortunatly Bahrain MMSC makes us troule and I can guess that may be you are tired. But by the way, I will keep you update because I am trying daily to see if it will be any clouds or further more to come on the issue. Thank you very much as usual, because you are always helping us and we are really appreciating your efforts and supports... Regards, Salim | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 112 Registered: 04-2005 |
Hi Bryce, Hope these days will be a nice holidays for you... I just want to come with new improvement regarding one of our New MM7 connection. I setup an MM7 setup to Mobitel MMSC (Sudan), it seem to accept the MMS and get back response: I am waiting their feed back and I will make update: 12:14:52:560 [7] HttpResponseWait: Ok 12:14:52:560 [7] ThreadProcessVASPQ: mm7 - got http ok response 12:14:52:560 [7] ThreadProcessVASPQ: HTTP/1.1 200 OK Date: Mon, 18 Dec 2006 09:15:05 GMT Content-Length: 560 Content-Type: text/xml Connection: close Server: Apache/1.3.29 (Unix) PHP/4.3.8 mod_fastcgi/2.2.12 Via: 1.1 supercache4 (NetCache NetApp/6.0.4) Regards, Salim | |||||||
| MedSalimALI Frequent Contributor Username: Salim Post Number: 113 Registered: 04-2005 |
Hi Bryce, Is there any issue to solve the XML/soap submission log: <?xml version="1.0" ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <mm7:TransactionID xmlns:mm7="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-3" env:mustUnderstand="1">20070113142434-5D55B5A7@192.168.0.9</mm7:TransactionID> </env:Header> <env:Body> <SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-3"> <MM7Version>5.3.0</MM7Version> <SenderIdentification> <SenderAddress><ShortCode>IsysT</ShortCode></SenderAddress> </SenderIdentification> <Recipients> <To> <Number>249912396085</Number> <Number>249912150595</Number> </To> </Recipients> <Priority>Normal</Priority> <DeliveryReport>False</DeliveryReport> <ReadReply>False</ReadReply> <Subject>MMS test 05</Subject> <Content href="cid:mms_cid"/> </SubmitReq> </env:Body> </env:Envelope> as above one of our mobile operator said that our MMSFrom is going empty and the MMSCDEBUG show the senderaddress as well... di you have any suggestion? Regards, Salim | |||||||
SMPPDEBUG.Log
SMPPDEBUG.Log
