OpenBTS

The freeswitch scripts are in openbts/trunk/FreeswitchConfig/scripts.
If you have any problem deciphering how to use them, I'd be happy to
explain. You're the first person to debug the installation
instructions.

On Wed, Feb 1, 2012 at 4:06 PM, Arghyadip Paul <arghyadip@...> wrote:
> Hi Kurtis,
>
> Alright.
>
> I have configured FreeSwitch to check if  can make it working.
>
>
> I am facing the following problem.For the entire installation procedure I
> have followed all the instructions carefully from
> https://wush.net/trac/rangepublic/wiki/freeswitchConfig
>
> All my servers, SipAuthServe, smqueue, freeswitch , openbts are running in
> the same physical machine with an external IP 192.168.2.131
>
> 1. MS1 and MS2 registered to OpenBTS.
> 2. MS1 sends sms to MS2
> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]
>
> FreeSwitch Logs:
> -------------------------
>
> 2012-02-01 15:58:41.883212 [WARNING] sofia_presence.c:193 Not sending to
> local box for smsc@...
> 2012-02-01 15:58:41.883212 [ERR] sofia_presence.c:242 Chat proto [sip]
> from [IMSI404864430002302
> <sip:IMSI404864430002302@...]
> to [smsc@...]
> 00050007911989680045441111880a8179331053020000ff044ab41a0dpor
> Nobody to send to: Profile internal
>
>
> In Addition to above analysis:
> ------------------------------------------
>
> I can see when smqueue start, it gives following error logs:
> It fails to bind to port 5063
>
> Feb  1 16:02:09 moment-portable smqueue: ALERT 3078641888
> smqueue.cpp:2347:main: smqueue (re)starting
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> HLR.cpp:294:getCLIDLocal: getCLIDLocal(IMSI001010000000000)
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> HLR.cpp:202:sqlLocal: select callerid from sip_buddies where name =
> "IMSI001010000000000"
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> HLR.cpp:242:sqlQuery: result = 2100
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> smnet.cpp:319:listen_on_port: Listening at address '0.0.0.0:5063'.
> Feb  1 16:02:09 moment-portable smqueue: ERR 3078641888
> smnet.cpp:301:listen_on_port: listen_on_port(5063) can't bind to addr
> ':::5063': Address already in use
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:2390:main: My own IP address is configured as 127.0.0.1
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:2391:main: The HLR registry is at 192.168.2.131
> Feb  1 16:02:09 moment-portable smqueue: WARNING 3078641888
> smqueue.cpp:2396:main: Failed to read queue from file /tmp/save
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:2398:main: Queue contains 0 msgs.
> Feb  1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:1996:main_loop: === Feb  1 16:02:09 0 queued; waiting
>
>
>
> In your last mail, you talked about a script which will take care for
> converting a SIP MESSAGE from external entity with text/plain to 3gpp
> equivalent and forwarding to Smqueue. Is the script part of SVN else please
> tell me how can I get that script.
>
> Thanks and Regards,
> Arghyadip
>
>
>
> On Tue, Jan 31, 2012 at 4:08 PM, Kurtis Heimerl <kheimerl@...>
> wrote:
>>
>> As I stated before, this is working with FreeSWITCH, as well as
>> supporting routing for inbound messages.
>>
>> There's an ongoing effort to implement a new message server
>> (https://wush.net/trac/rangepublic/wiki/SMQ2) due to the limitations
>> of smqueue. I don't think we're likely to spend a great deal of effort
>> enabling new features, but I'm happy to receive patches towards that
>> end.
>>
>> On Tue, Jan 31, 2012 at 3:55 PM, Arghyadip Paul <arghyadip@...>
>> wrote:
>> > Kurtis/David,
>> >
>> > Yeah..I also feel, this will be the opportunity to make Smqueue/Asterisk
>> > more robust.
>> >
>> > Well, I run some testing with my local set up. I tried to send one SIP
>> > MESSAGE destined to one MS registered to OpenBTS from an external IM
>> > client
>> > which implements RFC 3428 UAC.
>> >
>> > As an address  of record of the MS I have used the registered SIP user
>> > id of
>> > the message but getting this abnormal behavior.
>> >
>> > i. External RFC 3428 UAC sends MESSAGE to Smqueue destined to MS in
>> > OpenBTS.
>> > ii. Smqueue responds with 405 Method not allowed.
>> >
>> >
>> > There was no corruption at the SIP Packet level in the MESSAGE request.
>> > So,
>> > I guess, this is an issue with the Smqueue itself. As of now, I am
>> > thinking
>> > of only in one direction where SIP MESSAGE can be sent from external
>> > entity
>> > to an MS in the OpenBTS. Obviously at this point I am not considering MS
>> > to
>> > outside world SIP MESSAGE, where we may need to incorporate Asterisk for
>> > routing.
>> >
>> > Do you think we can fix this? Anyhow this is not an expected behavior of
>> > Smqueue as Smqueue should be able to route the MESSAGE to the proper MS
>> > identified by the SIP AOR in the from header in the SIP MESSAGE method.
>> >
>> > I am also analyzing the code, and can give you update on this, if I find
>> > anything problematic.
>> >
>> > SIP Logs are below:
>> > -----------------------------
>> >
>> > MESSAGE sip:IMSI404864430002302@... SIP/2.0
>> > Via: SIP/2.0/UDP
>> >
>> > 192.168.2.131:5061;rport;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy
>> > Max-Forwards: 70
>> > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
>> > To: <sip:IMSI404864430002302@...>
>> > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
>> > CSeq: 51023 MESSAGE
>> > Content-Type: text/plain
>> > Content-Length:     2
>> >
>> > jk
>> >
>> > SIP/2.0 405 Method Not Allowed
>> > Via: SIP/2.0/UDP
>> >
>> > 192.168.2.131:5061;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy;received=192.168.2.131;rport=5061
>> > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
>> > To: <sip:IMSI404864430002302@...
>> > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
>> > CSeq: 51023 MESSAGE
>> > Server: Asterisk PBX 1.6.2.21
>> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>> > Supported: replaces, timer
>> > Content-Length: 0
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Jan 31, 2012 at 7:53 AM, David Burgess <david@...>
>> > wrote:
>> >>
>> >> If you two do have that conversation, don't just keep it to yourselves.
>> >> The Asterisk/smqueue model is due for an overhaul. They served us well
>> >> for
>> >> early years of the project, but we are starting to hit limitations on
>> >> both
>> >> of them.
>> >>
>> >>
>> >> Range Networks, Inc.
>> >> 560 Brannan St.
>> >> San Francisco, CA
>> >>
>> >> -----Original Message-----
>> >> From: Kurtis Heimerl <kheimerl@...>
>> >> Date: Tue, 31 Jan 2012 00:33:48
>> >> To: Arghyadip Paul<arghyadip@...>
>> >> Cc: <openbts-discuss@...>
>> >> Subject: Re: [Openbts-discuss] SMS "text/plain" Failed.
>> >>
>> >> It's quite likely that smqueue does (or is supposed to) support what
>> >> you are looking for. You'll need to check the source code to be
>> >> certain, I may find some time to do that myself.
>> >>
>> >> At the same time, you'll still have a very difficult time integrating
>> >> with any external sip routing engines. How does a user direct an
>> >> outward facing SMS to a SIP client? It's for these reasons (as well as
>> >> many others) I moved to the freeswitch implementation. It's worth
>> >> noting that freeswitch is NOT a PBX, it's a softswitch. It routes
>> >> stuff, of which SIP voice traffic is just one item. As such, we
>> >> eventually got it to route SIP message traffic as well, providing a
>> >> dialplan-like interface for routing our OpenBTS SMS messages. I think
>> >> this is significantly more elegant than the current shortcode system
>> >> in smqueue. In my architecture, smqueue is used solely for
>> >> store-and-forwarding, not routing, which is done in the softswitch.
>> >> We're starting to build out tools for doing this routing and
>> >> interfacing with existing SIP engines.
>> >>
>> >> If any of this could support what you folks are doing, or has any
>> >> overlap, we should talk.
>> >>
>> >> On Mon, Jan 30, 2012 at 11:39 PM, Arghyadip Paul <arghyadip@...>
>> >> wrote:
>> >> > Dear Kurtis,
>> >> >
>> >> > Thanks for your mail.
>> >> >
>> >> > I actually followed the following patch of text from the OpenBTS 2.8
>> >> > manual
>> >> > about Smqueue.
>> >> >
>> >> > "The message arrives at smqueue from the outside world addressed
>> >> > either
>> >> > to a
>> >> > SIP user or to a numeric address. Smqueue resolves the destination
>> >> > address
>> >> > to an IMSI-based SIP user name and forwards the message to OpenBTS.
>> >> > OpenBTS
>> >> > pages the MS, establishes a channel, transfers the message as SMS and
>> >> > then
>> >> > responds to smqueue with 200 OK."
>> >> >
>> >> > With this patch of text in the manual and along with the
>> >> > configuration
>> >> > values present in the OpenBTS for SMS MIME, I thought expected
>> >> > behavior
>> >> > from
>> >> > Smqueue would be to accept any form of a valid SIP MESSAGE destined
>> >> > to
>> >> > one
>> >> > of the registered MS and if any outside entity is sending a SIP
>> >> > MESSAGE
>> >> > destined to SIP address of an MS in OpenBTS , smqueue will be able to
>> >> > resolve and forward the SIP MESSAGE.
>> >> >
>> >> > I don't use FreeSwitch as a PBX and instead I use Asterisk. Also,
>> >> > don't
>> >> > you
>> >> > think involving the PBX here would be complication in the design.
>> >> > Instead if
>> >> > we can run the same script whatever you are running in FreeSwitch in
>> >> > Smqueue
>> >> > which will take care for converting the MESSAGE 's content to 3GPP.
>> >> >
>> >> > I am not sure if I am right here. But you still insist then , I
>> >> > should
>> >> > start
>> >> > configuring my set up with FreeSwitch to get the thing working.
>> >> >
>> >> > Regards,
>> >> > Arghyadip
>> >> >
>> >> > On Mon, Jan 30, 2012 at 9:08 PM, Kurtis Heimerl
>> >> > <kheimerl@...>
>> >> > wrote:
>> >> >>
>> >> >> I think the MIME type is configurable so that you can use an
>> >> >> existing
>> >> >> SIP MESSAGE server to talk directly to OpenBTS. It has a number of
>> >> >> limitations regardless, as text/plain does not support anything but
>> >> >> ASCII.
>> >> >>
>> >> >> My freeSWITCH scripts begin to address your concern. Basically,
>> >> >> external services can send SIP MESSAGEs into freeSWITCH, which then
>> >> >> encodes them as 3gpp traffic and directs them to smqueue. We can
>> >> >> talk
>> >> >> about this offline if you have a specific use, I'd be happy to
>> >> >> support
>> >> >> whatever you are doing or hoping to do.
>> >> >>
>> >> >> On Mon, Jan 30, 2012 at 7:11 PM, Arghyadip Paul
>> >> >> <arghyadip@...>
>> >> >> wrote:
>> >> >> > I guess it should.
>> >> >> >
>> >> >> > If some external entity wants to send SMS or IM through the means
>> >> >> > of
>> >> >> > SMQUEUE
>> >> >> > to a UE which is in OpenBTS, current implementation fails.
>> >> >> > If we imagine of one unified messaging system where we want to
>> >> >> > reach
>> >> >> > someone
>> >> >> > with a UE in OpenBTS from the internet world through the means of
>> >> >> > SIP
>> >> >> > MESSAGE from a SIP based IM client then the standard
>> >> >> > recommendation
>> >> >> > is
>> >> >> > to
>> >> >> > use any of the content type it RFC3428 does not mandate any
>> >> >> > particular
>> >> >> > MIME
>> >> >> > type.
>> >> >> >
>> >> >> > Also, if the plain/text is not needed then I am not sure why there
>> >> >> > is
>> >> >> > the
>> >> >> > need to make the SMS MIME type configurable?
>> >> >> >
>> >> >> > Regards,
>> >> >> > Arghyadip
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Jan 30, 2012 at 6:16 PM, Kurtis Heimerl
>> >> >> > <kheimerl@...>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> This is an open question: Is smqueue supposed to handle
>> >> >> >> text/plain
>> >> >> >> messages?
>> >> >> >>
>> >> >> >> On Mon, Jan 30, 2012 at 6:03 PM, Arghyadip Paul
>> >> >> >> <arghyadip@...>
>> >> >> >> wrote:
>> >> >> >> > Hi All,
>> >> >> >> >
>> >> >> >> > I am trying to send SMS from one UE to another and I wanted to
>> >> >> >> > skip
>> >> >> >> > the
>> >> >> >> > end
>> >> >> >> > to end encryption. To do that , I configured the following
>> >> >> >> > parameters
>> >> >> >> > as
>> >> >> >> > follows in OpenBTS.db
>> >> >> >> >
>> >> >> >> > 1. SIP.SMSC = NULL
>> >> >> >> > 2. SMS.MIMEType = text/plain
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > I followed the direction from the manual where it is said:
>> >> >> >> >
>> >> >> >> > "SIP.SMSC – The SMSC handler in smqueue. This is the entity
>> >> >> >> > that
>> >> >> >> > handles
>> >> >> >> > full 3GPP MIME-
>> >> >> >> > encapsulted TPDUs. If not defined, use direct numeric
>> >> >> >> > addressing.
>> >> >> >> > Normally
>> >> >> >> > the value is NULL if
>> >> >> >> > SMS.MIMIEType is ”text/plain” or ”smsc” if SMS.MIMEType is
>> >> >> >> > ”application/vnd.3gpp”.
>> >> >> >> > "
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > But using these set of configuration I am getting the following
>> >> >> >> > bad
>> >> >> >> > behavior:
>> >> >> >> >
>> >> >> >> > 1. UE one sends the SMS.
>> >> >> >> > 2. OpenBTS forwards the SIP MESSAGE to Smqueue.
>> >> >> >> > 3. Smqueue respondes with 484 Address Incomplete
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > From my initial analysis , I think the problem is due to bad
>> >> >> >> > "to"
>> >> >> >> > header
>> >> >> >> > in
>> >> >> >> > the SIP MESSAGE:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > MESSAGE sip:@127.0.0.1 SIP/2.0
>> >> >> >> > Via: SIP/2.0/UDP
>> >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
>> >> >> >> > From: IMSI404864415448667
>> >> >> >> > <sip:IMSI404864415448667@...
>> >> >> >> > To:  <sip:@127.0.0.1>
>> >> >> >> > Call-ID: 1488923392@...
>> >> >> >> > CSeq: 59 MESSAGE
>> >> >> >> > Content-Type: text/plain
>> >> >> >> > Max-Forwards: 5
>> >> >> >> > Content-Length:     3
>> >> >> >> >
>> >> >> >> > Che.SIP/2.0 484 Address Incomplete
>> >> >> >> > Via: SIP/2.0/UDP
>> >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
>> >> >> >> > From: IMSI404864415448667
>> >> >> >> > <sip:IMSI404864415448667@...
>> >> >> >> > To: <sip:127.0.0.1>
>> >> >> >> > Call-ID: 1488923392@...
>> >> >> >> > CSeq: 59 MESSAGE
>> >> >> >> > Content-Length: 0
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Guess, its a bug.
>> >> >> >> > --
>> >> >> >> > Arghyadip Paul
>> >> >> >> > Graduate Student
>> >> >> >> > Department of Computer Science
>> >> >> >> > University of California Santa Barbara
>> >> >> >> > Santa Barbara , CA 93106 USA
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > ------------------------------------------------------------------------------
>> >> >> >> > Keep Your Developer Skills Current with LearnDevNow!
>> >> >> >> > The most comprehensive online learning library for Microsoft
>> >> >> >> > developers
>> >> >> >> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
>> >> >> >> > CSS3,
>> >> >> >> > MVC3,
>> >> >> >> > Metro Style Apps, more. Free future releases when you subscribe
>> >> >> >> > now!
>> >> >> >> > http://p.sf.net/sfu/learndevnow-d2d
>> >> >> >> > _______________________________________________
>> >> >> >> > Openbts-discuss mailing list
>> >> >> >> > Openbts-discuss@...
>> >> >> >> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Arghyadip Paul
>> >> >> > Graduate Student
>> >> >> > Department of Computer Science
>> >> >> > University of California Santa Barbara
>> >> >> > Santa Barbara , CA 93106 USA
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Arghyadip Paul
>> >> > Graduate Student
>> >> > Department of Computer Science
>> >> > University of California Santa Barbara
>> >> > Santa Barbara , CA 93106 USA
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Keep Your Developer Skills Current with LearnDevNow!
>> >> The most comprehensive online learning library for Microsoft developers
>> >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
>> >> MVC3,
>> >> Metro Style Apps, more. Free future releases when you subscribe now!
>> >> http://p.sf.net/sfu/learndevnow-d2d
>> >> _______________________________________________
>> >> Openbts-discuss mailing list
>> >> Openbts-discuss@...
>> >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>> >>
>> >
>> >
>> >
>> > --
>> > Arghyadip Paul
>> > Graduate Student
>> > Department of Computer Science
>> > University of California Santa Barbara
>> > Santa Barbara , CA 93106 USA
>> >
>
>
>
>
> --
> Arghyadip Paul
> Graduate Student
> Department of Computer Science
> University of California Santa Barbara
> Santa Barbara , CA 93106 USA
>

