Hi,

>From BB's point of view each process is agnostic of the other. Each process 
>has its own sockets and cannot read the other's. There can be no mixup.

BR,
Nikos
  ----- Original Message ----- 
  From: Elton Hoxha 
  To: Alvaro Cornejo 
  Cc: kannel users 
  Sent: Wednesday, November 04, 2009 7:30 PM
  Subject: Re: SMSC name conflict???


  Thanks Alvaro but its a misundesrtanding. ITs not a matter of SMSC provider. 
Im just thinking from kannel point of view, considering the example I gave 
above.
  Actually both conenctions are live and running, but sometimes having 
interruption, connection reset by peer. When sending the enquiry link, kannel 
prints smsc name

  2009-11-04 18:28:44 [5057] [6] DEBUG: SMPP[gprs-bill]: Sending enquire link:
  2009-11-04 18:28:44 [5057] [6] DEBUG: SMPP PDU 0x973d3a8 dump:
  2009-11-04 18:28:44 [5057] [6] DEBUG:   type_name: enquire_link
  2009-11-04 18:28:44 [5057] [6] DEBUG:   command_id: 21 = 0x00000015
  2009-11-04 18:28:44 [5057] [6] DEBUG:   command_status: 0 = 0x00000000
  2009-11-04 18:28:44 [5057] [6] DEBUG:   sequence_number: 224 = 0x000000e0
  2009-11-04 18:28:44 [5057] [6] DEBUG: SMPP PDU dump ends.

  So by havving two processes by sending enqiry links or whatever with the same 
name gprs-bill, may be any problem?

  THanks


  On Wed, Nov 4, 2009 at 6:20 PM, Alvaro Cornejo <[email protected]> 
wrote:

    Elton

    I think it is more a problem from your SMSC provider. If they do allow
    you to have 2 -or more- connections to the same port or not.

    The connection resets can happen for multiple reasons including
    problems on any of the peers, the network (Lan/Wan) , etc.

    Hope helps


    
|-----------------------------------------------------------------------------------------------------------------|
    Envνe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
    celular y Nextel
    en el Perϊ, Mιxico y en mas de 180 paises. Use aplicaciones 2 vias via
    SMS y GPRS online
                 Visitenos en www.perusms.NET www.smsglobal.com.mx y
    www.pravcom.com




    On Wed, Nov 4, 2009 at 11:56 AM, Elton Hoxha <[email protected]> wrote:
    >
    > More details:
    >
    > - a.conf
    >
    > group=smsc
    > smsc=smpp
    > smsc-id=gprs-bill
    > interface-version=34
    > host=10.1.7.21
    > port=1600
    > system-id=a
    > smsc-password=a
    > system-type=a
    > transceiver-mode=true
    >
    > - b.conf
    > group=smsc
    > smsc=smpp
    > smsc-id=gprs-bill
    > interface-version=34
    > host=10.1.7.21
    > port=1600
    > system-id=b
    > smsc-password=b
    > system-type=b
    > transceiver-mode=true
    >
    > So, starting to bearerboxes (normally with different ports) may cause any
    > problem if both conf files have same smsc-id?
    >
    > Thanks
    >
    >
    >
    >
    > On Wed, Nov 4, 2009 at 5:43 PM, vijay shanker <[email protected]> 
wrote:
    >>
    >> Can not be conformed.
    >> How many connection your SMMP service provider supports?
    >> Two bearer box may be running but on different ports. Try to find out or
    >> give more relevant details.
    >> Like what is your configuration? or what is the problem you have
    >> encountered.
    >> Regards,
    >> Vijay Shanker Dubey
    >>
    >>
    >>
    >> On Wed, Nov 4, 2009 at 9:22 PM, Elton Hoxha <[email protected]> wrote:
    >>>
    >>> Hi guys,
    >>>
    >>> Is there any possibility to have conflict between two bearerbox 
processes
    >>> running in paralel, having separate smpp connection but same SMSC name??
    >>> example: gprs-bill
    >>>
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG: SMPP[gprs-bill]: Sending enquire
    >>> link:
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG: SMPP PDU 0x9743758 dump:
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG:   type_name: enquire_link
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG:   command_id: 21 = 0x00000015
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG:   command_status: 0 = 0x00000000
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG:   sequence_number: 28 = 0x0000001c
    >>> 2009-11-04 16:50:44 [5057] [6] DEBUG: SMPP PDU dump ends.
    >>>
    >>> I`m just doubting because I had some "connection reset" errors.
    >>>
    >>> Thanks
    >>
    >
    >
    >


Reply via email to