Hi, Johan!
Yeah, apparently it is RURI, instead of To header, sorry about that.
Regarding the error, the result of send_smpp_message() says that the
messages sending did complete correctly - the message was properly sent.
However, it was denied by the "tralala" SMSC, who sends the 0000000b
error. This response is received asynchronously (as you can see, message
is sent by process 9897 and reply is received in process 9907), so the
two processes can't coordinate to indicate the error.
Unfortunately there's no way to detect this failure now, and not sure
how it's the best way to report it. Perhaps using a SIP reply when the
error message comes in.
Best regards,
Răzvan
On 7/25/19 11:57 AM, johan de clercq wrote:
Razvan,
It's confirmed : you take RURI instead of To, but that is fine.
However, the function returns always positive even if there is an smpp error.
$var(result)=send_smpp_message("tralala");
xlog("callid=$ci: Route[message]: result of send_smpp_message
var(result) $var(result)");
if ($(var(result){s.int})<0)
{
sl_send_reply(600, "General failure for this message");
xlog("callid=$ci: Route[message]: error in sending message to
tralala");
exit;
}
Jul 25 08:11:58 hendrix /data/opensips/sbin/opensips[9897]: callid=3GdSZmARTG:
Route[message]: result of send_smpp_message var(result) 1
Jul 25 08:11:58 hendrix /data/opensips/sbin/opensips[9907]:
ERROR:proto_smpp:handle_submit_or_deliver_resp_cmd: Error in submit_sm_resp
0000000b
-----Original Message-----
From: johan de clercq <[email protected]>
Sent: Thursday, July 25, 2019 10:29 AM
To: 'OpenSIPS users mailling list' <[email protected]>
Subject: RE: [OpenSIPS-Users] smpp manipulation of A and B number.
This is what the message looks like in SIP :
MESSAGE sip:+33xxx@zzz SIP/2.0
Via: SIP/2.0/UDP 10.3.0.150:5060;branch=z9hG4bK8b21.c08ad714.0;i=9e2a8e73
Via: SIP/2.0/TLS
10.205.0.50:33319;received=10.205.0.50;branch=z9hG4bK.tOgG7RZja;rport=33319
From: <sip:33yyy@zzz>;tag=6fpKtJ4ez
To: sip:33xxx@zzz
CSeq: 20 MESSAGE
Call-ID: Gtdp3TmWZn
Max-Forwards: 69
Supported: replaces, outbound, gruu
Date: Thu, 25 Jul 2019 08:17:21 GMT
Content-Type: text/plain
Content-Length: 4
This is what is send out :
Short Message Peer to Peer, Command: Submit_sm, Seq: 55, Len: 226
Length: 226
Operation: Submit_sm (0x00000004)
Sequence #: 55
Service type: (Default)
Type of number (originator): International (0x01)
Numbering plan indicator (originator): ISDN (E163/E164) (0x01)
Originator address: 33yyy
Type of number (recipient): International (0x01)
Numbering plan indicator (recipient): ISDN (E163/E164) (0x01)
Recipient address: +33xxx
.... ..00 = Messaging mode: Default SMSC mode (0x0)
..00 00.. = Message type: Default message type (0x0)
00.. .... = GSM features: No specific features selected (0x0)
Protocol id.: 0x00
Priority level: GSM: None ANSI-136: Bulk IS-95: Normal (0x00)
Scheduled delivery time: Immediate delivery
Validity period: SMSC default validity period
.... ..00 = Delivery receipt: No SMSC delivery receipt requested (0x0)
.... 00.. = Message type: No recipient SME acknowledgement requested (0x0)
...0 .... = Intermediate notif: No intermediate notification requested
(0x0)
.... ...0 = Replace: Don't replace (0x0)
Data coding: 0x00
Predefined message: 0
....
-----Original Message-----
From: johan de clercq <[email protected]>
Sent: Thursday, July 25, 2019 10:20 AM
To: 'OpenSIPS users mailling list' <[email protected]>
Subject: RE: [OpenSIPS-Users] smpp manipulation of A and B number.
Can it be that you use Ru instead of the To header ?
-----Original Message-----
From: Users <[email protected]> On Behalf Of Razvan Crainea
Sent: Thursday, July 25, 2019 9:43 AM
To: [email protected]
Subject: Re: [OpenSIPS-Users] smpp manipulation of A and B number.
Hi, Johan!
Yes, the modules do not see the uac_change_from/to() changes - these changes
only reflect in the message sent downstream.
Therefore, the only way to sort this out is to "loop" the message back to
OpenSIPS, after the normalization. To do that, after using uac_replace_from/to(), you can
send the message back to OpenSIPS using:
$dd = "OWN_SIP_IP";
And then "catch" this message as soon as possible in your script and send it to
the SMPP, using something like:
if (is_method("MESSAGE") && $si == "OWN_SIP_IP")
send_smpp_message("SMPP");
Hope this helps.
Best regards,
Răzvan
On 7/25/19 9:41 AM, johan de clercq wrote:
From and to header changes when you call uac_change_from and uac_change_to
are not taken into account.
Is there a wasy that I can resend the message through the request-route and
will this force the from and to header to be adapted in the request.
xlog("callid=$ci: Route[normalize]: we drop 0,00,+ from $fU, result is
var(from)");
dp_translate(1,$fU,$var(from));
if ($var(from)==NULL or $var(from)=='' or $var(from)=='<null>')
{
xlog("callid=$ci: Route[normalize]: result dp_translate for from header
var(from) $var(from) == NULL -> from header user $fU from $fu has correct format");
}
else
{
$avp(from)="sip:"+$var(from)+"@"+$fd;
xlog("callid=$ci: Route[normalize]: result dp_translate for from header
var(from) $var(from) -> from header user $fU from $fu has incorrect format , we use
var(from) $var(from) in the avp; avp(from) becomes $avp(from)");
xlog("callid=$ci: Route[normalize]: we change fu $fu to avp(from)
$avp(from)");
uac_replace_from( , "$avp(from)");
}
...
xlog("callid=$ci: Route[normalize]: result after normalization tu
$tu, fu $fu");
we drop 0,00,+ from +33333333, result is var(from) result dp_translate
for from header var(from) 33333333 -> from header user +33333333 from
sip:+ +33333333@xxxx has incorrect format, we use var(from) 33333333
in the avp; avp(from) becomes sip: 33333333 @xxxx we change fu sip:+ 33333333
@xxxx to avp(from) sip: 33333333@xxxx ...
result after normalization tu sip: .... , fu sip:+33333333@xxxx
-----Original Message-----
From: Users <[email protected]> On Behalf Of Razvan
Crainea
Sent: Wednesday, July 24, 2019 10:17 AM
To: [email protected]
Subject: Re: [OpenSIPS-Users] smpp manipulation of A and B number.
Hi, Johan!
Unfortunately the current code is only able to get the from and to fields that
are present in the From and To headers in the request. So unless that request
doesn't come in with a +, there's nothing you can do.
This looks however as a necessary feature, so can you please open a feature
request for this on our ticketing system:
https://github.com/OpenSIPS/opensips/issues
Best regards,
Razvan
On 7/24/19 9:40 AM, johan de clercq wrote:
Hello,
When a message is sent over smpp, then the A and B number always get
+ in front.
Is there a way that I can change this behavior ?
Basically, I want to get rid of the + that is put in front.
cid:F3100D46-F00D-4610-87ED-3E91DA790A82
Johan De Clercq, Managing Director
Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke
Tel +3256980990– GSM +32478720104
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