The bind to port error message that you are seeing means that smqueue
cannot bind to the IPv6 port 5063. Don't worry about that (unless you
are trying to set up an IPv6 network). As long as you don't see an error
about binding to "127.0.0.1:5063", you are fine. :)

Best,

Donald C. Kirker
Range Networks, Inc.


On 2/1/12 4:06 PM, Arghyadip Paul wrote:
> Hi Kurtis,
>
> Alright.
>
> I have configured FreeSwitch to check if can make it working.
>
>
> I am facing the following problem.For the entire installation
> procedure I have followed all the instructions carefully from
> https://wush.net/trac/rangepublic/wiki/freeswitchConfig
>
> All my servers, SipAuthServe, smqueue, freeswitch , openbts are
> running in the same physical machine with an external IP 192.168.2.131
>
> 1. MS1 and MS2 registered to OpenBTS.
> 2. MS1 sends sms to MS2
> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]
>
> FreeSwitch Logs:
> -------------------------
>
> 2012-02-01 15:58:41.883212 [WARNING] sofia_presence.c:193 Not sending
> to local box for smsc@... <mailto:smsc@...>
> 2012-02-01 15:58:41.883212 [ERR] sofia_presence.c:242 Chat proto [sip]
> from [IMSI404864430002302 <sip:IMSI404864430002302@...
> <mailto:sip%3AIMSI404864430002302@...]
> to [smsc@... <mailto:smsc@...>]
> 00050007911989680045441111880a8179331053020000ff044ab41a0dpor
> Nobody to send to: Profile internal
>
>
> In Addition to above analysis:
> ------------------------------------------
>
> I can see when smqueue start, it gives following error logs:
> It fails to bind to port 5063
>
> Feb 1 16:02:09 moment-portable smqueue: ALERT 3078641888
> smqueue.cpp:2347:main: smqueue (re)starting
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> HLR.cpp:294:getCLIDLocal: getCLIDLocal(IMSI001010000000000)
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> HLR.cpp:202:sqlLocal: select callerid from sip_buddies where name =
> "IMSI001010000000000"
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> HLR.cpp:242:sqlQuery: result = 2100
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> smnet.cpp:319:listen_on_port: Listening at address '0.0.0.0:5063
> <http://0.0.0.0:5063>'.
> Feb 1 16:02:09 moment-portable smqueue: ERR 3078641888
> smnet.cpp:301:listen_on_port: listen_on_port(5063) can't bind to addr
> ':::5063': Address already in use
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:2390:main: My own IP address is configured as 127.0.0.1
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:2391:main: The HLR registry is at 192.168.2.131
> Feb 1 16:02:09 moment-portable smqueue: WARNING 3078641888
> smqueue.cpp:2396:main: Failed to read queue from file /tmp/save
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:2398:main: Queue contains 0 msgs.
> Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> smqueue.cpp:1996:main_loop: === Feb 1 16:02:09 0 queued; waiting
>
>
>
> In your last mail, you talked about a script which will take care for
> converting a SIP MESSAGE from external entity with text/plain to 3gpp
> equivalent and forwarding to Smqueue. Is the script part of SVN else
> please tell me how can I get that script.
>
> Thanks and Regards,
> Arghyadip
>
>
> On Tue, Jan 31, 2012 at 4:08 PM, Kurtis Heimerl
> <kheimerl@... <mailto:kheimerl@...>> wrote:
>
>     As I stated before, this is working with FreeSWITCH, as well as
>     supporting routing for inbound messages.
>
>     There's an ongoing effort to implement a new message server
>     (https://wush.net/trac/rangepublic/wiki/SMQ2) due to the limitations
>     of smqueue. I don't think we're likely to spend a great deal of effort
>     enabling new features, but I'm happy to receive patches towards that
>     end.
>
>     On Tue, Jan 31, 2012 at 3:55 PM, Arghyadip Paul
>     <arghyadip@... <mailto:arghyadip@...>> wrote:
>     > Kurtis/David,
>     >
>     > Yeah..I also feel, this will be the opportunity to make
>     Smqueue/Asterisk
>     > more robust.
>     >
>     > Well, I run some testing with my local set up. I tried to send
>     one SIP
>     > MESSAGE destined to one MS registered to OpenBTS from an
>     external IM client
>     > which implements RFC 3428 UAC.
>     >
>     > As an address of record of the MS I have used the registered SIP
>     user id of
>     > the message but getting this abnormal behavior.
>     >
>     > i. External RFC 3428 UAC sends MESSAGE to Smqueue destined to MS
>     in OpenBTS.
>     > ii. Smqueue responds with 405 Method not allowed.
>     >
>     >
>     > There was no corruption at the SIP Packet level in the MESSAGE
>     request. So,
>     > I guess, this is an issue with the Smqueue itself. As of now, I
>     am thinking
>     > of only in one direction where SIP MESSAGE can be sent from
>     external entity
>     > to an MS in the OpenBTS. Obviously at this point I am not
>     considering MS to
>     > outside world SIP MESSAGE, where we may need to incorporate
>     Asterisk for
>     > routing.
>     >
>     > Do you think we can fix this? Anyhow this is not an expected
>     behavior of
>     > Smqueue as Smqueue should be able to route the MESSAGE to the
>     proper MS
>     > identified by the SIP AOR in the from header in the SIP MESSAGE
>     method.
>     >
>     > I am also analyzing the code, and can give you update on this,
>     if I find
>     > anything problematic.
>     >
>     > SIP Logs are below:
>     > -----------------------------
>     >
>     > MESSAGE sip:IMSI404864430002302@...
>     <mailto:sip%3AIMSI404864430002302@...> SIP/2.0
>     > Via: SIP/2.0/UDP
>     >
>     192.168.2.131:5061;rport;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy
>     > Max-Forwards: 70
>     > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
>     > To: <sip:IMSI404864430002302@...
>     <mailto:sip%3AIMSI404864430002302@...>>
>     > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
>     > CSeq: 51023 MESSAGE
>     > Content-Type: text/plain
>     > Content-Length: 2
>     >
>     > jk
>     >
>     > SIP/2.0 405 Method Not Allowed
>     > Via: SIP/2.0/UDP
>     >
>     192.168.2.131:5061;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy;received=192.168.2.131;rport=5061
>     > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
>     > To: <sip:IMSI404864430002302@...
>     <mailto:sip%3AIMSI404864430002302@...
>     > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
>     > CSeq: 51023 MESSAGE
>     > Server: Asterisk PBX 1.6.2.21
>     > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>     NOTIFY, INFO
>     > Supported: replaces, timer
>     > Content-Length: 0
>     >
>     >
>     >
>     >
>     >
>     >
>     > On Tue, Jan 31, 2012 at 7:53 AM, David Burgess
>     <david@... <mailto:david@...>>
>     > wrote:
>     >>
>     >> If you two do have that conversation, don't just keep it to
>     yourselves.
>     >> The Asterisk/smqueue model is due for an overhaul. They served
>     us well for
>     >> early years of the project, but we are starting to hit
>     limitations on both
>     >> of them.
>     >>
>     >>
>     >> Range Networks, Inc.
>     >> 560 Brannan St.
>     >> San Francisco, CA
>     >>
>     >> -----Original Message-----
>     >> From: Kurtis Heimerl <kheimerl@...
>     <mailto:kheimerl@...>>
>     >> Date: Tue, 31 Jan 2012 00:33:48
>     >> To: Arghyadip Paul<arghyadip@...
>     <mailto:arghyadip@...>>
>     >> Cc: <openbts-discuss@...
>     <mailto:openbts-discuss@...>>
>     >> Subject: Re: [Openbts-discuss] SMS "text/plain" Failed.
>     >>
>     >> It's quite likely that smqueue does (or is supposed to) support
>     what
>     >> you are looking for. You'll need to check the source code to be
>     >> certain, I may find some time to do that myself.
>     >>
>     >> At the same time, you'll still have a very difficult time
>     integrating
>     >> with any external sip routing engines. How does a user direct an
>     >> outward facing SMS to a SIP client? It's for these reasons (as
>     well as
>     >> many others) I moved to the freeswitch implementation. It's worth
>     >> noting that freeswitch is NOT a PBX, it's a softswitch. It routes
>     >> stuff, of which SIP voice traffic is just one item. As such, we
>     >> eventually got it to route SIP message traffic as well, providing a
>     >> dialplan-like interface for routing our OpenBTS SMS messages. I
>     think
>     >> this is significantly more elegant than the current shortcode
>     system
>     >> in smqueue. In my architecture, smqueue is used solely for
>     >> store-and-forwarding, not routing, which is done in the softswitch.
>     >> We're starting to build out tools for doing this routing and
>     >> interfacing with existing SIP engines.
>     >>
>     >> If any of this could support what you folks are doing, or has any
>     >> overlap, we should talk.
>     >>
>     >> On Mon, Jan 30, 2012 at 11:39 PM, Arghyadip Paul
>     <arghyadip@... <mailto:arghyadip@...>>
>     >> wrote:
>     >> > Dear Kurtis,
>     >> >
>     >> > Thanks for your mail.
>     >> >
>     >> > I actually followed the following patch of text from the
>     OpenBTS 2.8
>     >> > manual
>     >> > about Smqueue.
>     >> >
>     >> > "The message arrives at smqueue from the outside world
>     addressed either
>     >> > to a
>     >> > SIP user or to a numeric address. Smqueue resolves the
>     destination
>     >> > address
>     >> > to an IMSI-based SIP user name and forwards the message to
>     OpenBTS.
>     >> > OpenBTS
>     >> > pages the MS, establishes a channel, transfers the message as
>     SMS and
>     >> > then
>     >> > responds to smqueue with 200 OK."
>     >> >
>     >> > With this patch of text in the manual and along with the
>     configuration
>     >> > values present in the OpenBTS for SMS MIME, I thought
>     expected behavior
>     >> > from
>     >> > Smqueue would be to accept any form of a valid SIP MESSAGE
>     destined to
>     >> > one
>     >> > of the registered MS and if any outside entity is sending a
>     SIP MESSAGE
>     >> > destined to SIP address of an MS in OpenBTS , smqueue will be
>     able to
>     >> > resolve and forward the SIP MESSAGE.
>     >> >
>     >> > I don't use FreeSwitch as a PBX and instead I use Asterisk.
>     Also, don't
>     >> > you
>     >> > think involving the PBX here would be complication in the design.
>     >> > Instead if
>     >> > we can run the same script whatever you are running in
>     FreeSwitch in
>     >> > Smqueue
>     >> > which will take care for converting the MESSAGE 's content to
>     3GPP.
>     >> >
>     >> > I am not sure if I am right here. But you still insist then ,
>     I should
>     >> > start
>     >> > configuring my set up with FreeSwitch to get the thing working.
>     >> >
>     >> > Regards,
>     >> > Arghyadip
>     >> >
>     >> > On Mon, Jan 30, 2012 at 9:08 PM, Kurtis Heimerl
>     >> > <kheimerl@... <mailto:kheimerl@...>>
>     >> > wrote:
>     >> >>
>     >> >> I think the MIME type is configurable so that you can use an
>     existing
>     >> >> SIP MESSAGE server to talk directly to OpenBTS. It has a
>     number of
>     >> >> limitations regardless, as text/plain does not support
>     anything but
>     >> >> ASCII.
>     >> >>
>     >> >> My freeSWITCH scripts begin to address your concern. Basically,
>     >> >> external services can send SIP MESSAGEs into freeSWITCH,
>     which then
>     >> >> encodes them as 3gpp traffic and directs them to smqueue. We
>     can talk
>     >> >> about this offline if you have a specific use, I'd be happy
>     to support
>     >> >> whatever you are doing or hoping to do.
>     >> >>
>     >> >> On Mon, Jan 30, 2012 at 7:11 PM, Arghyadip Paul
>     <arghyadip@... <mailto:arghyadip@...>>
>     >> >> wrote:
>     >> >> > I guess it should.
>     >> >> >
>     >> >> > If some external entity wants to send SMS or IM through
>     the means of
>     >> >> > SMQUEUE
>     >> >> > to a UE which is in OpenBTS, current implementation fails.
>     >> >> > If we imagine of one unified messaging system where we
>     want to reach
>     >> >> > someone
>     >> >> > with a UE in OpenBTS from the internet world through the
>     means of SIP
>     >> >> > MESSAGE from a SIP based IM client then the standard
>     recommendation
>     >> >> > is
>     >> >> > to
>     >> >> > use any of the content type it RFC3428 does not mandate any
>     >> >> > particular
>     >> >> > MIME
>     >> >> > type.
>     >> >> >
>     >> >> > Also, if the plain/text is not needed then I am not sure
>     why there is
>     >> >> > the
>     >> >> > need to make the SMS MIME type configurable?
>     >> >> >
>     >> >> > Regards,
>     >> >> > Arghyadip
>     >> >> >
>     >> >> >
>     >> >> > On Mon, Jan 30, 2012 at 6:16 PM, Kurtis Heimerl
>     >> >> > <kheimerl@... <mailto:kheimerl@...>>
>     >> >> > wrote:
>     >> >> >>
>     >> >> >> This is an open question: Is smqueue supposed to handle
>     text/plain
>     >> >> >> messages?
>     >> >> >>
>     >> >> >> On Mon, Jan 30, 2012 at 6:03 PM, Arghyadip Paul
>     >> >> >> <arghyadip@... <mailto:arghyadip@...>>
>     >> >> >> wrote:
>     >> >> >> > Hi All,
>     >> >> >> >
>     >> >> >> > I am trying to send SMS from one UE to another and I
>     wanted to
>     >> >> >> > skip
>     >> >> >> > the
>     >> >> >> > end
>     >> >> >> > to end encryption. To do that , I configured the following
>     >> >> >> > parameters
>     >> >> >> > as
>     >> >> >> > follows in OpenBTS.db
>     >> >> >> >
>     >> >> >> > 1. SIP.SMSC = NULL
>     >> >> >> > 2. SMS.MIMEType = text/plain
>     >> >> >> >
>     >> >> >> >
>     >> >> >> > I followed the direction from the manual where it is said:
>     >> >> >> >
>     >> >> >> > "SIP.SMSC – The SMSC handler in smqueue. This is the
>     entity that
>     >> >> >> > handles
>     >> >> >> > full 3GPP MIME-
>     >> >> >> > encapsulted TPDUs. If not defined, use direct numeric
>     addressing.
>     >> >> >> > Normally
>     >> >> >> > the value is NULL if
>     >> >> >> > SMS.MIMIEType is ”text/plain” or ”smsc” if SMS.MIMEType is
>     >> >> >> > ”application/vnd.3gpp”.
>     >> >> >> > "
>     >> >> >> >
>     >> >> >> >
>     >> >> >> > But using these set of configuration I am getting the
>     following
>     >> >> >> > bad
>     >> >> >> > behavior:
>     >> >> >> >
>     >> >> >> > 1. UE one sends the SMS.
>     >> >> >> > 2. OpenBTS forwards the SIP MESSAGE to Smqueue.
>     >> >> >> > 3. Smqueue respondes with 484 Address Incomplete
>     >> >> >> >
>     >> >> >> >
>     >> >> >> > From my initial analysis , I think the problem is due
>     to bad "to"
>     >> >> >> > header
>     >> >> >> > in
>     >> >> >> > the SIP MESSAGE:
>     >> >> >> >
>     >> >> >> >
>     >> >> >> > MESSAGE sip:@127.0.0.1 <mailto:sip%3A@...> SIP/2.0
>     >> >> >> > Via: SIP/2.0/UDP
>     >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
>     >> >> >> > From: IMSI404864415448667
>     >> >> >> > <sip:IMSI404864415448667@...
>     <mailto:sip%3AIMSI404864415448667@...
>     >> >> >> > To: <sip:@127.0.0.1 <mailto:sip%3A@...>>
>     >> >> >> > Call-ID: 1488923392@... <mailto:1488923392@...>
>     >> >> >> > CSeq: 59 MESSAGE
>     >> >> >> > Content-Type: text/plain
>     >> >> >> > Max-Forwards: 5
>     >> >> >> > Content-Length: 3
>     >> >> >> >
>     >> >> >> > Che.SIP/2.0 484 Address Incomplete
>     >> >> >> > Via: SIP/2.0/UDP
>     >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
>     >> >> >> > From: IMSI404864415448667
>     >> >> >> > <sip:IMSI404864415448667@...
>     <mailto:sip%3AIMSI404864415448667@...
>     >> >> >> > To: <sip:127.0.0.1>
>     >> >> >> > Call-ID: 1488923392@... <mailto:1488923392@...>
>     >> >> >> > CSeq: 59 MESSAGE
>     >> >> >> > Content-Length: 0
>     >> >> >> >
>     >> >> >> >
>     >> >> >> >
>     >> >> >> > Guess, its a bug.
>     >> >> >> > --
>     >> >> >> > Arghyadip Paul
>     >> >> >> > Graduate Student
>     >> >> >> > Department of Computer Science
>     >> >> >> > University of California Santa Barbara
>     >> >> >> > Santa Barbara , CA 93106 USA
>     >> >> >> >
>     >> >> >> >
>     >> >> >> >
>     >> >> >> >
>     >> >> >> >
>     >> >> >> >
>     ------------------------------------------------------------------------------
>     >> >> >> > Keep Your Developer Skills Current with LearnDevNow!
>     >> >> >> > The most comprehensive online learning library for
>     Microsoft
>     >> >> >> > developers
>     >> >> >> > is just $99.99! Visual Studio, SharePoint, SQL - plus
>     HTML5, CSS3,
>     >> >> >> > MVC3,
>     >> >> >> > Metro Style Apps, more. Free future releases when you
>     subscribe
>     >> >> >> > now!
>     >> >> >> > http://p.sf.net/sfu/learndevnow-d2d
>     >> >> >> > _______________________________________________
>     >> >> >> > Openbts-discuss mailing list
>     >> >> >> > Openbts-discuss@...
>     <mailto:Openbts-discuss@...>
>     >> >> >> >
>     https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>     >> >> >> >
>     >> >> >
>     >> >> >
>     >> >> >
>     >> >> >
>     >> >> > --
>     >> >> > Arghyadip Paul
>     >> >> > Graduate Student
>     >> >> > Department of Computer Science
>     >> >> > University of California Santa Barbara
>     >> >> > Santa Barbara , CA 93106 USA
>     >> >> >
>     >> >
>     >> >
>     >> >
>     >> >
>     >> > --
>     >> > Arghyadip Paul
>     >> > Graduate Student
>     >> > Department of Computer Science
>     >> > University of California Santa Barbara
>     >> > Santa Barbara , CA 93106 USA
>     >> >
>     >>
>     >>
>     >>
>     ------------------------------------------------------------------------------
>     >> Keep Your Developer Skills Current with LearnDevNow!
>     >> The most comprehensive online learning library for Microsoft
>     developers
>     >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
>     CSS3, MVC3,
>     >> Metro Style Apps, more. Free future releases when you subscribe
>     now!
>     >> http://p.sf.net/sfu/learndevnow-d2d
>     >> _______________________________________________
>     >> Openbts-discuss mailing list
>     >> Openbts-discuss@...
>     <mailto:Openbts-discuss@...>
>     >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>     >>
>     >
>     >
>     >
>     > --
>     > Arghyadip Paul
>     > Graduate Student
>     > Department of Computer Science
>     > University of California Santa Barbara
>     > Santa Barbara , CA 93106 USA
>     >
>
>
>
>
> -- 
> Arghyadip Paul
> Graduate Student
> Department of Computer Science
> University of California Santa Barbara
> Santa Barbara , CA 93106 USA
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
> _______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss

