[OpenSIPS-Users] smpp manipulation of A and B number.

johan de clercq johan at democon.be
Thu Jul 25 11:49:41 EDT 2019


I think that I know what it is. 

In smpp table, I only made a record for the outbound connection to the SMSC. 
So there is no record for the inbound connection towards opensips. 

Am I correct in assuming that I need a record in SMPP table for the inbound connection  towards opensips also ?

-----Original Message-----
From: johan de clercq <johan at democon.be> 
Sent: Thursday, July 25, 2019 5:30 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: RE: [OpenSIPS-Users] smpp manipulation of A and B number.

Razvan, please let me know if you need anything else. 

-----Original Message-----
From: johan de clercq <johan at democon.be>
Sent: Thursday, July 25, 2019 3:26 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: RE: [OpenSIPS-Users] smpp manipulation of A and B number.

To me, what is send over the wire seems to be compliant with smpp 3.4. 

-----Original Message-----
From: johan de clercq <johan at democon.be>
Sent: Thursday, July 25, 2019 3:02 PM
To: 'OpenSIPS users mailling list' <users at lists.opensips.org>
Subject: RE: [OpenSIPS-Users] smpp manipulation of A and B number.

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