[OpenSIPS-Users] smpp manipulation of A and B number.
johan de clercq
johan at democon.be
Thu Jul 25 09:01:52 EDT 2019
Razvan,
opensips doesn't respond to bind-transceiver.
Jul 25 12:55:24 hendrix /data/opensips/sbin/opensips[19637]: DBG:proto_smpp:handle_smpp_msg: Received SMPP command 00000009
Jul 25 12:55:24 hendrix /data/opensips/sbin/opensips[19637]: DBG:proto_smpp:handle_bind_transceiver_cmd: Received bind_transceiver command
Jul 25 12:55:24 hendrix /data/opensips/sbin/opensips[19637]: ERROR:proto_smpp:handle_bind_transceiver_cmd: NULL params
Jul 25 12:55:24 hendrix /data/opensips/sbin/opensips[19637]: DBG:proto_smpp:smpp_read_req: tcp_read_req end
Jul 25 12:55:25 hendrix /data/opensips/sbin/opensips[19638]: DBG:proto_smpp:smpp_read_req: Using the global ( per process ) buff
However in the request that comes in I have below info:
Transmission Control Protocol, Src Port: 38423, Dst Port: 5062, Seq: 1, Ack: 1, Len: 43
Short Message Peer to Peer, Command: Bind_transceiver, Seq: 1, Len: 43
Length: 43
Operation: Bind_transceiver (0x00000009)
Sequence #: 1
System ID: xxxxx
Password: yyyy
System type: OTT
Version (if): 3.4
Type of number: International (0x01)
Numbering plan indicator: ISDN (E163/E164) (0x01)
Can you please indicate what is wrong ?
-----Original Message-----
From: Users <users-bounces at lists.opensips.org> On Behalf Of Razvan Crainea
Sent: Thursday, July 25, 2019 11:32 AM
To: users at lists.opensips.org
Subject: Re: [OpenSIPS-Users] smpp manipulation of A and B number.
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 <johan at democon.be>
> Sent: Thursday, July 25, 2019 10:29 AM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> Subject: RE: [OpenSIPS-Users] smpp manipulation of A and B number.
>
> This is what the message looks like in SIP :
>
> MESSAGE sip:+33xxx at 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 at zzz>;tag=6fpKtJ4ez
> To: sip:33xxx at 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 <johan at democon.be>
> Sent: Thursday, July 25, 2019 10:20 AM
> To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
> 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 <users-bounces at lists.opensips.org> On Behalf Of Razvan
> Crainea
> Sent: Thursday, July 25, 2019 9:43 AM
> To: users at lists.opensips.org
> 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 at 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 at xxxx ...
>> result after normalization tu sip: .... , fu sip:+33333333 at xxxx
>>
>>
>> -----Original Message-----
>> From: Users <users-bounces at lists.opensips.org> On Behalf Of Razvan
>> Crainea
>> Sent: Wednesday, July 24, 2019 10:17 AM
>> To: users at lists.opensips.org
>> 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
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> --
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> --
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list