@Thanks Kurtis and Donald for your comment


Do you guys have any catch why the SMS is not getting forwarded from
Freeswitch to Smqueue??

Can you show me some line why this logs are coming

Nobody to send to: Profile internal

Honestly today is my first day with freeswitch and I dont have any idea why
this is happening.
On Wed, Feb 1, 2012 at 4:13 PM, Donald Kirker <
donald.kirker@...> wrote:

> The bind to port error message that you are seeing means that smqueue
> cannot bind to the IPv6 port 5063. Don't worry about that (unless you
> are trying to set up an IPv6 network). As long as you don't see an error
> about binding to "127.0.0.1:5063", you are fine. :)
>
> Best,
>
> Donald C. Kirker
> Range Networks, Inc.
>
>
> On 2/1/12 4:06 PM, Arghyadip Paul wrote:
> > Hi Kurtis,
> >
> > Alright.
> >
> > I have configured FreeSwitch to check if can make it working.
> >
> >
> > I am facing the following problem.For the entire installation
> > procedure I have followed all the instructions carefully from
> > https://wush.net/trac/rangepublic/wiki/freeswitchConfig
> >
> > All my servers, SipAuthServe, smqueue, freeswitch , openbts are
> > running in the same physical machine with an external IP 192.168.2.131
> >
> > 1. MS1 and MS2 registered to OpenBTS.
> > 2. MS1 sends sms to MS2
> > 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
> > 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not
> Ok]
> >
> > FreeSwitch Logs:
> > -------------------------
> >
> > 2012-02-01 15:58:41.883212 [WARNING] sofia_presence.c:193 Not sending
> > to local box for smsc@... <mailto:smsc@...>
> > 2012-02-01 15:58:41.883212 [ERR] sofia_presence.c:242 Chat proto [sip]
> > from [IMSI404864430002302 <sip:IMSI404864430002302@...
> > <mailto:sip%3AIMSI404864430002302@...]
> > to [smsc@... <mailto:smsc@...>]
> > 00050007911989680045441111880a8179331053020000ff044ab41a0dpor
> > Nobody to send to: Profile internal
> >
> >
> > In Addition to above analysis:
> > ------------------------------------------
> >
> > I can see when smqueue start, it gives following error logs:
> > It fails to bind to port 5063
> >
> > Feb 1 16:02:09 moment-portable smqueue: ALERT 3078641888
> > smqueue.cpp:2347:main: smqueue (re)starting
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > HLR.cpp:294:getCLIDLocal: getCLIDLocal(IMSI001010000000000)
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > HLR.cpp:202:sqlLocal: select callerid from sip_buddies where name =
> > "IMSI001010000000000"
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > HLR.cpp:242:sqlQuery: result = 2100
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > smnet.cpp:319:listen_on_port: Listening at address '0.0.0.0:5063
> > <http://0.0.0.0:5063>'.
> > Feb 1 16:02:09 moment-portable smqueue: ERR 3078641888
> > smnet.cpp:301:listen_on_port: listen_on_port(5063) can't bind to addr
> > ':::5063': Address already in use
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > smqueue.cpp:2390:main: My own IP address is configured as 127.0.0.1
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > smqueue.cpp:2391:main: The HLR registry is at 192.168.2.131
> > Feb 1 16:02:09 moment-portable smqueue: WARNING 3078641888
> > smqueue.cpp:2396:main: Failed to read queue from file /tmp/save
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > smqueue.cpp:2398:main: Queue contains 0 msgs.
> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
> > smqueue.cpp:1996:main_loop: === Feb 1 16:02:09 0 queued; waiting
> >
> >
> >
> > In your last mail, you talked about a script which will take care for
> > converting a SIP MESSAGE from external entity with text/plain to 3gpp
> > equivalent and forwarding to Smqueue. Is the script part of SVN else
> > please tell me how can I get that script.
> >
> > Thanks and Regards,
> > Arghyadip
> >
> >
> > On Tue, Jan 31, 2012 at 4:08 PM, Kurtis Heimerl
> > <kheimerl@... <mailto:kheimerl@...>> wrote:
> >
> >     As I stated before, this is working with FreeSWITCH, as well as
> >     supporting routing for inbound messages.
> >
> >     There's an ongoing effort to implement a new message server
> >     (https://wush.net/trac/rangepublic/wiki/SMQ2) due to the limitations
> >     of smqueue. I don't think we're likely to spend a great deal of
> effort
> >     enabling new features, but I'm happy to receive patches towards that
> >     end.
> >
> >     On Tue, Jan 31, 2012 at 3:55 PM, Arghyadip Paul
> >     <arghyadip@... <mailto:arghyadip@...>> wrote:
> >     > Kurtis/David,
> >     >
> >     > Yeah..I also feel, this will be the opportunity to make
> >     Smqueue/Asterisk
> >     > more robust.
> >     >
> >     > Well, I run some testing with my local set up. I tried to send
> >     one SIP
> >     > MESSAGE destined to one MS registered to OpenBTS from an
> >     external IM client
> >     > which implements RFC 3428 UAC.
> >     >
> >     > As an address of record of the MS I have used the registered SIP
> >     user id of
> >     > the message but getting this abnormal behavior.
> >     >
> >     > i. External RFC 3428 UAC sends MESSAGE to Smqueue destined to MS
> >     in OpenBTS.
> >     > ii. Smqueue responds with 405 Method not allowed.
> >     >
> >     >
> >     > There was no corruption at the SIP Packet level in the MESSAGE
> >     request. So,
> >     > I guess, this is an issue with the Smqueue itself. As of now, I
> >     am thinking
> >     > of only in one direction where SIP MESSAGE can be sent from
> >     external entity
> >     > to an MS in the OpenBTS. Obviously at this point I am not
> >     considering MS to
> >     > outside world SIP MESSAGE, where we may need to incorporate
> >     Asterisk for
> >     > routing.
> >     >
> >     > Do you think we can fix this? Anyhow this is not an expected
> >     behavior of
> >     > Smqueue as Smqueue should be able to route the MESSAGE to the
> >     proper MS
> >     > identified by the SIP AOR in the from header in the SIP MESSAGE
> >     method.
> >     >
> >     > I am also analyzing the code, and can give you update on this,
> >     if I find
> >     > anything problematic.
> >     >
> >     > SIP Logs are below:
> >     > -----------------------------
> >     >
> >     > MESSAGE sip:IMSI404864430002302@...
> >     <mailto:sip%3AIMSI404864430002302@...> SIP/2.0
> >     > Via: SIP/2.0/UDP
> >     >
> >     192.168.2.131:5061
> ;rport;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy
> >     > Max-Forwards: 70
> >     > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
> >     > To: <sip:IMSI404864430002302@...
> >     <mailto:sip%3AIMSI404864430002302@...>>
> >     > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
> >     > CSeq: 51023 MESSAGE
> >     > Content-Type: text/plain
> >     > Content-Length: 2
> >     >
> >     > jk
> >     >
> >     > SIP/2.0 405 Method Not Allowed
> >     > Via: SIP/2.0/UDP
> >     >
> >     192.168.2.131:5061
> ;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy;received=192.168.2.131;rport=5061
> >     > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
> >     > To: <sip:IMSI404864430002302@...
> >     <mailto:sip%3AIMSI404864430002302@...
> >     > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
> >     > CSeq: 51023 MESSAGE
> >     > Server: Asterisk PBX 1.6.2.21
> >     > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
> >     NOTIFY, INFO
> >     > Supported: replaces, timer
> >     > Content-Length: 0
> >     >
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > On Tue, Jan 31, 2012 at 7:53 AM, David Burgess
> >     <david@... <mailto:david@...>>
> >     > wrote:
> >     >>
> >     >> If you two do have that conversation, don't just keep it to
> >     yourselves.
> >     >> The Asterisk/smqueue model is due for an overhaul. They served
> >     us well for
> >     >> early years of the project, but we are starting to hit
> >     limitations on both
> >     >> of them.
> >     >>
> >     >>
> >     >> Range Networks, Inc.
> >     >> 560 Brannan St.
> >     >> San Francisco, CA
> >     >>
> >     >> -----Original Message-----
> >     >> From: Kurtis Heimerl <kheimerl@...
> >     <mailto:kheimerl@...>>
> >     >> Date: Tue, 31 Jan 2012 00:33:48
> >     >> To: Arghyadip Paul<arghyadip@...
> >     <mailto:arghyadip@...>>
> >     >> Cc: <openbts-discuss@...
> >     <mailto:openbts-discuss@...>>
> >     >> Subject: Re: [Openbts-discuss] SMS "text/plain" Failed.
> >     >>
> >     >> It's quite likely that smqueue does (or is supposed to) support
> >     what
> >     >> you are looking for. You'll need to check the source code to be
> >     >> certain, I may find some time to do that myself.
> >     >>
> >     >> At the same time, you'll still have a very difficult time
> >     integrating
> >     >> with any external sip routing engines. How does a user direct an
> >     >> outward facing SMS to a SIP client? It's for these reasons (as
> >     well as
> >     >> many others) I moved to the freeswitch implementation. It's worth
> >     >> noting that freeswitch is NOT a PBX, it's a softswitch. It routes
> >     >> stuff, of which SIP voice traffic is just one item. As such, we
> >     >> eventually got it to route SIP message traffic as well, providing
> a
> >     >> dialplan-like interface for routing our OpenBTS SMS messages. I
> >     think
> >     >> this is significantly more elegant than the current shortcode
> >     system
> >     >> in smqueue. In my architecture, smqueue is used solely for
> >     >> store-and-forwarding, not routing, which is done in the
> softswitch.
> >     >> We're starting to build out tools for doing this routing and
> >     >> interfacing with existing SIP engines.
> >     >>
> >     >> If any of this could support what you folks are doing, or has any
> >     >> overlap, we should talk.
> >     >>
> >     >> On Mon, Jan 30, 2012 at 11:39 PM, Arghyadip Paul
> >     <arghyadip@... <mailto:arghyadip@...>>
> >     >> wrote:
> >     >> > Dear Kurtis,
> >     >> >
> >     >> > Thanks for your mail.
> >     >> >
> >     >> > I actually followed the following patch of text from the
> >     OpenBTS 2.8
> >     >> > manual
> >     >> > about Smqueue.
> >     >> >
> >     >> > "The message arrives at smqueue from the outside world
> >     addressed either
> >     >> > to a
> >     >> > SIP user or to a numeric address. Smqueue resolves the
> >     destination
> >     >> > address
> >     >> > to an IMSI-based SIP user name and forwards the message to
> >     OpenBTS.
> >     >> > OpenBTS
> >     >> > pages the MS, establishes a channel, transfers the message as
> >     SMS and
> >     >> > then
> >     >> > responds to smqueue with 200 OK."
> >     >> >
> >     >> > With this patch of text in the manual and along with the
> >     configuration
> >     >> > values present in the OpenBTS for SMS MIME, I thought
> >     expected behavior
> >     >> > from
> >     >> > Smqueue would be to accept any form of a valid SIP MESSAGE
> >     destined to
> >     >> > one
> >     >> > of the registered MS and if any outside entity is sending a
> >     SIP MESSAGE
> >     >> > destined to SIP address of an MS in OpenBTS , smqueue will be
> >     able to
> >     >> > resolve and forward the SIP MESSAGE.
> >     >> >
> >     >> > I don't use FreeSwitch as a PBX and instead I use Asterisk.
> >     Also, don't
> >     >> > you
> >     >> > think involving the PBX here would be complication in the
> design.
> >     >> > Instead if
> >     >> > we can run the same script whatever you are running in
> >     FreeSwitch in
> >     >> > Smqueue
> >     >> > which will take care for converting the MESSAGE 's content to
> >     3GPP.
> >     >> >
> >     >> > I am not sure if I am right here. But you still insist then ,
> >     I should
> >     >> > start
> >     >> > configuring my set up with FreeSwitch to get the thing working.
> >     >> >
> >     >> > Regards,
> >     >> > Arghyadip
> >     >> >
> >     >> > On Mon, Jan 30, 2012 at 9:08 PM, Kurtis Heimerl
> >     >> > <kheimerl@... <mailto:kheimerl@...>>
> >     >> > wrote:
> >     >> >>
> >     >> >> I think the MIME type is configurable so that you can use an
> >     existing
> >     >> >> SIP MESSAGE server to talk directly to OpenBTS. It has a
> >     number of
> >     >> >> limitations regardless, as text/plain does not support
> >     anything but
> >     >> >> ASCII.
> >     >> >>
> >     >> >> My freeSWITCH scripts begin to address your concern. Basically,
> >     >> >> external services can send SIP MESSAGEs into freeSWITCH,
> >     which then
> >     >> >> encodes them as 3gpp traffic and directs them to smqueue. We
> >     can talk
> >     >> >> about this offline if you have a specific use, I'd be happy
> >     to support
> >     >> >> whatever you are doing or hoping to do.
> >     >> >>
> >     >> >> On Mon, Jan 30, 2012 at 7:11 PM, Arghyadip Paul
> >     <arghyadip@... <mailto:arghyadip@...>>
> >     >> >> wrote:
> >     >> >> > I guess it should.
> >     >> >> >
> >     >> >> > If some external entity wants to send SMS or IM through
> >     the means of
> >     >> >> > SMQUEUE
> >     >> >> > to a UE which is in OpenBTS, current implementation fails.
> >     >> >> > If we imagine of one unified messaging system where we
> >     want to reach
> >     >> >> > someone
> >     >> >> > with a UE in OpenBTS from the internet world through the
> >     means of SIP
> >     >> >> > MESSAGE from a SIP based IM client then the standard
> >     recommendation
> >     >> >> > is
> >     >> >> > to
> >     >> >> > use any of the content type it RFC3428 does not mandate any
> >     >> >> > particular
> >     >> >> > MIME
> >     >> >> > type.
> >     >> >> >
> >     >> >> > Also, if the plain/text is not needed then I am not sure
> >     why there is
> >     >> >> > the
> >     >> >> > need to make the SMS MIME type configurable?
> >     >> >> >
> >     >> >> > Regards,
> >     >> >> > Arghyadip
> >     >> >> >
> >     >> >> >
> >     >> >> > On Mon, Jan 30, 2012 at 6:16 PM, Kurtis Heimerl
> >     >> >> > <kheimerl@... <mailto:kheimerl@...>>
> >     >> >> > wrote:
> >     >> >> >>
> >     >> >> >> This is an open question: Is smqueue supposed to handle
> >     text/plain
> >     >> >> >> messages?
> >     >> >> >>
> >     >> >> >> On Mon, Jan 30, 2012 at 6:03 PM, Arghyadip Paul
> >     >> >> >> <arghyadip@... <mailto:arghyadip@...>>
> >     >> >> >> wrote:
> >     >> >> >> > Hi All,
> >     >> >> >> >
> >     >> >> >> > I am trying to send SMS from one UE to another and I
> >     wanted to
> >     >> >> >> > skip
> >     >> >> >> > the
> >     >> >> >> > end
> >     >> >> >> > to end encryption. To do that , I configured the following
> >     >> >> >> > parameters
> >     >> >> >> > as
> >     >> >> >> > follows in OpenBTS.db
> >     >> >> >> >
> >     >> >> >> > 1. SIP.SMSC = NULL
> >     >> >> >> > 2. SMS.MIMEType = text/plain
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> > I followed the direction from the manual where it is said:
> >     >> >> >> >
> >     >> >> >> > "SIP.SMSC – The SMSC handler in smqueue. This is the
> >     entity that
> >     >> >> >> > handles
> >     >> >> >> > full 3GPP MIME-
> >     >> >> >> > encapsulted TPDUs. If not defined, use direct numeric
> >     addressing.
> >     >> >> >> > Normally
> >     >> >> >> > the value is NULL if
> >     >> >> >> > SMS.MIMIEType is ”text/plain” or ”smsc” if SMS.MIMEType is
> >     >> >> >> > ”application/vnd.3gpp”.
> >     >> >> >> > "
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> > But using these set of configuration I am getting the
> >     following
> >     >> >> >> > bad
> >     >> >> >> > behavior:
> >     >> >> >> >
> >     >> >> >> > 1. UE one sends the SMS.
> >     >> >> >> > 2. OpenBTS forwards the SIP MESSAGE to Smqueue.
> >     >> >> >> > 3. Smqueue respondes with 484 Address Incomplete
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> > From my initial analysis , I think the problem is due
> >     to bad "to"
> >     >> >> >> > header
> >     >> >> >> > in
> >     >> >> >> > the SIP MESSAGE:
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> > MESSAGE sip:@127.0.0.1 <mailto:sip%3A@...> SIP/2.0
> >     >> >> >> > Via: SIP/2.0/UDP
> >     >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
> >     >> >> >> > From: IMSI404864415448667
> >     >> >> >> > <sip:IMSI404864415448667@...
> >     <mailto:sip%3AIMSI404864415448667@...
> >     >> >> >> > To: <sip:@127.0.0.1 <mailto:sip%3A@...>>
> >     >> >> >> > Call-ID: 1488923392@... <mailto:
> 1488923392@...>
> >     >> >> >> > CSeq: 59 MESSAGE
> >     >> >> >> > Content-Type: text/plain
> >     >> >> >> > Max-Forwards: 5
> >     >> >> >> > Content-Length: 3
> >     >> >> >> >
> >     >> >> >> > Che.SIP/2.0 484 Address Incomplete
> >     >> >> >> > Via: SIP/2.0/UDP
> >     >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
> >     >> >> >> > From: IMSI404864415448667
> >     >> >> >> > <sip:IMSI404864415448667@...
> >     <mailto:sip%3AIMSI404864415448667@...
> >     >> >> >> > To: <sip:127.0.0.1>
> >     >> >> >> > Call-ID: 1488923392@... <mailto:
> 1488923392@...>
> >     >> >> >> > CSeq: 59 MESSAGE
> >     >> >> >> > Content-Length: 0
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> > Guess, its a bug.
> >     >> >> >> > --
> >     >> >> >> > Arghyadip Paul
> >     >> >> >> > Graduate Student
> >     >> >> >> > Department of Computer Science
> >     >> >> >> > University of California Santa Barbara
> >     >> >> >> > Santa Barbara , CA 93106 USA
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> >
> >     >> >> >> >
> >
> ------------------------------------------------------------------------------
> >     >> >> >> > Keep Your Developer Skills Current with LearnDevNow!
> >     >> >> >> > The most comprehensive online learning library for
> >     Microsoft
> >     >> >> >> > developers
> >     >> >> >> > is just $99.99! Visual Studio, SharePoint, SQL - plus
> >     HTML5, CSS3,
> >     >> >> >> > MVC3,
> >     >> >> >> > Metro Style Apps, more. Free future releases when you
> >     subscribe
> >     >> >> >> > now!
> >     >> >> >> > http://p.sf.net/sfu/learndevnow-d2d
> >     >> >> >> > _______________________________________________
> >     >> >> >> > Openbts-discuss mailing list
> >     >> >> >> > Openbts-discuss@...
> >     <mailto:Openbts-discuss@...>
> >     >> >> >> >
> >     https://lists.sourceforge.net/lists/listinfo/openbts-discuss
> >     >> >> >> >
> >     >> >> >
> >     >> >> >
> >     >> >> >
> >     >> >> >
> >     >> >> > --
> >     >> >> > Arghyadip Paul
> >     >> >> > Graduate Student
> >     >> >> > Department of Computer Science
> >     >> >> > University of California Santa Barbara
> >     >> >> > Santa Barbara , CA 93106 USA
> >     >> >> >
> >     >> >
> >     >> >
> >     >> >
> >     >> >
> >     >> > --
> >     >> > Arghyadip Paul
> >     >> > Graduate Student
> >     >> > Department of Computer Science
> >     >> > University of California Santa Barbara
> >     >> > Santa Barbara , CA 93106 USA
> >     >> >
> >     >>
> >     >>
> >     >>
> >
> ------------------------------------------------------------------------------
> >     >> Keep Your Developer Skills Current with LearnDevNow!
> >     >> The most comprehensive online learning library for Microsoft
> >     developers
> >     >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
> >     CSS3, MVC3,
> >     >> Metro Style Apps, more. Free future releases when you subscribe
> >     now!
> >     >> http://p.sf.net/sfu/learndevnow-d2d
> >     >> _______________________________________________
> >     >> Openbts-discuss mailing list
> >     >> Openbts-discuss@...
> >     <mailto:Openbts-discuss@...>
> >     >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
> >     >>
> >     >
> >     >
> >     >
> >     > --
> >     > Arghyadip Paul
> >     > Graduate Student
> >     > Department of Computer Science
> >     > University of California Santa Barbara
> >     > Santa Barbara , CA 93106 USA
> >     >
> >
> >
> >
> >
> > --
> > Arghyadip Paul
> > Graduate Student
> > Department of Computer Science
> > University of California Santa Barbara
> > Santa Barbara , CA 93106 USA
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> >
> >
> > _______________________________________________
> > Openbts-discuss mailing list
> > Openbts-discuss@...
> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>



