camel-smpp in trx mode
Hi camel users, Please help on smpp client connected to operator smsc in trx mode.I have only one smpp connectivity is given operator in TRX mode. Regards, Srinivas -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
The camel-smpp component doesn't support the TRX mode yet. We only support the trasmitter mode (if you use to(...)) and the receiver mode (if you use from(...)). I don't think it's a good idea to have an enpoint which is a producer and a consumer. How should your route looks like? What is the reason for this limitation from your SMSC? Sent from a mobile device Am 27.12.2012 05:51 schrieb "Srinivas" : > Hi camel users, > > Please help on smpp client connected to operator smsc in trx mode.I have > only one smpp connectivity is given operator in TRX mode. > > Regards, > Srinivas > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: camel-smpp in trx mode
Hi Christian, Thank you for replying. Operator given only one smpp connectivity that is in trx mode and operator not allowed two smpp(tx and rx) connections. In my application receive delivery sm ,delivery recipients and submit sm. Please help me how to solve my problem using apache camel. Regards, Srinivas -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
It doesn't make sense for me to support the TRX mode. Could you provide some pseudo code how your route will looks like? Best, Christian On Mon, Dec 31, 2012 at 5:32 AM, Srinivas wrote: > Hi Christian, > > Thank you for replying. > > Operator given only one smpp connectivity that is in trx mode and > operator not allowed two smpp(tx and rx) connections. In my application > receive delivery sm ,delivery recipients and submit sm. Please help me how > to solve my problem using apache camel. > > Regards, > > Srinivas > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html > Sent from the Camel - Users mailing list archive at Nabble.com. > --
Re: camel-smpp in trx mode
On Friday, 4 January 2013, Christian Müller wrote: > It doesn't make sense for me to support the TRX mode. > Could you provide some pseudo code how your route will looks like? > > Best, > Christian > > On Mon, Dec 31, 2012 at 5:32 AM, Srinivas > > > wrote: > > > Hi Christian, > > > > Thank you for replying. > > > > Operator given only one smpp connectivity that is in trx mode > and > > operator not allowed two smpp(tx and rx) connections. In my application > > receive delivery sm ,delivery recipients and submit sm. Please help me > how > > to solve my problem using apache camel. > > > > Regards, > > > > Srinivas >From my experience, some SMSC only allow single connection using TRX. I can't remember whether i have established TRX connection during my tests, but I remember that sometimes my outbound route also receive incoming sms if i add additional "to" destination > > > > > > > -- > > View this message in context: > > > http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > -- > -- Johanes
Re: camel-smpp in trx mode
That's the problem from my point of view. If you can suggest a good design how to handle it, I will implement it. Assume your route to send short messages looks like the following: from("bean://") .to("smpp://..."); By using TRX mode your smpp session will also receive: - sync. response from the SMSC - async. requests for the delivery notification - async requests for received short messages How would you like to model your route to catch all this use cases? Something like from("bean://") .to("smpp://...") .choice() .when(header("CamelSmppMessageType").isEqual("DeliveryReceipt")) .to("bean://") // async. requests for the delivery notification .when(header("CamelSmppMessageType").isEqual("DeliverSm")) .to("bean://") // async. requests for the delivery notification .otherwise() .to("bean://") // sync. response from the SMSC .end(); ? I think we don't have another camel component where the endpoint is a consumer and producer. I'm not sure how/if it works or if we hit problems in other areas (exception handling, ...). Best, Christian On Thu, Jan 3, 2013 at 11:41 PM, Johanes Soetanto wrote: > On Friday, 4 January 2013, Christian Müller wrote: > > > It doesn't make sense for me to support the TRX mode. > > Could you provide some pseudo code how your route will looks like? > > > > Best, > > Christian > > > > On Mon, Dec 31, 2012 at 5:32 AM, Srinivas > > > wrote: > > > > > Hi Christian, > > > > > > Thank you for replying. > > > > > > Operator given only one smpp connectivity that is in trx mode > > and > > > operator not allowed two smpp(tx and rx) connections. In my application > > > receive delivery sm ,delivery recipients and submit sm. Please help me > > how > > > to solve my problem using apache camel. > > > > > > Regards, > > > > > > Srinivas > > > From my experience, some SMSC only allow single connection using TRX. > I can't remember whether i have established TRX connection during my tests, > but I remember that sometimes my outbound route also receive incoming sms > if i add additional "to" destination > > > > > > > > > > > > > -- > > > View this message in context: > > > > > > http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5724731.html > > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > > > > > > -- > > > > > -- > Johanes > --
Re: camel-smpp in trx mode
On 4 January 2013 17:26, Christian Müller wrote: > I think we don't have another camel component where the endpoint is a > consumer and producer. I'm not sure how/if it works or if we hit problems > in other areas (exception handling, ...). We do this for the camel-smslib component. The endpoint represents a serial connection to an SMS modem, and therefore must deal with either sending or receiving of messages or both. I have no idea if this is a recommended approach from camel perspective, but it works for us. My interpretation of the camel doc was that returning `true` from Endpoint.isSingleton() should allow for one Endpoint per URI, but multiple consumers/producers tied to the Endpoint. You can see example at https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java
Re: camel-smpp in trx mode
The smslib model is a bit different. The smslib camel consumer pull the short messages for the SMSC. And only if a consumer is defined ( from("smslib://...") ). In the smpp Camel component, the SMPP library push the short messages (and delivery receipt messages) to the client if the client is connected in the TRX mode. Assume there is only one producer ( to("smpp://...") ) defined and no consumer. The SMPP library push the message to the client. Because there is no Camel consumer, there is no route which can consume/handle/process/... this message. What is a good/acceptable behavior in this case? Best, Christian On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson wrote: > On 4 January 2013 17:26, Christian Müller > wrote: > > I think we don't have another camel component where the endpoint is a > > consumer and producer. I'm not sure how/if it works or if we hit problems > > in other areas (exception handling, ...). > > We do this for the camel-smslib component. The endpoint represents a > serial connection to an SMS modem, and therefore must deal with either > sending or receiving of messages or both. I have no idea if this is a > recommended approach from camel perspective, but it works for us. My > interpretation of the camel doc was that returning `true` from > Endpoint.isSingleton() should allow for one Endpoint per URI, but > multiple consumers/producers tied to the Endpoint. > > You can see example at > > https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java > --
Re: camel-smpp in trx mode
On Sunday, 13 January 2013, Christian Müller wrote: > The smslib model is a bit different. The smslib camel consumer pull the > short messages for the SMSC. And only if a consumer is defined ( > from("smslib://...") ). > In the smpp Camel component, the SMPP library push the short messages (and > delivery receipt messages) to the client if the client is connected in the > TRX mode. Would it be possible to share SMPP session? > Assume there is only one producer ( to("smpp://...") ) defined and no > consumer. The SMPP library push the message to the client. Because there is > no Camel consumer, there is no route which can consume/handle/process/... > this message. What is a good/acceptable behavior in this case? If there is no consumer and bind TRX would it be acceptable to simply dump the message somewhere. Like slf4j nop? > > Best, > Christian > > On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson > > >wrote: > > > On 4 January 2013 17:26, Christian Müller > > > > > > wrote: > > > I think we don't have another camel component where the endpoint is a > > > consumer and producer. I'm not sure how/if it works or if we hit > problems > > > in other areas (exception handling, ...). > > > > We do this for the camel-smslib component. The endpoint represents a > > serial connection to an SMS modem, and therefore must deal with either > > sending or receiving of messages or both. I have no idea if this is a > > recommended approach from camel perspective, but it works for us. My > > interpretation of the camel doc was that returning `true` from > > Endpoint.isSingleton() should allow for one Endpoint per URI, but > > multiple consumers/producers tied to the Endpoint. > > > > You can see example at > > > > > https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java > > > > > > -- > -- Johanes
Re: camel-smpp in trx mode
On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller wrote: > The smslib model is a bit different. The smslib camel consumer pull the > short messages for the SMSC. And only if a consumer is defined ( > from("smslib://...") ). > In the smpp Camel component, the SMPP library push the short messages (and > delivery receipt messages) to the client if the client is connected in the > TRX mode. > Assume there is only one producer ( to("smpp://...") ) defined and no > consumer. The SMPP library push the message to the client. Because there is > no Camel consumer, there is no route which can consume/handle/process/... > this message. What is a good/acceptable behavior in this case? > Not sure what the JSMPP library allows us to do but on a protocol level you can reply with a deliver_sm_resp to indicate a failed command_status. Perhaps this is a solution if there is no consuming endpoint. Another solution would be to refuse to start the producer endpoint in trx mode if there is no corresponding consuming endpoint defined. If I do not remember incorrectly a similar restriction applies to direct endpoints ? // Pontus > Best, > Christian > > On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson wrote: > >> On 4 January 2013 17:26, Christian Müller >> wrote: >> > I think we don't have another camel component where the endpoint is a >> > consumer and producer. I'm not sure how/if it works or if we hit problems >> > in other areas (exception handling, ...). >> >> We do this for the camel-smslib component. The endpoint represents a >> serial connection to an SMS modem, and therefore must deal with either >> sending or receiving of messages or both. I have no idea if this is a >> recommended approach from camel perspective, but it works for us. My >> interpretation of the camel doc was that returning `true` from >> Endpoint.isSingleton() should allow for one Endpoint per URI, but >> multiple consumers/producers tied to the Endpoint. >> >> You can see example at >> >> https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java >> > > > > --
Re: camel-smpp in trx mode
Correction I was wrong on the direct endpoint restriction. I was thinking about the log message that occurs when a exchange is send to a direct endpoint without a consumer. So perhaps there is no way to determine if there is a corresponding consuming endpoint at start. On Sun, Jan 13, 2013 at 11:19 AM, Pontus Ullgren wrote: > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller > wrote: >> The smslib model is a bit different. The smslib camel consumer pull the >> short messages for the SMSC. And only if a consumer is defined ( >> from("smslib://...") ). >> In the smpp Camel component, the SMPP library push the short messages (and >> delivery receipt messages) to the client if the client is connected in the >> TRX mode. >> Assume there is only one producer ( to("smpp://...") ) defined and no >> consumer. The SMPP library push the message to the client. Because there is >> no Camel consumer, there is no route which can consume/handle/process/... >> this message. What is a good/acceptable behavior in this case? >> > Not sure what the JSMPP library allows us to do but on a protocol level you > can > reply with a deliver_sm_resp to indicate a failed command_status. Perhaps this > is a solution if there is no consuming endpoint. > > Another solution would be to refuse to start the producer endpoint in > trx mode if > there is no corresponding consuming endpoint defined. If I do not > remember incorrectly > a similar restriction applies to direct endpoints ? > > // Pontus > > >> Best, >> Christian >> >> On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson wrote: >> >>> On 4 January 2013 17:26, Christian Müller >>> wrote: >>> > I think we don't have another camel component where the endpoint is a >>> > consumer and producer. I'm not sure how/if it works or if we hit problems >>> > in other areas (exception handling, ...). >>> >>> We do this for the camel-smslib component. The endpoint represents a >>> serial connection to an SMS modem, and therefore must deal with either >>> sending or receiving of messages or both. I have no idea if this is a >>> recommended approach from camel perspective, but it works for us. My >>> interpretation of the camel doc was that returning `true` from >>> Endpoint.isSingleton() should allow for one Endpoint per URI, but >>> multiple consumers/producers tied to the Endpoint. >>> >>> You can see example at >>> >>> https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java >>> >> >> >> >> --
Re: camel-smpp in trx mode
Yes, it's possible to share the jsmpp session, btw. we have to share it in this case (only one TRX connection is allowed). We could only log the received message, if no consumer route is defined. But may be this is not suitable for most of our users. We could also throw an exception at route/context start up, but this is not right in my opinion. Assume you do not expect to receive short message (you only send short message) and you send the messages with the flag that you are not interested in any delivery received message (part of the SMPP specification). In this case, you do not need a consumer route. The best solution I can think for this case (TRX mode connection and no consumer route) is to log the incomming message at WARN level (delivery receipt, short message, ...) and reject it. Than the SMSC should try to redeliver the short message at a later time and the user can fix this misconfiguration. What do you think? Best, Christian On Sun, Jan 13, 2013 at 11:31 AM, Pontus Ullgren wrote: > Correction I was wrong on the direct endpoint restriction. > > I was thinking about the log message that occurs when a exchange is > send to a direct endpoint without a consumer. So perhaps there is no > way to determine if there is a corresponding consuming endpoint at > start. > > On Sun, Jan 13, 2013 at 11:19 AM, Pontus Ullgren > wrote: > > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller > > wrote: > >> The smslib model is a bit different. The smslib camel consumer pull the > >> short messages for the SMSC. And only if a consumer is defined ( > >> from("smslib://...") ). > >> In the smpp Camel component, the SMPP library push the short messages > (and > >> delivery receipt messages) to the client if the client is connected in > the > >> TRX mode. > >> Assume there is only one producer ( to("smpp://...") ) defined and no > >> consumer. The SMPP library push the message to the client. Because > there is > >> no Camel consumer, there is no route which can > consume/handle/process/... > >> this message. What is a good/acceptable behavior in this case? > >> > > Not sure what the JSMPP library allows us to do but on a protocol level > you can > > reply with a deliver_sm_resp to indicate a failed command_status. > Perhaps this > > is a solution if there is no consuming endpoint. > > > > Another solution would be to refuse to start the producer endpoint in > > trx mode if > > there is no corresponding consuming endpoint defined. If I do not > > remember incorrectly > > a similar restriction applies to direct endpoints ? > > > > // Pontus > > > > > >> Best, > >> Christian > >> > >> On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson >wrote: > >> > >>> On 4 January 2013 17:26, Christian Müller > > >>> wrote: > >>> > I think we don't have another camel component where the endpoint is a > >>> > consumer and producer. I'm not sure how/if it works or if we hit > problems > >>> > in other areas (exception handling, ...). > >>> > >>> We do this for the camel-smslib component. The endpoint represents a > >>> serial connection to an SMS modem, and therefore must deal with either > >>> sending or receiving of messages or both. I have no idea if this is a > >>> recommended approach from camel perspective, but it works for us. My > >>> interpretation of the camel doc was that returning `true` from > >>> Endpoint.isSingleton() should allow for one Endpoint per URI, but > >>> multiple consumers/producers tied to the Endpoint. > >>> > >>> You can see example at > >>> > >>> > https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java > >>> > >> > >> > >> > >> -- > --
Re: camel-smpp in trx mode
Agree, log and reject would be the best solution. // Pontus On Sun, Jan 13, 2013 at 12:01 PM, Christian Müller wrote: > Yes, it's possible to share the jsmpp session, btw. we have to share it in > this case (only one TRX connection is allowed). > We could only log the received message, if no consumer route is defined. > But may be this is not suitable for most of our users. > We could also throw an exception at route/context start up, but this is not > right in my opinion. Assume you do not expect to receive short message (you > only send short message) and you send the messages with the flag that you > are not interested in any delivery received message (part of the SMPP > specification). In this case, you do not need a consumer route. > > The best solution I can think for this case (TRX mode connection and no > consumer route) is to log the incomming message at WARN level (delivery > receipt, short message, ...) and reject it. Than the SMSC should try to > redeliver the short message at a later time and the user can fix this > misconfiguration. What do you think? > > Best, > Christian > > On Sun, Jan 13, 2013 at 11:31 AM, Pontus Ullgren wrote: > >> Correction I was wrong on the direct endpoint restriction. >> >> I was thinking about the log message that occurs when a exchange is >> send to a direct endpoint without a consumer. So perhaps there is no >> way to determine if there is a corresponding consuming endpoint at >> start. >> >> On Sun, Jan 13, 2013 at 11:19 AM, Pontus Ullgren >> wrote: >> > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller >> > wrote: >> >> The smslib model is a bit different. The smslib camel consumer pull the >> >> short messages for the SMSC. And only if a consumer is defined ( >> >> from("smslib://...") ). >> >> In the smpp Camel component, the SMPP library push the short messages >> (and >> >> delivery receipt messages) to the client if the client is connected in >> the >> >> TRX mode. >> >> Assume there is only one producer ( to("smpp://...") ) defined and no >> >> consumer. The SMPP library push the message to the client. Because >> there is >> >> no Camel consumer, there is no route which can >> consume/handle/process/... >> >> this message. What is a good/acceptable behavior in this case? >> >> >> > Not sure what the JSMPP library allows us to do but on a protocol level >> you can >> > reply with a deliver_sm_resp to indicate a failed command_status. >> Perhaps this >> > is a solution if there is no consuming endpoint. >> > >> > Another solution would be to refuse to start the producer endpoint in >> > trx mode if >> > there is no corresponding consuming endpoint defined. If I do not >> > remember incorrectly >> > a similar restriction applies to direct endpoints ? >> > >> > // Pontus >> > >> > >> >> Best, >> >> Christian >> >> >> >> On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson > >wrote: >> >> >> >>> On 4 January 2013 17:26, Christian Müller > > >> >>> wrote: >> >>> > I think we don't have another camel component where the endpoint is a >> >>> > consumer and producer. I'm not sure how/if it works or if we hit >> problems >> >>> > in other areas (exception handling, ...). >> >>> >> >>> We do this for the camel-smslib component. The endpoint represents a >> >>> serial connection to an SMS modem, and therefore must deal with either >> >>> sending or receiving of messages or both. I have no idea if this is a >> >>> recommended approach from camel perspective, but it works for us. My >> >>> interpretation of the camel doc was that returning `true` from >> >>> Endpoint.isSingleton() should allow for one Endpoint per URI, but >> >>> multiple consumers/producers tied to the Endpoint. >> >>> >> >>> You can see example at >> >>> >> >>> >> https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java >> >>> >> >> >> >> >> >> >> >> -- >> > > > > --
Re: camel-smpp in trx mode
I logged a ticket: https://issues.apache.org/jira/browse/CAMEL-5963 Best, Christian On Sun, Jan 13, 2013 at 12:19 PM, Pontus Ullgren wrote: > Agree, log and reject would be the best solution. > > // Pontus > > On Sun, Jan 13, 2013 at 12:01 PM, Christian Müller > wrote: > > Yes, it's possible to share the jsmpp session, btw. we have to share it > in > > this case (only one TRX connection is allowed). > > We could only log the received message, if no consumer route is defined. > > But may be this is not suitable for most of our users. > > We could also throw an exception at route/context start up, but this is > not > > right in my opinion. Assume you do not expect to receive short message > (you > > only send short message) and you send the messages with the flag that you > > are not interested in any delivery received message (part of the SMPP > > specification). In this case, you do not need a consumer route. > > > > The best solution I can think for this case (TRX mode connection and no > > consumer route) is to log the incomming message at WARN level (delivery > > receipt, short message, ...) and reject it. Than the SMSC should try to > > redeliver the short message at a later time and the user can fix this > > misconfiguration. What do you think? > > > > Best, > > Christian > > > > On Sun, Jan 13, 2013 at 11:31 AM, Pontus Ullgren > wrote: > > > >> Correction I was wrong on the direct endpoint restriction. > >> > >> I was thinking about the log message that occurs when a exchange is > >> send to a direct endpoint without a consumer. So perhaps there is no > >> way to determine if there is a corresponding consuming endpoint at > >> start. > >> > >> On Sun, Jan 13, 2013 at 11:19 AM, Pontus Ullgren > >> wrote: > >> > On Sat, Jan 12, 2013 at 6:47 PM, Christian Müller > >> > wrote: > >> >> The smslib model is a bit different. The smslib camel consumer pull > the > >> >> short messages for the SMSC. And only if a consumer is defined ( > >> >> from("smslib://...") ). > >> >> In the smpp Camel component, the SMPP library push the short messages > >> (and > >> >> delivery receipt messages) to the client if the client is connected > in > >> the > >> >> TRX mode. > >> >> Assume there is only one producer ( to("smpp://...") ) defined and no > >> >> consumer. The SMPP library push the message to the client. Because > >> there is > >> >> no Camel consumer, there is no route which can > >> consume/handle/process/... > >> >> this message. What is a good/acceptable behavior in this case? > >> >> > >> > Not sure what the JSMPP library allows us to do but on a protocol > level > >> you can > >> > reply with a deliver_sm_resp to indicate a failed command_status. > >> Perhaps this > >> > is a solution if there is no consuming endpoint. > >> > > >> > Another solution would be to refuse to start the producer endpoint in > >> > trx mode if > >> > there is no corresponding consuming endpoint defined. If I do not > >> > remember incorrectly > >> > a similar restriction applies to direct endpoints ? > >> > > >> > // Pontus > >> > > >> > > >> >> Best, > >> >> Christian > >> >> > >> >> On Thu, Jan 10, 2013 at 1:37 PM, Alex Anderson < > a...@frontlinesms.com > >> >wrote: > >> >> > >> >>> On 4 January 2013 17:26, Christian Müller < > christian.muel...@gmail.com > >> > > >> >>> wrote: > >> >>> > I think we don't have another camel component where the endpoint > is a > >> >>> > consumer and producer. I'm not sure how/if it works or if we hit > >> problems > >> >>> > in other areas (exception handling, ...). > >> >>> > >> >>> We do this for the camel-smslib component. The endpoint represents > a > >> >>> serial connection to an SMS modem, and therefore must deal with > either > >> >>> sending or receiving of messages or both. I have no idea if this > is a > >> >>> recommended approach from camel perspective, but it works for us. > My > >> >>> interpretation of the camel doc was that returning `true` from > >> >>> Endpoint.isSingleton() should allow for one Endpoint per URI, but > >> >>> multiple consumers/producers tied to the Endpoint. > >> >>> > >> >>> You can see example at > >> >>> > >> >>> > >> > https://github.com/frontlinesms/camel-smslib/blob/master/src/main/java/net/frontlinesms/camel/smslib/SmslibEndpoint.java > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> > > > > > > > > -- > --
Re: camel-smpp in trx mode
What is the use of "systemType" paramter ? I don't see any differentiation in the code based on this parameter . Am I missing something ? The possible values are "producer" , "consumer" - ~Sandeep -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734784.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
>From the spec: 5.2.3 The system_type parameter is used to categorize the type of ESME that is binding to the SMSC. Examples include “VMS” (voice mail system) and “OTA” (over-the-air activation system). Specification of the system_type is optional - some SMSC’s may not require ESME’s to provide this detail. In this case, the ESME can set the system_type to NULL. Best, Christian - Software Integration Specialist Apache Camel committer: https://camel.apache.org/team V.P. Apache Camel: https://www.apache.org/foundation/ Apache Member: https://www.apache.org/foundation/members.html https://www.linkedin.com/pub/christian-mueller/11/551/642 On Wed, Jun 26, 2013 at 8:08 AM, sash_...@yahoo.com wrote: > What is the use of "systemType" paramter ? I don't see any differentiation > in the code based on this parameter . Am I missing something ? > The possible values are "producer" , "consumer" > > > > - > ~Sandeep > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734784.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
Re: camel-smpp in trx mode
The thorny issue with the TRX mode is that it uses a conversational pattern, not really quite supported/modeled well. Since the Endpoint is the one creating the Producers and Consumers, it could be used to share the conversation state. I believe a cleaner solution would be to model a Conversation and have consumers and producers join it. But a quick and dirty solution would do too. Cheers, Hadrian On 06/27/2013 05:28 PM, Christian Müller wrote: From the spec: 5.2.3 The system_type parameter is used to categorize the type of ESME that is binding to the SMSC. Examples include “VMS” (voice mail system) and “OTA” (over-the-air activation system). Specification of the system_type is optional - some SMSC’s may not require ESME’s to provide this detail. In this case, the ESME can set the system_type to NULL. Best, Christian - Software Integration Specialist Apache Camel committer: https://camel.apache.org/team V.P. Apache Camel: https://www.apache.org/foundation/ Apache Member: https://www.apache.org/foundation/members.html https://www.linkedin.com/pub/christian-mueller/11/551/642 On Wed, Jun 26, 2013 at 8:08 AM, sash_...@yahoo.com wrote: What is the use of "systemType" paramter ? I don't see any differentiation in the code based on this parameter . Am I missing something ? The possible values are "producer" , "consumer" - ~Sandeep -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734784.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
In that case the endpoint will hold the session. What I am not sure is what type of listener does one register with the Producer ? The listener does require the processor . - ~Sandeep -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5734973.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
Hadrian - I am eagerly waiting for the release of the SMPP component with TRX support. And I guess , this conversational state pattern is a better solutions. I am not sure how the listener at the producer side get handle to the "processor" ? - ~Sandeep -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5735017.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
Are there any progress on this issue. I see that there hasn't been mutch activity on the CAMEL-5963 issue. This must be something that is crucial for many camel users using smpp? Are there any possible workarrounds to support smpp TRX with camel? Any other components that can serve as the smpp TRX endpoint in some way? -- View this message in context: http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5748908.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel-smpp in trx mode
There was no progress on this issue until now. We use to separate connections (tx and rx). And we love contributions. If you want to take a stab on it, let us know. Best, Christian - Software Integration Specialist Apache Member V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer Apache Incubator PMC Member https://www.linkedin.com/pub/christian-mueller/11/551/642 On Mon, Mar 17, 2014 at 8:53 AM, tkvarenes wrote: > Are there any progress on this issue. I see that there hasn't been mutch > activity on the CAMEL-5963 issue. > This must be something that is crucial for many camel users using smpp? > Are there any possible workarrounds to support smpp TRX with camel? Any > other components that can serve as the smpp TRX endpoint in some way? > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/camel-smpp-in-trx-mode-tp5724608p5748908.html > Sent from the Camel - Users mailing list archive at Nabble.com. >