http://www.orangepartner.com/images/smsc46emiucpspecification.pdf
regards -- Telemaque - 06200 NICE - (FR) Service Technique/Reseau - NOC Developpement SMS/MMS/Kiosques http://www.telemaque.fr/ [EMAIL PROTECTED] Tel : +33 4 93 97 71 64 (fax 68) ----- Original Message ----- From: "Colin Pitrat" <[EMAIL PROTECTED]> To: "Vincent CHAVANIS" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Friday, August 18, 2006 4:30 PM Subject: Re: [PATCH] EMI UCP Numerical message for OT 01 > Well, in the version of EMI/UCP I have (3.5), there's only MT=2 and > MT=3. Do you have a link where I could fine a more recent version ? (I > know I'm lazy :) ). > > For the redundant code, it's not really redundant as for MT=2 there's > only the if, whereas for MT=3 there's the if and the else, so if you > wan't to change it you have to add a flag to know later if > emimsg->fields[E01_AMSG] was NULL or not in order to do the else only > when needed. Moreover, this part only concern MT=2 and MT=3, but not the > default case, and maybe not the MT=4 part (what is it ?). > > Colin Pitrat (Bull Services Telco) > Bull, Architect of an Open World (TM) > Tél : +33 (0) 1 30 80 72 93 > www.bull.com > > > Vincent CHAVANIS wrote: >> I'm -0 for this patch >> >> As it's presented as a new feature, your patch looks incomplete. >> Please refer to EMI/UCP 4.6 Specs. (MT=4 is missing for example) >> Then you are using redundant code when you initiate emimsg->fields[E01_AMSG] >> >> Vincent. >> >> -- >> Telemaque - 06200 NICE - (FR) >> Service Technique/Reseau - NOC >> Developpement SMS/MMS/Kiosques >> http://www.telemaque.fr/ >> [EMAIL PROTECTED] >> Tel : +33 4 93 97 71 64 (fax 68) >> >> ----- Original Message ----- >> From: "Colin Pitrat" <[EMAIL PROTECTED]> >> To: "Kannel Devel" <[email protected]> >> Sent: Friday, August 18, 2006 2:57 PM >> Subject: [PATCH] EMI UCP Numerical message for OT 01 >> >> >> Hi, >> this patch add support for numerical message for operation call input >> operation (Call input operation is OT=01, Numerical message is MT=2). >> As we're dealing with numerical data, there should be no need of charset >> conversion. >> >> Regards, >