-- 
Arghyadip Paul
Graduate Student
Department of Computer Science
University of California Santa Barbara
Santa Barbara , CA 93106 USA

Freeswitch has a "chatplan" which is very similar to asterisk's
"dialplan" but for SIP MESSAGE traffic. I'm fairly certain that it's
hitting the chatplan but there's nothing caught (e.g, dialing a number
that doesn't exist).

On Wed, Feb 1, 2012 at 5:46 PM, Arghyadip Paul <arghyadip@...> wrote:
> @Thanks Kurtis and Donald for your comment
>
>
> Do you guys have any catch why the SMS is not getting forwarded from
> Freeswitch to Smqueue??
>
> Can you show me some line why this logs are coming
>
> Nobody to send to: Profile internal
>
> Honestly today is my first day with freeswitch and I dont have any idea why
> this is happening.
> On Wed, Feb 1, 2012 at 4:13 PM, Donald Kirker
> <donald.kirker@...> wrote:
>>
>> The bind to port error message that you are seeing means that smqueue
>> cannot bind to the IPv6 port 5063. Don't worry about that (unless you
>> are trying to set up an IPv6 network). As long as you don't see an error
>> about binding to "127.0.0.1:5063", you are fine. :)
>>
>> Best,
>>
>> Donald C. Kirker
>> Range Networks, Inc.
>>
>>
>> On 2/1/12 4:06 PM, Arghyadip Paul wrote:
>> > Hi Kurtis,
>> >
>> > Alright.
>> >
>> > I have configured FreeSwitch to check if can make it working.
>> >
>> >
>> > I am facing the following problem.For the entire installation
>> > procedure I have followed all the instructions carefully from
>> > https://wush.net/trac/rangepublic/wiki/freeswitchConfig
>> >
>> > All my servers, SipAuthServe, smqueue, freeswitch , openbts are
>> > running in the same physical machine with an external IP 192.168.2.131
>> >
>> > 1. MS1 and MS2 registered to OpenBTS.
>> > 2. MS1 sends sms to MS2
>> > 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
>> > 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not
>> > Ok]
>> >
>> > FreeSwitch Logs:
>> > -------------------------
>> >
>> > 2012-02-01 15:58:41.883212 [WARNING] sofia_presence.c:193 Not sending
>> > to local box for smsc@... <mailto:smsc@...>
>> > 2012-02-01 15:58:41.883212 [ERR] sofia_presence.c:242 Chat proto [sip]
>> > from [IMSI404864430002302 <sip:IMSI404864430002302@...
>> > <mailto:sip%3AIMSI404864430002302@...]
>> > to [smsc@... <mailto:smsc@...>]
>> > 00050007911989680045441111880a8179331053020000ff044ab41a0dpor
>> > Nobody to send to: Profile internal
>> >
>> >
>> > In Addition to above analysis:
>> > ------------------------------------------
>> >
>> > I can see when smqueue start, it gives following error logs:
>> > It fails to bind to port 5063
>> >
>> > Feb 1 16:02:09 moment-portable smqueue: ALERT 3078641888
>> > smqueue.cpp:2347:main: smqueue (re)starting
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > HLR.cpp:294:getCLIDLocal: getCLIDLocal(IMSI001010000000000)
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > HLR.cpp:202:sqlLocal: select callerid from sip_buddies where name =
>> > "IMSI001010000000000"
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > HLR.cpp:242:sqlQuery: result = 2100
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > smnet.cpp:319:listen_on_port: Listening at address '0.0.0.0:5063
>> > <http://0.0.0.0:5063>'.
>> > Feb 1 16:02:09 moment-portable smqueue: ERR 3078641888
>> > smnet.cpp:301:listen_on_port: listen_on_port(5063) can't bind to addr
>> > ':::5063': Address already in use
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > smqueue.cpp:2390:main: My own IP address is configured as 127.0.0.1
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > smqueue.cpp:2391:main: The HLR registry is at 192.168.2.131
>> > Feb 1 16:02:09 moment-portable smqueue: WARNING 3078641888
>> > smqueue.cpp:2396:main: Failed to read queue from file /tmp/save
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > smqueue.cpp:2398:main: Queue contains 0 msgs.
>> > Feb 1 16:02:09 moment-portable smqueue: INFO 3078641888
>> > smqueue.cpp:1996:main_loop: === Feb 1 16:02:09 0 queued; waiting
>> >
>> >
>> >
>> > In your last mail, you talked about a script which will take care for
>> > converting a SIP MESSAGE from external entity with text/plain to 3gpp
>> > equivalent and forwarding to Smqueue. Is the script part of SVN else
>> > please tell me how can I get that script.
>> >
>> > Thanks and Regards,
>> > Arghyadip
>> >
>> >
>> > On Tue, Jan 31, 2012 at 4:08 PM, Kurtis Heimerl
>> > <kheimerl@... <mailto:kheimerl@...>> wrote:
>> >
>> >     As I stated before, this is working with FreeSWITCH, as well as
>> >     supporting routing for inbound messages.
>> >
>> >     There's an ongoing effort to implement a new message server
>> >     (https://wush.net/trac/rangepublic/wiki/SMQ2) due to the limitations
>> >     of smqueue. I don't think we're likely to spend a great deal of
>> > effort
>> >     enabling new features, but I'm happy to receive patches towards that
>> >     end.
>> >
>> >     On Tue, Jan 31, 2012 at 3:55 PM, Arghyadip Paul
>> >     <arghyadip@... <mailto:arghyadip@...>> wrote:
>> >     > Kurtis/David,
>> >     >
>> >     > Yeah..I also feel, this will be the opportunity to make
>> >     Smqueue/Asterisk
>> >     > more robust.
>> >     >
>> >     > Well, I run some testing with my local set up. I tried to send
>> >     one SIP
>> >     > MESSAGE destined to one MS registered to OpenBTS from an
>> >     external IM client
>> >     > which implements RFC 3428 UAC.
>> >     >
>> >     > As an address of record of the MS I have used the registered SIP
>> >     user id of
>> >     > the message but getting this abnormal behavior.
>> >     >
>> >     > i. External RFC 3428 UAC sends MESSAGE to Smqueue destined to MS
>> >     in OpenBTS.
>> >     > ii. Smqueue responds with 405 Method not allowed.
>> >     >
>> >     >
>> >     > There was no corruption at the SIP Packet level in the MESSAGE
>> >     request. So,
>> >     > I guess, this is an issue with the Smqueue itself. As of now, I
>> >     am thinking
>> >     > of only in one direction where SIP MESSAGE can be sent from
>> >     external entity
>> >     > to an MS in the OpenBTS. Obviously at this point I am not
>> >     considering MS to
>> >     > outside world SIP MESSAGE, where we may need to incorporate
>> >     Asterisk for
>> >     > routing.
>> >     >
>> >     > Do you think we can fix this? Anyhow this is not an expected
>> >     behavior of
>> >     > Smqueue as Smqueue should be able to route the MESSAGE to the
>> >     proper MS
>> >     > identified by the SIP AOR in the from header in the SIP MESSAGE
>> >     method.
>> >     >
>> >     > I am also analyzing the code, and can give you update on this,
>> >     if I find
>> >     > anything problematic.
>> >     >
>> >     > SIP Logs are below:
>> >     > -----------------------------
>> >     >
>> >     > MESSAGE sip:IMSI404864430002302@...
>> >     <mailto:sip%3AIMSI404864430002302@...> SIP/2.0
>> >     > Via: SIP/2.0/UDP
>> >     >
>> >
>> > 192.168.2.131:5061;rport;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy
>> >     > Max-Forwards: 70
>> >     > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
>> >     > To: <sip:IMSI404864430002302@...
>> >     <mailto:sip%3AIMSI404864430002302@...>>
>> >     > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
>> >     > CSeq: 51023 MESSAGE
>> >     > Content-Type: text/plain
>> >     > Content-Length: 2
>> >     >
>> >     > jk
>> >     >
>> >     > SIP/2.0 405 Method Not Allowed
>> >     > Via: SIP/2.0/UDP
>> >     >
>> >
>> > 192.168.2.131:5061;branch=z9hG4bKPjzvuIESaT9vbNogBUaIVbnEA7W2VLt5oy;received=192.168.2.131;rport=5061
>> >     > From: <sip:192.168.2.131>;tag=gyZry8C2-yXabsL6PqHySsASgTo9WJ6f
>> >     > To: <sip:IMSI404864430002302@...
>> >     <mailto:sip%3AIMSI404864430002302@...
>> >     > Call-ID: EzHdm3fnvCdPuLgedSqhkkPaoZiIPmdt
>> >     > CSeq: 51023 MESSAGE
>> >     > Server: Asterisk PBX 1.6.2.21
>> >     > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
>> >     NOTIFY, INFO
>> >     > Supported: replaces, timer
>> >     > Content-Length: 0
>> >     >
>> >     >
>> >     >
>> >     >
>> >     >
>> >     >
>> >     > On Tue, Jan 31, 2012 at 7:53 AM, David Burgess
>> >     <david@... <mailto:david@...>>
>> >     > wrote:
>> >     >>
>> >     >> If you two do have that conversation, don't just keep it to
>> >     yourselves.
>> >     >> The Asterisk/smqueue model is due for an overhaul. They served
>> >     us well for
>> >     >> early years of the project, but we are starting to hit
>> >     limitations on both
>> >     >> of them.
>> >     >>
>> >     >>
>> >     >> Range Networks, Inc.
>> >     >> 560 Brannan St.
>> >     >> San Francisco, CA
>> >     >>
>> >     >> -----Original Message-----
>> >     >> From: Kurtis Heimerl <kheimerl@...
>> >     <mailto:kheimerl@...>>
>> >     >> Date: Tue, 31 Jan 2012 00:33:48
>> >     >> To: Arghyadip Paul<arghyadip@...
>> >     <mailto:arghyadip@...>>
>> >     >> Cc: <openbts-discuss@...
>> >     <mailto:openbts-discuss@...>>
>> >     >> Subject: Re: [Openbts-discuss] SMS "text/plain" Failed.
>> >     >>
>> >     >> It's quite likely that smqueue does (or is supposed to) support
>> >     what
>> >     >> you are looking for. You'll need to check the source code to be
>> >     >> certain, I may find some time to do that myself.
>> >     >>
>> >     >> At the same time, you'll still have a very difficult time
>> >     integrating
>> >     >> with any external sip routing engines. How does a user direct an
>> >     >> outward facing SMS to a SIP client? It's for these reasons (as
>> >     well as
>> >     >> many others) I moved to the freeswitch implementation. It's worth
>> >     >> noting that freeswitch is NOT a PBX, it's a softswitch. It routes
>> >     >> stuff, of which SIP voice traffic is just one item. As such, we
>> >     >> eventually got it to route SIP message traffic as well, providing
>> > a
>> >     >> dialplan-like interface for routing our OpenBTS SMS messages. I
>> >     think
>> >     >> this is significantly more elegant than the current shortcode
>> >     system
>> >     >> in smqueue. In my architecture, smqueue is used solely for
>> >     >> store-and-forwarding, not routing, which is done in the
>> > softswitch.
>> >     >> We're starting to build out tools for doing this routing and
>> >     >> interfacing with existing SIP engines.
>> >     >>
>> >     >> If any of this could support what you folks are doing, or has any
>> >     >> overlap, we should talk.
>> >     >>
>> >     >> On Mon, Jan 30, 2012 at 11:39 PM, Arghyadip Paul
>> >     <arghyadip@... <mailto:arghyadip@...>>
>> >     >> wrote:
>> >     >> > Dear Kurtis,
>> >     >> >
>> >     >> > Thanks for your mail.
>> >     >> >
>> >     >> > I actually followed the following patch of text from the
>> >     OpenBTS 2.8
>> >     >> > manual
>> >     >> > about Smqueue.
>> >     >> >
>> >     >> > "The message arrives at smqueue from the outside world
>> >     addressed either
>> >     >> > to a
>> >     >> > SIP user or to a numeric address. Smqueue resolves the
>> >     destination
>> >     >> > address
>> >     >> > to an IMSI-based SIP user name and forwards the message to
>> >     OpenBTS.
>> >     >> > OpenBTS
>> >     >> > pages the MS, establishes a channel, transfers the message as
>> >     SMS and
>> >     >> > then
>> >     >> > responds to smqueue with 200 OK."
>> >     >> >
>> >     >> > With this patch of text in the manual and along with the
>> >     configuration
>> >     >> > values present in the OpenBTS for SMS MIME, I thought
>> >     expected behavior
>> >     >> > from
>> >     >> > Smqueue would be to accept any form of a valid SIP MESSAGE
>> >     destined to
>> >     >> > one
>> >     >> > of the registered MS and if any outside entity is sending a
>> >     SIP MESSAGE
>> >     >> > destined to SIP address of an MS in OpenBTS , smqueue will be
>> >     able to
>> >     >> > resolve and forward the SIP MESSAGE.
>> >     >> >
>> >     >> > I don't use FreeSwitch as a PBX and instead I use Asterisk.
>> >     Also, don't
>> >     >> > you
>> >     >> > think involving the PBX here would be complication in the
>> > design.
>> >     >> > Instead if
>> >     >> > we can run the same script whatever you are running in
>> >     FreeSwitch in
>> >     >> > Smqueue
>> >     >> > which will take care for converting the MESSAGE 's content to
>> >     3GPP.
>> >     >> >
>> >     >> > I am not sure if I am right here. But you still insist then ,
>> >     I should
>> >     >> > start
>> >     >> > configuring my set up with FreeSwitch to get the thing working.
>> >     >> >
>> >     >> > Regards,
>> >     >> > Arghyadip
>> >     >> >
>> >     >> > On Mon, Jan 30, 2012 at 9:08 PM, Kurtis Heimerl
>> >     >> > <kheimerl@... <mailto:kheimerl@...>>
>> >     >> > wrote:
>> >     >> >>
>> >     >> >> I think the MIME type is configurable so that you can use an
>> >     existing
>> >     >> >> SIP MESSAGE server to talk directly to OpenBTS. It has a
>> >     number of
>> >     >> >> limitations regardless, as text/plain does not support
>> >     anything but
>> >     >> >> ASCII.
>> >     >> >>
>> >     >> >> My freeSWITCH scripts begin to address your concern.
>> > Basically,
>> >     >> >> external services can send SIP MESSAGEs into freeSWITCH,
>> >     which then
>> >     >> >> encodes them as 3gpp traffic and directs them to smqueue. We
>> >     can talk
>> >     >> >> about this offline if you have a specific use, I'd be happy
>> >     to support
>> >     >> >> whatever you are doing or hoping to do.
>> >     >> >>
>> >     >> >> On Mon, Jan 30, 2012 at 7:11 PM, Arghyadip Paul
>> >     <arghyadip@... <mailto:arghyadip@...>>
>> >     >> >> wrote:
>> >     >> >> > I guess it should.
>> >     >> >> >
>> >     >> >> > If some external entity wants to send SMS or IM through
>> >     the means of
>> >     >> >> > SMQUEUE
>> >     >> >> > to a UE which is in OpenBTS, current implementation fails.
>> >     >> >> > If we imagine of one unified messaging system where we
>> >     want to reach
>> >     >> >> > someone
>> >     >> >> > with a UE in OpenBTS from the internet world through the
>> >     means of SIP
>> >     >> >> > MESSAGE from a SIP based IM client then the standard
>> >     recommendation
>> >     >> >> > is
>> >     >> >> > to
>> >     >> >> > use any of the content type it RFC3428 does not mandate any
>> >     >> >> > particular
>> >     >> >> > MIME
>> >     >> >> > type.
>> >     >> >> >
>> >     >> >> > Also, if the plain/text is not needed then I am not sure
>> >     why there is
>> >     >> >> > the
>> >     >> >> > need to make the SMS MIME type configurable?
>> >     >> >> >
>> >     >> >> > Regards,
>> >     >> >> > Arghyadip
>> >     >> >> >
>> >     >> >> >
>> >     >> >> > On Mon, Jan 30, 2012 at 6:16 PM, Kurtis Heimerl
>> >     >> >> > <kheimerl@... <mailto:kheimerl@...>>
>> >     >> >> > wrote:
>> >     >> >> >>
>> >     >> >> >> This is an open question: Is smqueue supposed to handle
>> >     text/plain
>> >     >> >> >> messages?
>> >     >> >> >>
>> >     >> >> >> On Mon, Jan 30, 2012 at 6:03 PM, Arghyadip Paul
>> >     >> >> >> <arghyadip@... <mailto:arghyadip@...>>
>> >     >> >> >> wrote:
>> >     >> >> >> > Hi All,
>> >     >> >> >> >
>> >     >> >> >> > I am trying to send SMS from one UE to another and I
>> >     wanted to
>> >     >> >> >> > skip
>> >     >> >> >> > the
>> >     >> >> >> > end
>> >     >> >> >> > to end encryption. To do that , I configured the
>> > following
>> >     >> >> >> > parameters
>> >     >> >> >> > as
>> >     >> >> >> > follows in OpenBTS.db
>> >     >> >> >> >
>> >     >> >> >> > 1. SIP.SMSC = NULL
>> >     >> >> >> > 2. SMS.MIMEType = text/plain
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> > I followed the direction from the manual where it is
>> > said:
>> >     >> >> >> >
>> >     >> >> >> > "SIP.SMSC – The SMSC handler in smqueue. This is the
>> >     entity that
>> >     >> >> >> > handles
>> >     >> >> >> > full 3GPP MIME-
>> >     >> >> >> > encapsulted TPDUs. If not defined, use direct numeric
>> >     addressing.
>> >     >> >> >> > Normally
>> >     >> >> >> > the value is NULL if
>> >     >> >> >> > SMS.MIMIEType is ”text/plain” or ”smsc” if SMS.MIMEType
>> > is
>> >     >> >> >> > ”application/vnd.3gpp”.
>> >     >> >> >> > "
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> > But using these set of configuration I am getting the
>> >     following
>> >     >> >> >> > bad
>> >     >> >> >> > behavior:
>> >     >> >> >> >
>> >     >> >> >> > 1. UE one sends the SMS.
>> >     >> >> >> > 2. OpenBTS forwards the SIP MESSAGE to Smqueue.
>> >     >> >> >> > 3. Smqueue respondes with 484 Address Incomplete
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> > From my initial analysis , I think the problem is due
>> >     to bad "to"
>> >     >> >> >> > header
>> >     >> >> >> > in
>> >     >> >> >> > the SIP MESSAGE:
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> > MESSAGE sip:@127.0.0.1 <mailto:sip%3A@...> SIP/2.0
>> >     >> >> >> > Via: SIP/2.0/UDP
>> >     >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
>> >     >> >> >> > From: IMSI404864415448667
>> >     >> >> >> > <sip:IMSI404864415448667@...
>> >     <mailto:sip%3AIMSI404864415448667@...
>> >     >> >> >> > To: <sip:@127.0.0.1 <mailto:sip%3A@...>>
>> >     >> >> >> > Call-ID: 1488923392@...
>> > <mailto:1488923392@...>
>> >     >> >> >> > CSeq: 59 MESSAGE
>> >     >> >> >> > Content-Type: text/plain
>> >     >> >> >> > Max-Forwards: 5
>> >     >> >> >> > Content-Length: 3
>> >     >> >> >> >
>> >     >> >> >> > Che.SIP/2.0 484 Address Incomplete
>> >     >> >> >> > Via: SIP/2.0/UDP
>> >     >> >> >> > 127.0.0.1:5062;branch=z9hG4bKobts289b4c8ea716d10aa
>> >     >> >> >> > From: IMSI404864415448667
>> >     >> >> >> > <sip:IMSI404864415448667@...
>> >     <mailto:sip%3AIMSI404864415448667@...
>> >     >> >> >> > To: <sip:127.0.0.1>
>> >     >> >> >> > Call-ID: 1488923392@...
>> > <mailto:1488923392@...>
>> >     >> >> >> > CSeq: 59 MESSAGE
>> >     >> >> >> > Content-Length: 0
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> > Guess, its a bug.
>> >     >> >> >> > --
>> >     >> >> >> > Arghyadip Paul
>> >     >> >> >> > Graduate Student
>> >     >> >> >> > Department of Computer Science
>> >     >> >> >> > University of California Santa Barbara
>> >     >> >> >> > Santa Barbara , CA 93106 USA
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> >
>> >     >> >> >> >
>> >
>> > ------------------------------------------------------------------------------
>> >     >> >> >> > Keep Your Developer Skills Current with LearnDevNow!
>> >     >> >> >> > The most comprehensive online learning library for
>> >     Microsoft
>> >     >> >> >> > developers
>> >     >> >> >> > is just $99.99! Visual Studio, SharePoint, SQL - plus
>> >     HTML5, CSS3,
>> >     >> >> >> > MVC3,
>> >     >> >> >> > Metro Style Apps, more. Free future releases when you
>> >     subscribe
>> >     >> >> >> > now!
>> >     >> >> >> > http://p.sf.net/sfu/learndevnow-d2d
>> >     >> >> >> > _______________________________________________
>> >     >> >> >> > Openbts-discuss mailing list
>> >     >> >> >> > Openbts-discuss@...
>> >     <mailto:Openbts-discuss@...>
>> >     >> >> >> >
>> >     https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>> >     >> >> >> >
>> >     >> >> >
>> >     >> >> >
>> >     >> >> >
>> >     >> >> >
>> >     >> >> > --
>> >     >> >> > Arghyadip Paul
>> >     >> >> > Graduate Student
>> >     >> >> > Department of Computer Science
>> >     >> >> > University of California Santa Barbara
>> >     >> >> > Santa Barbara , CA 93106 USA
>> >     >> >> >
>> >     >> >
>> >     >> >
>> >     >> >
>> >     >> >
>> >     >> > --
>> >     >> > Arghyadip Paul
>> >     >> > Graduate Student
>> >     >> > Department of Computer Science
>> >     >> > University of California Santa Barbara
>> >     >> > Santa Barbara , CA 93106 USA
>> >     >> >
>> >     >>
>> >     >>
>> >     >>
>> >
>> > ------------------------------------------------------------------------------
>> >     >> Keep Your Developer Skills Current with LearnDevNow!
>> >     >> The most comprehensive online learning library for Microsoft
>> >     developers
>> >     >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
>> >     CSS3, MVC3,
>> >     >> Metro Style Apps, more. Free future releases when you subscribe
>> >     now!
>> >     >> http://p.sf.net/sfu/learndevnow-d2d
>> >     >> _______________________________________________
>> >     >> Openbts-discuss mailing list
>> >     >> Openbts-discuss@...
>> >     <mailto:Openbts-discuss@...>
>> >     >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>> >     >>
>> >     >
>> >     >
>> >     >
>> >     > --
>> >     > Arghyadip Paul
>> >     > Graduate Student
>> >     > Department of Computer Science
>> >     > University of California Santa Barbara
>> >     > Santa Barbara , CA 93106 USA
>> >     >
>> >
>> >
>> >
>> >
>> > --
>> > Arghyadip Paul
>> > Graduate Student
>> > Department of Computer Science
>> > University of California Santa Barbara
>> > Santa Barbara , CA 93106 USA
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Keep Your Developer Skills Current with LearnDevNow!
>> > The most comprehensive online learning library for Microsoft developers
>> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> > Metro Style Apps, more. Free future releases when you subscribe now!
>> > http://p.sf.net/sfu/learndevnow-d2d
>> >
>> >
>> > _______________________________________________
>> > Openbts-discuss mailing list
>> > Openbts-discuss@...
>> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Openbts-discuss mailing list
>> Openbts-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>
>
>
>
> --
> Arghyadip Paul
> Graduate Student
> Department of Computer Science
> University of California Santa Barbara
> Santa Barbara , CA 93106 USA
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>

Note that step #3 is a violation of the SPI spec.  A 200 OK response to SIP MESSAGE means that the message was delivered to the endpoint.  A 202 Queued response to SIP MESSAGE means that the message is stored for reliable delivery.  Only OpenBTS itself is in a position to give a 200 OK response and FS has no storage function and therefore has no business answering with 202 Queued.  The result here is worse than a simple failure, since there is not feedback to the handset that something is wrong.

I'm not anti-FS.  I like the idea of using the same component for SMS and telephone number resolution.  But this looks like a problem that needs worked around somehow.

On Feb 1, 2012, at 4:06 PM, Arghyadip Paul wrote:

> 
> 1. MS1 and MS2 registered to OpenBTS.
> 2. MS1 sends sms to MS2
> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]

David A. Burgess
Range Networks, Inc.
560 Brannan St.
San Francisco, CA 94107
USA
cell +1 707 208 2622

If you can give the specific spec being violated, I'll submit a bug
fix to Anthony on FS. The SIP MESSAGE stuff is not as mature (having
come around 6 months ago) and so you're going to find issues like
this.

At the same time, I think it's reasonable to say that FS is
potentially the "endpoint" in this instance. For short-codes, for
instance, it's the right response.

On Wed, Feb 1, 2012 at 6:03 PM, David Burgess <david@...> wrote:
>
> Note that step #3 is a violation of the SPI spec.  A 200 OK response to SIP
> MESSAGE means that the message was delivered to the endpoint.  A 202 Queued
> response to SIP MESSAGE means that the message is stored for reliable
> delivery.  Only OpenBTS itself is in a position to give a 200 OK response
> and FS has no storage function and therefore has no business answering with
> 202 Queued.  The result here is worse than a simple failure, since there is
> not feedback to the handset that something is wrong.
>
> I'm not anti-FS.  I like the idea of using the same component for SMS and
> telephone number resolution.  But this looks like a problem that needs
> worked around somehow.
>
> On Feb 1, 2012, at 4:06 PM, Arghyadip Paul wrote:
>
>
> 1. MS1 and MS2 registered to OpenBTS.
> 2. MS1 sends sms to MS2
> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]
>
>
> David A. Burgess
> Range Networks, Inc.
> 560 Brannan St.
> San Francisco, CA 94107
> USA
> cell +1 707 208 2622
>
>
>

Kurtis -

It's in RFC-3428 Section 4.  It includes this paragraph:

"""
   If the UAC receives a 200 OK response to a MESSAGE request, it may
   assume the message has been delivered to the final destination.  It
   MUST NOT assume that the recipient has actually read the instant
   message.  If the UAC receives a 202 Accepted response, the message
   has been delivered to a gateway, store and forward server, or some
   other service that may eventually deliver the message.  In this case,
   the UAC MUST NOT assume the message has been delivered to the final
   destination.  If confirmation of delivery is required for a message
   that has been responded to with a 202 Accepted, that confirmation
   must be delivered via some other mechanism, which is beyond the scope
   of this specification.
"""

It sounds like the only way to get truly reliable delivery at the user level is to implement SMS delivery reports in the transfer layer (layer 5).

-- David




On Feb 1, 2012, at 6:30 PM, Kurtis Heimerl wrote:

> If you can give the specific spec being violated, I'll submit a bug
> fix to Anthony on FS. The SIP MESSAGE stuff is not as mature (having
> come around 6 months ago) and so you're going to find issues like
> this.
> 
> At the same time, I think it's reasonable to say that FS is
> potentially the "endpoint" in this instance. For short-codes, for
> instance, it's the right response.
> 
> On Wed, Feb 1, 2012 at 6:03 PM, David Burgess <david@...> wrote:
>> 
>> Note that step #3 is a violation of the SPI spec.  A 200 OK response to SIP
>> MESSAGE means that the message was delivered to the endpoint.  A 202 Queued
>> response to SIP MESSAGE means that the message is stored for reliable
>> delivery.  Only OpenBTS itself is in a position to give a 200 OK response
>> and FS has no storage function and therefore has no business answering with
>> 202 Queued.  The result here is worse than a simple failure, since there is
>> not feedback to the handset that something is wrong.
>> 
>> I'm not anti-FS.  I like the idea of using the same component for SMS and
>> telephone number resolution.  But this looks like a problem that needs
>> worked around somehow.
>> 
>> On Feb 1, 2012, at 4:06 PM, Arghyadip Paul wrote:
>> 
>> 
>> 1. MS1 and MS2 registered to OpenBTS.
>> 2. MS1 sends sms to MS2
>> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
>> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]
>> 
>> 
>> David A. Burgess
>> Range Networks, Inc.
>> 560 Brannan St.
>> San Francisco, CA 94107
>> USA
>> cell +1 707 208 2622
>> 
>> 
>> 
> 

David A. Burgess
Range Networks, Inc.
560 Brannan St.
San Francisco, CA 94107
USA
cell +1 707 208 2622

Sounds like having FS respond with a 202 is sufficient to meet the
spec. That should be easy to do.

On Wed, Feb 1, 2012 at 6:41 PM, David Burgess <david@...> wrote:
> Kurtis -
>
> It's in RFC-3428 Section 4.  It includes this paragraph:
>
> """
>   If the UAC receives a 200 OK response to a MESSAGE request, it may
>   assume the message has been delivered to the final destination.  It
>   MUST NOT assume that the recipient has actually read the instant
>   message.  If the UAC receives a 202 Accepted response, the message
>   has been delivered to a gateway, store and forward server, or some
>   other service that may eventually deliver the message.  In this case,
>   the UAC MUST NOT assume the message has been delivered to the final
>   destination.  If confirmation of delivery is required for a message
>   that has been responded to with a 202 Accepted, that confirmation
>   must be delivered via some other mechanism, which is beyond the scope
>   of this specification.
> """
>
> It sounds like the only way to get truly reliable delivery at the user level is to implement SMS delivery reports in the transfer layer (layer 5).
>
> -- David
>
>
>
>
> On Feb 1, 2012, at 6:30 PM, Kurtis Heimerl wrote:
>
>> If you can give the specific spec being violated, I'll submit a bug
>> fix to Anthony on FS. The SIP MESSAGE stuff is not as mature (having
>> come around 6 months ago) and so you're going to find issues like
>> this.
>>
>> At the same time, I think it's reasonable to say that FS is
>> potentially the "endpoint" in this instance. For short-codes, for
>> instance, it's the right response.
>>
>> On Wed, Feb 1, 2012 at 6:03 PM, David Burgess <david@...> wrote:
>>>
>>> Note that step #3 is a violation of the SPI spec.  A 200 OK response to SIP
>>> MESSAGE means that the message was delivered to the endpoint.  A 202 Queued
>>> response to SIP MESSAGE means that the message is stored for reliable
>>> delivery.  Only OpenBTS itself is in a position to give a 200 OK response
>>> and FS has no storage function and therefore has no business answering with
>>> 202 Queued.  The result here is worse than a simple failure, since there is
>>> not feedback to the handset that something is wrong.
>>>
>>> I'm not anti-FS.  I like the idea of using the same component for SMS and
>>> telephone number resolution.  But this looks like a problem that needs
>>> worked around somehow.
>>>
>>> On Feb 1, 2012, at 4:06 PM, Arghyadip Paul wrote:
>>>
>>>
>>> 1. MS1 and MS2 registered to OpenBTS.
>>> 2. MS1 sends sms to MS2
>>> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
>>> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]
>>>
>>>
>>> David A. Burgess
>>> Range Networks, Inc.
>>> 560 Brannan St.
>>> San Francisco, CA 94107
>>> USA
>>> cell +1 707 208 2622
>>>
>>>
>>>
>>
>
> David A. Burgess
> Range Networks, Inc.
> 560 Brannan St.
> San Francisco, CA 94107
> USA
> cell +1 707 208 2622
>
>
>

Though I'd really like the dialplan to give me the option of
responding with what I see fit (as perhaps I am the end point or can
confirm the delivery to the endpoint). I'll poke those folks and see
what happens.

On Wed, Feb 1, 2012 at 6:48 PM, Kurtis Heimerl <kheimerl@...> wrote:
> Sounds like having FS respond with a 202 is sufficient to meet the
> spec. That should be easy to do.
>
> On Wed, Feb 1, 2012 at 6:41 PM, David Burgess <david@...> wrote:
>> Kurtis -
>>
>> It's in RFC-3428 Section 4.  It includes this paragraph:
>>
>> """
>>   If the UAC receives a 200 OK response to a MESSAGE request, it may
>>   assume the message has been delivered to the final destination.  It
>>   MUST NOT assume that the recipient has actually read the instant
>>   message.  If the UAC receives a 202 Accepted response, the message
>>   has been delivered to a gateway, store and forward server, or some
>>   other service that may eventually deliver the message.  In this case,
>>   the UAC MUST NOT assume the message has been delivered to the final
>>   destination.  If confirmation of delivery is required for a message
>>   that has been responded to with a 202 Accepted, that confirmation
>>   must be delivered via some other mechanism, which is beyond the scope
>>   of this specification.
>> """
>>
>> It sounds like the only way to get truly reliable delivery at the user level is to implement SMS delivery reports in the transfer layer (layer 5).
>>
>> -- David
>>
>>
>>
>>
>> On Feb 1, 2012, at 6:30 PM, Kurtis Heimerl wrote:
>>
>>> If you can give the specific spec being violated, I'll submit a bug
>>> fix to Anthony on FS. The SIP MESSAGE stuff is not as mature (having
>>> come around 6 months ago) and so you're going to find issues like
>>> this.
>>>
>>> At the same time, I think it's reasonable to say that FS is
>>> potentially the "endpoint" in this instance. For short-codes, for
>>> instance, it's the right response.
>>>
>>> On Wed, Feb 1, 2012 at 6:03 PM, David Burgess <david@...> wrote:
>>>>
>>>> Note that step #3 is a violation of the SPI spec.  A 200 OK response to SIP
>>>> MESSAGE means that the message was delivered to the endpoint.  A 202 Queued
>>>> response to SIP MESSAGE means that the message is stored for reliable
>>>> delivery.  Only OpenBTS itself is in a position to give a 200 OK response
>>>> and FS has no storage function and therefore has no business answering with
>>>> 202 Queued.  The result here is worse than a simple failure, since there is
>>>> not feedback to the handset that something is wrong.
>>>>
>>>> I'm not anti-FS.  I like the idea of using the same component for SMS and
>>>> telephone number resolution.  But this looks like a problem that needs
>>>> worked around somehow.
>>>>
>>>> On Feb 1, 2012, at 4:06 PM, Arghyadip Paul wrote:
>>>>
>>>>
>>>> 1. MS1 and MS2 registered to OpenBTS.
>>>> 2. MS1 sends sms to MS2
>>>> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok response.
>>>> 4. Freeswith is supposed to forward the SMS to smqueue but Failed.[Not Ok]
>>>>
>>>>
>>>> David A. Burgess
>>>> Range Networks, Inc.
>>>> 560 Brannan St.
>>>> San Francisco, CA 94107
>>>> USA
>>>> cell +1 707 208 2622
>>>>
>>>>
>>>>
>>>
>>
>> David A. Burgess
>> Range Networks, Inc.
>> 560 Brannan St.
>> San Francisco, CA 94107
>> USA
>> cell +1 707 208 2622
>>
>>
>>

I have some question regarding the configuration of Freeswitch and OpenBTS:

In the https://wush.net/trac/rangepublic/wiki/freeswitchConfig

In last section "Using FreeSWITCH with OpenBTS" a couple of tools and
examples given:

To configure OpenBTS to work with Freeswitch are those tools and examples
mandatory to be applied or run. From this page its not clear what needs to
be done after this patch of text:

*"Lastly, there are a few utility scripts we've written that should be made
accessible to FreeSWITCH. These are located in
(openbtsdir)/FreeswitchConfig/scripts/. Copy all of those to
(freeswitchInstallDir)/scripts. Their functions are detailed below. *

* Restart FreeSWITCH and your system should be receiving and handing
OpenBTS traffic."*


In my set up I have not run any of the tools nor I have updates the
chatplans according to the example.

Waiting for your responses. May be I am missing only these final steps to
be applied and these are not done , currently set up is not working.


On Wed, Feb 1, 2012 at 6:49 PM, Kurtis Heimerl <kheimerl@...:

> Though I'd really like the dialplan to give me the option of
> responding with what I see fit (as perhaps I am the end point or can
> confirm the delivery to the endpoint). I'll poke those folks and see
> what happens.
>
> On Wed, Feb 1, 2012 at 6:48 PM, Kurtis Heimerl <kheimerl@...>
> wrote:
> > Sounds like having FS respond with a 202 is sufficient to meet the
> > spec. That should be easy to do.
> >
> > On Wed, Feb 1, 2012 at 6:41 PM, David Burgess <david@...>
> wrote:
> >> Kurtis -
> >>
> >> It's in RFC-3428 Section 4.  It includes this paragraph:
> >>
> >> """
> >>   If the UAC receives a 200 OK response to a MESSAGE request, it may
> >>   assume the message has been delivered to the final destination.  It
> >>   MUST NOT assume that the recipient has actually read the instant
> >>   message.  If the UAC receives a 202 Accepted response, the message
> >>   has been delivered to a gateway, store and forward server, or some
> >>   other service that may eventually deliver the message.  In this case,
> >>   the UAC MUST NOT assume the message has been delivered to the final
> >>   destination.  If confirmation of delivery is required for a message
> >>   that has been responded to with a 202 Accepted, that confirmation
> >>   must be delivered via some other mechanism, which is beyond the scope
> >>   of this specification.
> >> """
> >>
> >> It sounds like the only way to get truly reliable delivery at the user
> level is to implement SMS delivery reports in the transfer layer (layer 5).
> >>
> >> -- David
> >>
> >>
> >>
> >>
> >> On Feb 1, 2012, at 6:30 PM, Kurtis Heimerl wrote:
> >>
> >>> If you can give the specific spec being violated, I'll submit a bug
> >>> fix to Anthony on FS. The SIP MESSAGE stuff is not as mature (having
> >>> come around 6 months ago) and so you're going to find issues like
> >>> this.
> >>>
> >>> At the same time, I think it's reasonable to say that FS is
> >>> potentially the "endpoint" in this instance. For short-codes, for
> >>> instance, it's the right response.
> >>>
> >>> On Wed, Feb 1, 2012 at 6:03 PM, David Burgess <david@...>
> wrote:
> >>>>
> >>>> Note that step #3 is a violation of the SPI spec.  A 200 OK response
> to SIP
> >>>> MESSAGE means that the message was delivered to the endpoint.  A 202
> Queued
> >>>> response to SIP MESSAGE means that the message is stored for reliable
> >>>> delivery.  Only OpenBTS itself is in a position to give a 200 OK
> response
> >>>> and FS has no storage function and therefore has no business
> answering with
> >>>> 202 Queued.  The result here is worse than a simple failure, since
> there is
> >>>> not feedback to the handset that something is wrong.
> >>>>
> >>>> I'm not anti-FS.  I like the idea of using the same component for SMS
> and
> >>>> telephone number resolution.  But this looks like a problem that needs
> >>>> worked around somehow.
> >>>>
> >>>> On Feb 1, 2012, at 4:06 PM, Arghyadip Paul wrote:
> >>>>
> >>>>
> >>>> 1. MS1 and MS2 registered to OpenBTS.
> >>>> 2. MS1 sends sms to MS2
> >>>> 3. OpenBTS sends the SIP MESSAGE to Freeswitch and gets 200Ok
> response.
> >>>> 4. Freeswith is supposed to forward the SMS to smqueue but
> Failed.[Not Ok]
> >>>>
> >>>>
> >>>> David A. Burgess
> >>>> Range Networks, Inc.
> >>>> 560 Brannan St.
> >>>> San Francisco, CA 94107
> >>>> USA
> >>>> cell +1 707 208 2622
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> David A. Burgess
> >> Range Networks, Inc.
> >> 560 Brannan St.
> >> San Francisco, CA 94107
> >> USA
> >> cell +1 707 208 2622
> >>
> >>
> >>
>



-- 
Arghyadip Paul
Graduate Student
Department of Computer Science
University of California Santa Barbara
Santa Barbara , CA 93106 USA

I'd simplify the problem by using the CLI "originate" command instead
of calling from SW-phone.

What does the SIP traffic look like?

On Thu, Feb 2, 2012 at 8:08 AM, Dmytro Osmachka <Tima_20@...> wrote:
> Hello
>
> I do not understand why is my MS <-> SW-Phone connection unidirectional. I can call the SW-Phone (twinkle) from my MS (in this case is all right), but if I try to reach the MS from SW-Phone, then asterisk says: "Unable to create channel of type 'SIP' (cause 20 - Unknown)" ... what could it be?
>
> In my sip.conf there are follow lines:
> [IMSI001011832121286]
> callerid=10001000
> type=friend
> context=sip-local
> host=dynamic
>
> and in asterisk DB for openBTS this MS is defined in the same way:
> name     --> IMSI001011832121286
> context  --> sip-local
> host     --> dynamic
> nat      --> no
> type     --> friend
> callerid --> 10001000
> defailtip--> 0.0.0.0
> dtmfmode --> rfc2833
> ipaddr   --> 127.0.0.1
> port     --> 5062
> username --> IMSI001011832121286
> and other standard values
>
> the SW-Phone is defined as:
> [xlite1]
> callerid=2101
> context=sip-local
> type=friend
> host=dynamic
>
> in extensions.conf you can find
> exten => 2101,1,Dial(SIP/xlite1) --> for twinkle
> exten => 10001000,1,Dial(SIP/IMSI001011832121286) --> for MS
>
> both succeed by echo-test, but it is only possible to call SW-Phone from mobile (dial 2101), not in another direction, from twinkle to MS (dial 10001000)
>
> Do someone recognize a problem here?
>
> thanks
>
> ps: My last problem with Asterisk<->OpenBTS connection has been solved after clocktamer recalibration - thats why it was possible to send SMS, but impossible to make a telephone call
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss

02.02.2012 19:09, Alexander Chemeris пишет:

> Regarding contents of those digest. In OpenMoko digest I always
> appreciated an overview of important discussions and decision made on
> the mailing list. I think we should follow this rule as well. Will you
> be able to do write just a few sentences of the most important stuff?

I'll try to make better summary on encryption+authentication after the weekend.
However there's been many interesting discussions so I'd need help - what do you guys
consider as a 'hot topics' over last couple of months?

> Max -- a procedural question to you. If one wants to include some news
> into this digest, should he send send info to you (off the list) or
> just add info to the wiki? This should be clearly documented
> somewhere.

I think it's easier just to go straight to wiki - I don't want to become bottleneck
in case my Internet connection dies for example :)

cheers,
Max.

I also support this in endeavor, I think it'd a great idea. I'll make
sure to contribute my (and TIER's) work.

On Thu, Feb 2, 2012 at 3:39 AM,  <Max.Suraev@...> wrote:
> 02.02.2012 19:09, Alexander Chemeris пишет:
>
>> Regarding contents of those digest. In OpenMoko digest I always
>> appreciated an overview of important discussions and decision made on
>> the mailing list. I think we should follow this rule as well. Will you
>> be able to do write just a few sentences of the most important stuff?
>
> I'll try to make better summary on encryption+authentication after the weekend.
> However there's been many interesting discussions so I'd need help - what do you guys
> consider as a 'hot topics' over last couple of months?
>
>> Max -- a procedural question to you. If one wants to include some news
>> into this digest, should he send send info to you (off the list) or
>> just add info to the wiki? This should be clearly documented
>> somewhere.
>
> I think it's easier just to go straight to wiki - I don't want to become bottleneck
> in case my Internet connection dies for example :)
>
> cheers,
> Max.
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss

On Thu, Feb 2, 2012 at 15:39,  <Max.Suraev@...> wrote:
> 02.02.2012 19:09, Alexander Chemeris пишет:
>
>> Regarding contents of those digest. In OpenMoko digest I always
>> appreciated an overview of important discussions and decision made on
>> the mailing list. I think we should follow this rule as well. Will you
>> be able to do write just a few sentences of the most important stuff?
>
> I'll try to make better summary on encryption+authentication after the weekend.
> However there's been many interesting discussions so I'd need help - what do you guys
> consider as a 'hot topics' over last couple of months?

I'll look through mail history since NY and try to put something
together by the weekend. We'll be able to add as we go during the next
two weeks. I definitely will miss something, so please do not hesitate
to add your personal hits.


-- 
Regards,
Alexander Chemeris.

Hi,

> I think it's better to use boolen flags o indicate that encryption should be
> enabled/disabled for a given channel.

IMHO You'd  both the Kc _and_ the current algorith (0=no cipher,
1=A5/1 2=A5/2 3=A5/3 ...)

Ok, A5/2 should not be used but A5/3 should when possible (phone
support) and in an open source project I think it's important to show
the right way to do it.

> Just to summarize:
> - TCH+FACCH and SACCH could enable encryption (if appear layers set appropriate flags)
> - BCCH and CCCH have encryption always disabled.
>
> What about SDCCH, NDCCH, FCCH and SCH?

SDCCH yes
NDCCH ... are we talking about GSM ? I have _no_ idea what NDCCH is ...
FCCH & SCH ... that doesn't even make sense ...


> This means that if MS missed the ciphering command than it'll be effectively
> shut-off. After some timeout it'll probably try to recamp to BTS and will trigger
> authentication procedure again. Is that how it supposed to work?

No. If the MS missed the ciphering command, the BTS will never see the
LAPDm ACK for that message (since it started deciphering as soon as it
processed the cipher mode command) and will retransmit the ciphering
command (in clear because it hasn't seen any ciphered frame from the
mobile yet).

This is exactly why the BTS starts ciphering / deciphering at
different point in time.

Cheers,

    Sylvain

Carrier phase is detected on a burst-by-burst basis in the midamble correlation step and corrected by the equalizer.


On Feb 1, 2012, at 6:15 PM, Page Jack wrote:

> Hi list,
> I am studying openbts I can not find any code deal with the carrier phase recovery. From my knowledge the carrier phase error 
> will bring phase rotate to the sampled symbol. 
> 
> Regards!
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss

David A. Burgess
Range Networks, Inc.
560 Brannan St.
San Francisco, CA 94107
USA
cell +1 707 208 2622

Hi David,
do you mean timing error include the phase error information then using
delayvector to correct the burst both on
timing error and phase error?

Regards!

On Thu, Feb 2, 2012 at 10:35 AM, David Burgess <david@...:

>
> Carrier phase is detected on a burst-by-burst basis in the midamble
> correlation step and corrected by the equalizer.
>
>
> On Feb 1, 2012, at 6:15 PM, Page Jack wrote:
>
> Hi list,
> I am studying openbts I can not find any code deal with the carrier phase
> recovery. From my knowledge the carrier phase error
> will bring phase rotate to the sampled symbol.
>
> Regards!
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
>
> http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss@...
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>
>
> David A. Burgess
> Range Networks, Inc.
> 560 Brannan St.
> San Francisco, CA 94107
> USA
> cell +1 707 208 2622
>
>
>
>

On Wed, Feb 1, 2012 at 10:41 PM, Page Jack <jack.page999@...> wrote:
> Hi David,
> do you mean timing error include the phase error information then using
> delayvector to correct the burst both on
> timing error and phase error?

Basically, yes. The burst sequence goes through a fractional delay
which will adjust the sample point and phase.

  Thomas