From triv.krishna at gmail.com Sat Mar 3 08:40:59 2012 From: triv.krishna at gmail.com (thriveni) Date: Sat, 3 Mar 2012 14:10:59 +0530 Subject: GSM video lectures (en) Message-ID: <4f51d924.2811440a.7c73.fffff8eb@mx.google.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Thu Mar 1 07:01:47 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Thu, 01 Mar 2012 08:01:47 +0100 Subject: [PATCH] fix build without mISDN In-Reply-To: <20120229184012.GA3768@de.xx.vu> References: <1330523662-29713-2-git-send-email-alexander.huemer@xx.vu> <20120229160343.GL10919@massoud> <20120229162608.GB29813@de.xx.vu> <20120229172803.29287.qmail@stuge.se> <20120229184012.GA3768@de.xx.vu> Message-ID: <4F4F1EDB.7010404@eversberg.eu> >>>> channel.c -o bchannel.po >>>> bchannel.c:26:27: error: mISDN/mISDNif.h: No such file or directory >>>> bchannel.c:28:31: error: mISDN/mISDNcompat.h: No such file or directory >>>> bchannel.c:29: error: 'MISDN_AF_ISDN' undeclared here (not in a function) >>>> bchannel.c:30:24: error: mISDN/q931.h: No such file or directory >>>> hi, currently the chan_lcr only works with mISDN. the chan_lcr directly opens the bchannels in order to exchange audio with asterisk. this only works if the call is connected to isdn phone or isdn line, since only these interfaces support mISDN. gsm and sip interface cannot be used with chan_lcr (anymore). i plan to forward audio between lcr and chan_lcr using the unix-socket and remove the export/import code from lcr. currently you can only link gsm insterfaces to asterisk using sip. with jolly/rtpmux branch of openbsc, you can even forward rtp traffic directly between openbsc and the remote sip endpoint (asterisk or other sip gateway), without routing traffic through lcr. if you have any suggestions about further development, let me know. regards, andreas p.s. i committed the appbridge.cpp fix of alexander. thanx! From nikpakar at gmail.com Thu Mar 1 11:05:45 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 1 Mar 2012 11:05:45 +0000 Subject: [PATCH] fix build without mISDN In-Reply-To: <4F4F1EDB.7010404@eversberg.eu> References: <1330523662-29713-2-git-send-email-alexander.huemer@xx.vu> <20120229160343.GL10919@massoud> <20120229162608.GB29813@de.xx.vu> <20120229172803.29287.qmail@stuge.se> <20120229184012.GA3768@de.xx.vu> <4F4F1EDB.7010404@eversberg.eu> Message-ID: Hi Andreas, Wouldnt it be better if we can integrate OpenSBC to some thing like yate which already have extensive ss7, sigtran, camel and map parts implemented. It will be a perfect marriage if we can do it as both openbsc and yate have its own strength which can make a full fledge mobile switching environment. How difficult would it be either, 1. Use OpenBSC Nitb as its on LCR and implement a gsm channel driver for yate. or 2. Use extensive SCCP, MAP implementation already on yate and implement full A interface integration towards yate. Lets throw some ideas on this way, as im sure this will be a major implementation if we can do it. Rgds Nik On Thu, Mar 1, 2012 at 7:01 AM, Andreas Eversberg wrote: > > >>>> channel.c -o bchannel.po > >>>> bchannel.c:26:27: error: mISDN/mISDNif.h: No such file or directory > >>>> bchannel.c:28:31: error: mISDN/mISDNcompat.h: No such file or > directory > >>>> bchannel.c:29: error: 'MISDN_AF_ISDN' undeclared here (not in a > function) > >>>> bchannel.c:30:24: error: mISDN/q931.h: No such file or directory > >>>> > > hi, > > currently the chan_lcr only works with mISDN. the chan_lcr directly > opens the bchannels in order to exchange audio with asterisk. this only > works if the call is connected to isdn phone or isdn line, since only > these interfaces support mISDN. gsm and sip interface cannot be used > with chan_lcr (anymore). > > i plan to forward audio between lcr and chan_lcr using the unix-socket > and remove the export/import code from lcr. > > currently you can only link gsm insterfaces to asterisk using sip. with > jolly/rtpmux branch of openbsc, you can even forward rtp traffic > directly between openbsc and the remote sip endpoint (asterisk or other > sip gateway), without routing traffic through lcr. > > if you have any suggestions about further development, let me know. > > regards, > > andreas > > p.s. i committed the appbridge.cpp fix of alexander. thanx! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Mar 1 12:40:26 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 1 Mar 2012 13:40:26 +0100 Subject: [PATCH] fix build without mISDN In-Reply-To: References: <1330523662-29713-2-git-send-email-alexander.huemer@xx.vu> <20120229160343.GL10919@massoud> <20120229162608.GB29813@de.xx.vu> <20120229172803.29287.qmail@stuge.se> <20120229184012.GA3768@de.xx.vu> <4F4F1EDB.7010404@eversberg.eu> Message-ID: <20120301124026.GC21122@prithivi.gnumonks.org> Hi Nik, On Thu, Mar 01, 2012 at 11:05:45AM +0000, Nik Pakar wrote: > 1. Use OpenBSC Nitb as its on LCR and implement a gsm channel driver for > yate. Well, you are asking the lcr author to implement something for yate. I think it may be a bit of a strange question ;) > 2. Use extensive SCCP, MAP implementation already on yate and implement > full A interface integration towards yate. I would be honestly surprised if yate implemented connection-oriented SCCP procedures. This is only used on the GSM A interface and not to be mistaken with the datagram-oriented SCCP (UDT only) used by TCAP/MAP. In fact, it might make more sense to use the existing libosmo-sccp and either 1) add SCCP-lite (IPA multiplex) support to yate or 2) implement M3UA as a transport for osmo-bsc's existing libosmo-sccp and use that to connect to yate. But then, I am not aware of any commercial OpenBSC user who has any interest in OpenBSC with classic A interface. Everybody wants to move away from TDM and to an all-IP RAN. Furthermore, at least as far as I know, yate may not support AMR/EFR codecs, which makes it somewhat limited in the context of GSM. I may be wrong here, though. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nikpakar at gmail.com Thu Mar 1 17:53:47 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 1 Mar 2012 17:53:47 +0000 Subject: [PATCH] fix build without mISDN In-Reply-To: <20120301124026.GC21122@prithivi.gnumonks.org> References: <1330523662-29713-2-git-send-email-alexander.huemer@xx.vu> <20120229160343.GL10919@massoud> <20120229162608.GB29813@de.xx.vu> <20120229172803.29287.qmail@stuge.se> <20120229184012.GA3768@de.xx.vu> <4F4F1EDB.7010404@eversberg.eu> <20120301124026.GC21122@prithivi.gnumonks.org> Message-ID: Hello Harald, Thanks for the reply and sorry if i was blunt to ask the question as im new to openbsc. I was just trying to find a good sip interoperability for opensbc while keeping ss7 in handy. How would you think best way to integrate it with yate as we already have some services with yate and would like to integrate opensbc with that. All we need is basically, 1. Have multiple opensbc (probably NITB but with unbundled HLR features) connecting many nano.BTSs 2. Connect them back to yate in some way 3. let the call handling to take care of yate i.e. any MO call to routed to yate and yate will consult the HLR database and decide which BSC it should send it back to. WHat would be the best way to achieve this ? BTW, yate does support both AMR and GSM codes. Thanks again Harald for your valuable result and openbsc is a great software im just new to it, but i find it extremely useful and just trying to make it use in a commercial environment. Thanks again Nik. On Thu, Mar 1, 2012 at 12:40 PM, Harald Welte wrote: > Hi Nik, > > On Thu, Mar 01, 2012 at 11:05:45AM +0000, Nik Pakar wrote: > > > 1. Use OpenBSC Nitb as its on LCR and implement a gsm channel driver for > > yate. > > Well, you are asking the lcr author to implement something for yate. I > think it may be a bit of a strange question ;) > > > 2. Use extensive SCCP, MAP implementation already on yate and implement > > full A interface integration towards yate. > > I would be honestly surprised if yate implemented connection-oriented > SCCP procedures. This is only used on the GSM A interface and not to be > mistaken with the datagram-oriented SCCP (UDT only) used by TCAP/MAP. > > In fact, it might make more sense to use the existing libosmo-sccp and > either > 1) add SCCP-lite (IPA multiplex) support to yate > or > 2) implement M3UA as a transport for osmo-bsc's existing libosmo-sccp > and use that to connect to yate. > > But then, I am not aware of any commercial OpenBSC user who has any > interest in OpenBSC with classic A interface. Everybody wants to move > away from TDM and to an all-IP RAN. > > Furthermore, at least as far as I know, yate may not support AMR/EFR > codecs, which makes it somewhat limited in the context of GSM. I may be > wrong here, though. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Thu Mar 1 18:27:01 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 1 Mar 2012 18:27:01 +0000 Subject: [PATCH] fix build without mISDN In-Reply-To: References: <1330523662-29713-2-git-send-email-alexander.huemer@xx.vu> <20120229160343.GL10919@massoud> <20120229162608.GB29813@de.xx.vu> <20120229172803.29287.qmail@stuge.se> <20120229184012.GA3768@de.xx.vu> <4F4F1EDB.7010404@eversberg.eu> <20120301124026.GC21122@prithivi.gnumonks.org> Message-ID: Hi Harald, further more i would like to know who the current commercial deployments of openbsc works. I mean the best popular scenario if not using A interface. Thanks once again and appreciate your feedback. Rgds Nik On Thu, Mar 1, 2012 at 5:53 PM, Nik Pakar wrote: > Hello Harald, > > Thanks for the reply and sorry if i was blunt to ask the question as im > new to openbsc. I was just trying to find a good sip interoperability for > opensbc while keeping ss7 in handy. > > How would you think best way to integrate it with yate as we already have > some services with yate and would like to integrate opensbc with that. All > we need is basically, > > 1. Have multiple opensbc (probably NITB but with unbundled HLR features) > connecting many nano.BTSs > 2. Connect them back to yate in some way > 3. let the call handling to take care of yate > i.e. any MO call to routed to yate and yate will consult the HLR database > and decide which BSC it should send it back to. > > WHat would be the best way to achieve this ? > > BTW, yate does support both AMR and GSM codes. > > Thanks again Harald for your valuable result and openbsc is a great > software im just new to it, but i find it extremely useful and just trying > to make it use in a commercial environment. > > Thanks again > Nik. > > On Thu, Mar 1, 2012 at 12:40 PM, Harald Welte wrote: > >> Hi Nik, >> >> On Thu, Mar 01, 2012 at 11:05:45AM +0000, Nik Pakar wrote: >> >> > 1. Use OpenBSC Nitb as its on LCR and implement a gsm channel driver for >> > yate. >> >> Well, you are asking the lcr author to implement something for yate. I >> think it may be a bit of a strange question ;) >> >> > 2. Use extensive SCCP, MAP implementation already on yate and implement >> > full A interface integration towards yate. >> >> I would be honestly surprised if yate implemented connection-oriented >> SCCP procedures. This is only used on the GSM A interface and not to be >> mistaken with the datagram-oriented SCCP (UDT only) used by TCAP/MAP. >> >> In fact, it might make more sense to use the existing libosmo-sccp and >> either >> 1) add SCCP-lite (IPA multiplex) support to yate >> or >> 2) implement M3UA as a transport for osmo-bsc's existing libosmo-sccp >> and use that to connect to yate. >> >> But then, I am not aware of any commercial OpenBSC user who has any >> interest in OpenBSC with classic A interface. Everybody wants to move >> away from TDM and to an all-IP RAN. >> >> Furthermore, at least as far as I know, yate may not support AMR/EFR >> codecs, which makes it somewhat limited in the context of GSM. I may be >> wrong here, though. >> >> Regards, >> Harald >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Thu Mar 1 22:49:43 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 1 Mar 2012 22:49:43 +0000 Subject: [PATCH] fix build without mISDN In-Reply-To: References: <1330523662-29713-2-git-send-email-alexander.huemer@xx.vu> <20120229160343.GL10919@massoud> <20120229162608.GB29813@de.xx.vu> <20120229172803.29287.qmail@stuge.se> <20120229184012.GA3768@de.xx.vu> <4F4F1EDB.7010404@eversberg.eu> Message-ID: Hi Andreas, i think i mis-interpret my initial question. I should have asked whether LCR can have a chan_lcr for yate like it has for asterisk. If its not there can you please give me some idea on how to build one. Thanks for your help. Rgds Nik On Thu, Mar 1, 2012 at 11:05 AM, Nik Pakar wrote: > Hi Andreas, > > Wouldnt it be better if we can integrate OpenSBC to some thing like yate > which already have extensive ss7, sigtran, camel and map parts implemented. > > It will be a perfect marriage if we can do it as both openbsc and yate > have its own strength which can make a full fledge mobile switching > environment. > > How difficult would it be either, > > 1. Use OpenBSC Nitb as its on LCR and implement a gsm channel driver for > yate. > or > 2. Use extensive SCCP, MAP implementation already on yate and implement > full A interface integration towards yate. > > Lets throw some ideas on this way, as im sure this will be a major > implementation if we can do it. > > Rgds > Nik > > On Thu, Mar 1, 2012 at 7:01 AM, Andreas Eversberg wrote: > >> >> >>>> channel.c -o bchannel.po >> >>>> bchannel.c:26:27: error: mISDN/mISDNif.h: No such file or directory >> >>>> bchannel.c:28:31: error: mISDN/mISDNcompat.h: No such file or >> directory >> >>>> bchannel.c:29: error: 'MISDN_AF_ISDN' undeclared here (not in a >> function) >> >>>> bchannel.c:30:24: error: mISDN/q931.h: No such file or directory >> >>>> >> >> hi, >> >> currently the chan_lcr only works with mISDN. the chan_lcr directly >> opens the bchannels in order to exchange audio with asterisk. this only >> works if the call is connected to isdn phone or isdn line, since only >> these interfaces support mISDN. gsm and sip interface cannot be used >> with chan_lcr (anymore). >> >> i plan to forward audio between lcr and chan_lcr using the unix-socket >> and remove the export/import code from lcr. >> >> currently you can only link gsm insterfaces to asterisk using sip. with >> jolly/rtpmux branch of openbsc, you can even forward rtp traffic >> directly between openbsc and the remote sip endpoint (asterisk or other >> sip gateway), without routing traffic through lcr. >> >> if you have any suggestions about further development, let me know. >> >> regards, >> >> andreas >> >> p.s. i committed the appbridge.cpp fix of alexander. thanx! >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at 00100100.net Thu Mar 1 21:46:14 2012 From: don at 00100100.net (Don Fanning) Date: Thu, 1 Mar 2012 13:46:14 -0800 Subject: Adding subscriber to HLR database Message-ID: Does anyone have the steps/commands to add a new handset to the HLR database? I wanted to add in a new handset into my system but couldn't find the information short of opening access to the site. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Mar 1 21:51:47 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 1 Mar 2012 22:51:47 +0100 Subject: Adding subscriber to HLR database In-Reply-To: References: Message-ID: <20120301215147.14400.qmail@stuge.se> Don Fanning wrote: > Does anyone have the steps/commands to add a new handset to the HLR > database? > > I wanted to add in a new handset into my system but couldn't find the > information short of opening access to the site. Insert it into the sqlite3 database. I don't believe there is a special purpose tool to do it. You can use the sqlite3 command line tool to execute SQL against the nitb database. //Peter From nikpakar at gmail.com Thu Mar 1 21:55:23 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 1 Mar 2012 21:55:23 +0000 Subject: Adding subscriber to HLR database In-Reply-To: References: Message-ID: You can just attempt to register which will automatically insert the suscbriber details to HLR with authorized=0 which you can enable later from Vty. On Thu, Mar 1, 2012 at 9:46 PM, Don Fanning wrote: > Does anyone have the steps/commands to add a new handset to the HLR > database? > > I wanted to add in a new handset into my system but couldn't find the > information short of opening access to the site. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller.lennart at googlemail.com Thu Mar 1 22:11:39 2012 From: mueller.lennart at googlemail.com (=?ISO-8859-1?Q?Lennart_M=FCller?=) Date: Thu, 1 Mar 2012 23:11:39 +0100 Subject: Adding subscriber to HLR database In-Reply-To: References: Message-ID: 2012/3/1 Don Fanning > Does anyone have the steps/commands to add a new handset to the HLR > database? > > I wanted to add in a new handset into my system but couldn't find the > information short of opening access to the site. > > Try to manually log on your handset to your network - first registration will fail normally. OpenBSC stores new subscribers into the database. Then you can enable the IMSI via telnet 4242: > enable # subscriber imsi extension # subscriber imsi authorized 1 Now you are able to register your handset to the network. -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at 00100100.net Thu Mar 1 22:31:38 2012 From: don at 00100100.net (Don Fanning) Date: Thu, 1 Mar 2012 14:31:38 -0800 Subject: Adding subscriber to HLR database In-Reply-To: References: Message-ID: Ah... yeah, I was hoping to pre-register so I don't confused the end user having to register a couple times. I was also told that the table is auto increment so that helps in writing a quickie cli for creating and provisioning SIM's. Hopefully we'll be able to test the system out at HOPE in NYC. :) Thank you all and Cheers! On Thu, Mar 1, 2012 at 2:11 PM, Lennart M?ller < mueller.lennart at googlemail.com> wrote: > 2012/3/1 Don Fanning > >> Does anyone have the steps/commands to add a new handset to the HLR >> database? >> >> I wanted to add in a new handset into my system but couldn't find the >> information short of opening access to the site. >> >> > Try to manually log on your handset to your network - first registration > will fail normally. OpenBSC stores new subscribers into the database. > > Then you can enable the IMSI via telnet 4242: > > > enable > # subscriber imsi extension > # subscriber imsi authorized 1 > > Now you are able to register your handset to the network. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Fri Mar 2 00:22:45 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 2 Mar 2012 00:22:45 +0000 Subject: MySQL for HLR Message-ID: Is it possible to use mysql for HLR. I can see some notes within the source. Rgds Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Fri Mar 2 00:33:53 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 2 Mar 2012 01:33:53 +0100 Subject: MySQL for HLR In-Reply-To: References: Message-ID: <20120302003353.26230.qmail@stuge.se> Nik Pakar wrote: > Is it possible to use mysql for HLR. I can see some notes within > the source. The database access uses libdbi, which means that MySQL or MariaDB may actually already be supported. The code however doesn't support specifying which database to use, so you will have to make some trivial changes to libmsc/db.c. I'm also interested in this topic, so if you try it out please share results. //Peter From holger at freyther.de Fri Mar 2 00:43:44 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 02 Mar 2012 01:43:44 +0100 Subject: MySQL for HLR In-Reply-To: <20120302003353.26230.qmail@stuge.se> References: <20120302003353.26230.qmail@stuge.se> Message-ID: <4F5017C0.2090807@freyther.de> On 03/02/2012 01:33 AM, Peter Stuge wrote: > Nik Pakar wrote: > I'm also interested in this topic, so if you try it out please share > results. another topic is to make looking up a subscriber async and writing... just write through. holger From laforge at gnumonks.org Sat Mar 3 10:47:07 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 3 Mar 2012 11:47:07 +0100 Subject: MySQL for HLR In-Reply-To: <4F5017C0.2090807@freyther.de> References: <20120302003353.26230.qmail@stuge.se> <4F5017C0.2090807@freyther.de> Message-ID: <20120303104707.GM21016@prithivi.gnumonks.org> On Fri, Mar 02, 2012 at 01:43:44AM +0100, Holger Hans Peter Freyther wrote: > On 03/02/2012 01:33 AM, Peter Stuge wrote: > > Nik Pakar wrote: > > > I'm also interested in this topic, so if you try it out please share > > results. > > another topic is to make looking up a subscriber async and writing... just > write through. this is the much more important topic. Without that change, it is completely useless to switch to another database. In fact, it may make things worse due to higher latency caused by inter-process communication between DB client (openbsc) and DB server. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nikpakar at gmail.com Sat Mar 3 12:52:25 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 12:52:25 +0000 Subject: MySQL for HLR In-Reply-To: <20120303104707.GM21016@prithivi.gnumonks.org> References: <20120302003353.26230.qmail@stuge.se> <4F5017C0.2090807@freyther.de> <20120303104707.GM21016@prithivi.gnumonks.org> Message-ID: This tight integration of a db back end will have lot more limitation when it comes to scalable deployment. i.e. 100s of BTS connecting to more than one BSCs which will need a common database backend as the the HLR. We might not need BSCs to talk to HLR in proper MAP interface, but atleast they can do talk directly to HLR DB using db driver for now. Is there anyway we can get into mysql integration. I will give it a try if some one can put bit more light on that way. Rgds Nik On Sat, Mar 3, 2012 at 10:47 AM, Harald Welte wrote: > On Fri, Mar 02, 2012 at 01:43:44AM +0100, Holger Hans Peter Freyther wrote: > > On 03/02/2012 01:33 AM, Peter Stuge wrote: > > > Nik Pakar wrote: > > > > > I'm also interested in this topic, so if you try it out please share > > > results. > > > > another topic is to make looking up a subscriber async and writing... > just > > write through. > > this is the much more important topic. Without that change, it is > completely useless to switch to another database. In fact, it may make > things worse due to higher latency caused by inter-process > communication between DB client (openbsc) and DB server. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sat Mar 3 17:32:44 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 03 Mar 2012 18:32:44 +0100 Subject: MySQL for HLR In-Reply-To: References: <20120302003353.26230.qmail@stuge.se> <4F5017C0.2090807@freyther.de> <20120303104707.GM21016@prithivi.gnumonks.org> Message-ID: <4F5255BC.8000602@freyther.de> On 03/03/2012 01:52 PM, Nik Pakar wrote: > > Is there anyway we can get into mysql integration. I will give it a try if > some one can put bit more light on that way. Hi, it is as easy as writing the code, or find someone to write the code for you. We will be happy to integrate the code if it matches the quality criteria and is split up in a way one can review the contribution. h. From laforge at gnumonks.org Sat Mar 3 18:03:24 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 3 Mar 2012 19:03:24 +0100 Subject: MySQL for HLR In-Reply-To: References: <20120302003353.26230.qmail@stuge.se> <4F5017C0.2090807@freyther.de> <20120303104707.GM21016@prithivi.gnumonks.org> Message-ID: <20120303180324.GO21016@prithivi.gnumonks.org> Nik, On Sat, Mar 03, 2012 at 12:52:25PM +0000, Nik Pakar wrote: > This tight integration of a db back end will have lot more limitation when > it comes to scalable deployment. i.e. 100s of BTS connecting to more than > one BSCs which will need a common database backend as the the HLR. I have made it _very_ clear that the bottleneck is not the sqlite3 integration. Trust me, the problem is an architectural problem with the lack of asynchronous processing of subscriber lookups. You are looking at a symptom, not the cause. The people involved in OpenBSC have a very good understanding of what needs to be done. It is a volunteer project driven by poeple who want to contribute. If you want a scalable database backend, I suggest you contribute code to first make the subscriber lookups asynchronous, and then generalize it away from sqlite3. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sat Mar 3 19:44:48 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 3 Mar 2012 20:44:48 +0100 Subject: MySQL for HLR In-Reply-To: <20120303180324.GO21016@prithivi.gnumonks.org> References: <20120302003353.26230.qmail@stuge.se> <4F5017C0.2090807@freyther.de> <20120303104707.GM21016@prithivi.gnumonks.org> <20120303180324.GO21016@prithivi.gnumonks.org> Message-ID: <20120303194448.4889.qmail@stuge.se> Harald Welte wrote: > If you want a scalable database backend, I suggest you contribute > code to first make the subscriber lookups asynchronous, and then > generalize it away from sqlite3. I think it's fine to do it the other way around as well, and may be an easier entry to the codebase. Better database abstraction is desirable also on it's own, even if it isn't sufficient to make a leap in scalability. //Peter From alexander.huemer at xx.vu Fri Mar 2 08:50:57 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Fri, 2 Mar 2012 09:50:57 +0100 Subject: MySQL for HLR In-Reply-To: References: Message-ID: <20120302085057.GA17989@de.xx.vu> Hi Nik, On Fri, Mar 02, 2012 at 12:22:45AM +0000, Nik Pakar wrote: > Is it possible to use mysql for HLR. I can see some notes within the source. some thoughts: AFAIR there was a patch on the ML quite a long time ago that added mysql support. I have no idea if it worked or still applies or anything. Are you sure you want to use mysql and not something like postgres? I remember that somebody stumbled over a weirdness in the way the data is actually stored in the DB (sqlite), which was caused by the DBI layer. Maybe you want to have a look at the ML archive. Kind regards, -Alexander Huemer From gugod at gugod.org Fri Mar 2 17:36:41 2012 From: gugod at gugod.org (Kang-min Liu) Date: Sat, 3 Mar 2012 01:36:41 +0800 Subject: MySQL for HLR In-Reply-To: <20120302085057.GA17989@de.xx.vu> References: <20120302085057.GA17989@de.xx.vu> Message-ID: <96BFDFA2-57FB-48A9-9164-033A5D5631BC@gugod.org> On 2012/3/2, at ??4:50, Alexander Huemer wrote: > > I remember that somebody stumbled over a weirdness in the way the data > is actually stored in the DB (sqlite), which was caused by the DBI > layer. That would be me. To recap: libdbi (c lib) store binary value in its own way. It escapes the value to make it fit in a SQL string, instead of sqlite3_bind_blob function to store the actual raw value. It bugged me because I was trying to read the db from a perl program. I ended up porting the escaping/unescaping subroutine to perl in order to read/write the SMS table. Sincerely, Kang-min Liu From peter at stuge.se Fri Mar 2 18:58:35 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 2 Mar 2012 19:58:35 +0100 Subject: MySQL for HLR In-Reply-To: <96BFDFA2-57FB-48A9-9164-033A5D5631BC@gugod.org> References: <20120302085057.GA17989@de.xx.vu> <96BFDFA2-57FB-48A9-9164-033A5D5631BC@gugod.org> Message-ID: <20120302185835.19920.qmail@stuge.se> Kang-min Liu wrote: > To recap: libdbi (c lib) store binary value in its own way. Ahh. Thanks for this hint. > It escapes the value to make it fit in a SQL string, instead of > sqlite3_bind_blob function to store the actual raw value. It bugged > me because I was trying to read the db from a perl program. I ended > up porting the escaping/unescaping subroutine to perl in order to > read/write the SMS table. We'll have to change this to a more powerful solution soon. (Maybe both some database bits but in particular SMSes.) Kind regards //Peter From nikpakar at gmail.com Fri Mar 2 00:27:18 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 2 Mar 2012 00:27:18 +0000 Subject: OpenBSC-LCR integration Message-ID: When OpenBSC integrates with LCR, is it mean all call routing capabilities going to LCR including gsm-gsm on net calls. Or is it only external calls going to LCR while gsm-gsm calls routed within NITB Rgds Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Fri Mar 2 00:34:35 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 2 Mar 2012 01:34:35 +0100 Subject: OpenBSC-LCR integration In-Reply-To: References: Message-ID: <20120302003435.26320.qmail@stuge.se> Nik Pakar wrote: > When OpenBSC integrates with LCR, is it mean all call routing capabilities > going to LCR including gsm-gsm on net calls. Or is it only external calls > going to LCR while gsm-gsm calls routed within NITB All calls go to lcr. //Peter From nikpakar at gmail.com Fri Mar 2 15:33:55 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 2 Mar 2012 15:33:55 +0000 Subject: OpenBSC-LCR integration In-Reply-To: <20120302003435.26320.qmail@stuge.se> References: <20120302003435.26320.qmail@stuge.se> Message-ID: Thanks Peter, Im trying to get it working. I have openbsc NITB working all fine. But very little luck in LCR. When compiled with options it didnt even show up /usr/local/lcr/gsm.conf either Any reason for this ? Thanks in advance for the help. Rgds Nik On Fri, Mar 2, 2012 at 12:34 AM, Peter Stuge wrote: > Nik Pakar wrote: > > When OpenBSC integrates with LCR, is it mean all call routing > capabilities > > going to LCR including gsm-gsm on net calls. Or is it only external calls > > going to LCR while gsm-gsm calls routed within NITB > > All calls go to lcr. > > > //Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Fri Mar 2 17:08:45 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 2 Mar 2012 17:08:45 +0000 Subject: Compiling LCR for OpenBSC Message-ID: Do I have to have mISDN for LCR even im not going to use any isdn interface ? Im trying to connect the NITB to LCR and LCR to asterisk all on ip. Thanks for any help. Rgds Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.huemer at xx.vu Fri Mar 2 20:29:11 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Fri, 2 Mar 2012 21:29:11 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: Message-ID: <20120302202909.GA3720@de.xx.vu> Hi Nik, On Fri, Mar 02, 2012 at 05:08:45PM +0000, Nik Pakar wrote: > Do I have to have mISDN for LCR even im not going to use any isdn interface > ? Im trying to connect the NITB to LCR and LCR to asterisk all on ip. > see http://www.isdn4linux.de/pipermail/isdn4linux/2012-March/005688.html Kind regards, -Alexander Huemer From nikpakar at gmail.com Sat Mar 3 12:48:51 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 12:48:51 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: <20120302202909.GA3720@de.xx.vu> References: <20120302202909.GA3720@de.xx.vu> Message-ID: I think im little bit lost here now the way it should work. As per this link it only works with isdn interface not sip. All im trying to do is, [MS]---[nanoBTS]----[OpenBSC NITB]---(ip)---[LCR]---(ip)---[Asterisk]----(sip)---> Is this what its been made for or are there any E1/ISDN interfaces in the middle. On Fri, Mar 2, 2012 at 8:29 PM, Alexander Huemer wrote: > Hi Nik, > > On Fri, Mar 02, 2012 at 05:08:45PM +0000, Nik Pakar wrote: > > Do I have to have mISDN for LCR even im not going to use any isdn > interface > > ? Im trying to connect the NITB to LCR and LCR to asterisk all on ip. > > > see http://www.isdn4linux.de/pipermail/isdn4linux/2012-March/005688.html > > Kind regards, > -Alexander Huemer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Sat Mar 3 19:25:35 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 19:25:35 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <20120302202909.GA3720@de.xx.vu> Message-ID: Hi Carecel, I also still strugling with no luck. I have a very good understanding of the openbsc and it works well as the NITB. But LCR and asterisk integration is no where closer. Im using debian 6.0.4 Asterisk 1.8.9.3 OpenBSC, Osmocore, Osmo-abis : latest git clone LCR : latest git clone mISDN : downloaded from the site First thing didnt aligned with documentation is the LCR patch doesnt seems apply. I assume the developers has made the patch into it, so its not applying. But when i inspect the source of gsm_bs.cpp, doesnt seems there either. Passing on - once LCR compiled with asterisk and gsm_bs, it doesnt even create a gsm.conf So almost no go from that point. Anyway, now im waiting for some feedback about the actual topology of it since its unclear whether we still need E1/ISDN in the middle to integrate this. If that is the case i wouldnt want to try that. Been all IP solution, there is no point having TDM in the middle at all. Do you have any idea about that ? Nik. On Sat, Mar 3, 2012 at 12:48 PM, Nik Pakar wrote: > I think im little bit lost here now the way it should work. As per this > link it only works with isdn interface not sip. > > All im trying to do is, > > [MS]---[nanoBTS]----[OpenBSC > NITB]---(ip)---[LCR]---(ip)---[Asterisk]----(sip)---> > > Is this what its been made for or are there any E1/ISDN interfaces in the > middle. > > > On Fri, Mar 2, 2012 at 8:29 PM, Alexander Huemer wrote: > >> Hi Nik, >> >> On Fri, Mar 02, 2012 at 05:08:45PM +0000, Nik Pakar wrote: >> > Do I have to have mISDN for LCR even im not going to use any isdn >> interface >> > ? Im trying to connect the NITB to LCR and LCR to asterisk all on ip. >> > >> see http://www.isdn4linux.de/pipermail/isdn4linux/2012-March/005688.html >> >> Kind regards, >> -Alexander Huemer >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Sat Mar 3 21:09:22 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 21:09:22 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <20120302202909.GA3720@de.xx.vu> Message-ID: Another attempt with all sources downloaded from this link has failed when building LCR :( http://www.linux-call-router.de/download/lcr-1.7/ --- g++ -g -O2 -o gentones gentones.o -lpthread -lncurses -lm g++ -DHAVE_CONFIG_H -I. -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -g -O2 -MT genwave.o -MD -MP -MF .deps/genwave.Tpo -c -o genwave.o genwave.c mv -f .deps/genwave.Tpo .deps/genwave.Po g++ -g -O2 -o genwave genwave.o -lpthread -lncurses -lm gcc -DWITH_GSM_BS -I./openbsc/include -I./libosmocore/include -I./openbsc -Wall -DCONFIG_DATA="\"/usr/local/lcr\"" -DSHARE_DATA="\"/usr/local/lcr\"" -DLOG_DIR="\"/usr/local/lcr\"" -DEXTENSION_DATA="\"/usr/local/lcr/extensions\"" -D_GNU_SOURCE -fPIC -c chan_lcr.c -o chan_lcr.po chan_lcr.c: In function ?send_setup_to_lcr?: chan_lcr.c:644: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:655: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c: In function ?lcr_in_setup?: chan_lcr.c:858: warning: passing argument 9 of ?__ast_channel_alloc? makes integer from pointer without a cast /usr/include/asterisk/channel.h:1112: note: expected ?int? but argument is of type ?char *? chan_lcr.c:883: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:885: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:887: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:890: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:893: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:896: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:900: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:903: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:906: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:909: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c: In function ?handle_queue?: chan_lcr.c:1707: error: incompatible types when assigning to type ?union ast_frame_subclass? from type ?char? chan_lcr.c: In function ?lcr_request?: chan_lcr.c:1820: warning: passing argument 9 of ?__ast_channel_alloc? makes integer from pointer without a cast /usr/include/asterisk/channel.h:1112: note: expected ?int? but argument is of type ?char *? chan_lcr.c: In function ?lcr_call?: chan_lcr.c:1927: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1927: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1928: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1931: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1931: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1932: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1934: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1934: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c:1935: error: ?struct ast_channel? has no member named ?cid? chan_lcr.c: In function ?lcr_write?: chan_lcr.c:2164: error: wrong type argument to unary exclamation mark chan_lcr.c:2166: error: invalid operands to binary & (have ?union ast_frame_subclass? and ?format_t?) chan_lcr.c: In function ?lcr_read?: chan_lcr.c:2229: error: incompatible types when assigning to type ?union ast_frame_subclass? from type ?format_t? chan_lcr.c: In function ?lcr_indicate?: chan_lcr.c:2274: warning: assignment from incompatible pointer type chan_lcr.c:2289: warning: assignment from incompatible pointer type chan_lcr.c:2316: warning: assignment from incompatible pointer type chan_lcr.c:2381: error: dereferencing pointer to incomplete type chan_lcr.c:2382: error: dereferencing pointer to incomplete type chan_lcr.c: At top level: chan_lcr.c:2602: warning: initialization from incompatible pointer type chan_lcr.c: In function ?load_module?: chan_lcr.c:2818: warning: passing argument 2 of ?ast_register_application2? from incompatible pointer type /usr/include/asterisk/module.h:458: note: expected ?int (*)(struct ast_channel *, const char *)? but argument is of type ?int (*)(struct ast_channel *, void *)? make[1]: *** [chan_lcr.po] Error 1 make[1]: Leaving directory `/usr/local/src/lcr' make: *** [all] Error 2 On Sat, Mar 3, 2012 at 7:25 PM, Nik Pakar wrote: > Hi Carecel, > > I also still strugling with no luck. I have a very good understanding of > the openbsc and it works well as the NITB. > > But LCR and asterisk integration is no where closer. > > Im using debian 6.0.4 > Asterisk 1.8.9.3 > OpenBSC, Osmocore, Osmo-abis : latest git clone > LCR : latest git clone > mISDN : downloaded from the site > > First thing didnt aligned with documentation is the LCR patch doesnt seems > apply. I assume the developers has made the patch into it, so its not > applying. But when i inspect the source of gsm_bs.cpp, doesnt seems there > either. > > Passing on - once LCR compiled with asterisk and gsm_bs, it doesnt even > create a gsm.conf > > So almost no go from that point. > > Anyway, now im waiting for some feedback about the actual topology of it > since its unclear whether we still need E1/ISDN in the middle to integrate > this. If that is the case i wouldnt want to try that. Been all IP solution, > there is no point having TDM in the middle at all. > > Do you have any idea about that ? > > Nik. > > On Sat, Mar 3, 2012 at 12:48 PM, Nik Pakar wrote: > >> I think im little bit lost here now the way it should work. As per this >> link it only works with isdn interface not sip. >> >> All im trying to do is, >> >> [MS]---[nanoBTS]----[OpenBSC >> NITB]---(ip)---[LCR]---(ip)---[Asterisk]----(sip)---> >> >> Is this what its been made for or are there any E1/ISDN interfaces in the >> middle. >> >> >> On Fri, Mar 2, 2012 at 8:29 PM, Alexander Huemer wrote: >> >>> Hi Nik, >>> >>> On Fri, Mar 02, 2012 at 05:08:45PM +0000, Nik Pakar wrote: >>> > Do I have to have mISDN for LCR even im not going to use any isdn >>> interface >>> > ? Im trying to connect the NITB to LCR and LCR to asterisk all on ip. >>> > >>> see http://www.isdn4linux.de/pipermail/isdn4linux/2012-March/005688.html >>> >>> Kind regards, >>> -Alexander Huemer >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Mon Mar 5 07:44:40 2012 From: andreas at eversberg.eu (jolly) Date: Mon, 05 Mar 2012 08:44:40 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: Message-ID: <4F546EE8.8020901@eversberg.eu> > Do I have to have mISDN for LCR even im not going to use any isdn > interface ? Im trying to connect the NITB to LCR and LCR to asterisk > all on ip. > > Thanks for any help. > > Rgds > Nik hi nik, you don't need misdn to use lcr with sip and gsm anymore. also you don't need any patch. the lcr and openbsc compile out of the box supporting each other. the howto is a bit outdated. try to compile the lcr from the git. don't use chan_lcr, since it still works with isdn only. you need to setup a sip interface in interface.conf: [sip] sip [:] sip 10.0.0.12 10.0.0.34 earlyb no tones no use asterisk machine for remote ip. if you have asterisk on the same machine, change the sip port of asterisk and use "remoteip:port". regards, andreas From alexander.chemeris at gmail.com Mon Mar 5 09:58:12 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 5 Mar 2012 13:58:12 +0400 Subject: Compiling LCR for OpenBSC In-Reply-To: <4F546EE8.8020901@eversberg.eu> References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hi Jolly, On Mon, Mar 5, 2012 at 11:44, jolly wrote: > you don't need misdn to use lcr with sip and gsm anymore. also you don't > need any patch. the lcr and openbsc compile out of the box supporting > each other. the howto is a bit outdated. > > try to compile the lcr from the git. don't use chan_lcr, since it still > works with isdn only. you need to setup a sip interface in interface.conf: > > [sip] > sip [:] > sip 10.0.0.12 10.0.0.34 > earlyb no > tones no > > use asterisk machine for remote ip. ?if you have asterisk on the same > machine, change the sip port of asterisk and use "remoteip:port". Does it mean that that now we can use LCR with other SIP softswitches/PBX'es, like Freeswitch? I do not follow LCR development closely, but that would be a very interesting development. -- Regards, Alexander Chemeris. From andreas at eversberg.eu Mon Mar 5 10:05:04 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 05 Mar 2012 11:05:04 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: <4F548FD0.8020603@eversberg.eu> Alexander Chemeris wrote: > Does it mean that that now we can use LCR with other SIP > softswitches/PBX'es, like Freeswitch? I do not follow LCR development > closely, but that would be a very interesting development. > yes, this was my intention. gsm and sip interface of lcr will not rely on misdn anymore. currently i don't support audio transfer via chan_lcr, so chan_lcr will only work with isdn interfaces. the sip interface implementation has not much options, so it can only do sipmple point-to-point sip connections to a gateway or endpoint. From nikpakar at gmail.com Tue Mar 6 07:44:51 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Tue, 6 Mar 2012 07:44:51 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: <4F548FD0.8020603@eversberg.eu> References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Hi Andreas, It was apperently compiled on my debian while i had misdn libs isntalled. Now im trying on a fresh debian from the same set of sources which i got it working and without misdn, it fails to compile gsm. Attached is my config output and compile break. http://pastebin.com/W6UHn4Lc So should i still install misdn even though its not used. Rgds Nik On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg wrote: > Alexander Chemeris wrote: > > Does it mean that that now we can use LCR with other SIP > > softswitches/PBX'es, like Freeswitch? I do not follow LCR development > > closely, but that would be a very interesting development. > > > yes, this was my intention. gsm and sip interface of lcr will not rely > on misdn anymore. currently i don't support audio transfer via chan_lcr, > so chan_lcr will only work with isdn interfaces. the sip interface > implementation has not much options, so it can only do sipmple > point-to-point sip connections to a gateway or endpoint. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Tue Mar 6 12:51:15 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Tue, 6 Mar 2012 12:51:15 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Hi Andreas, i now have calls coming from external sip->LCR->gsm But still cant figure out the dial plan to send a call out on sip, gsm->LCR->sip I tried, dialing=072333444 : extern interfaces=sip prefix=072333444 But on LCR trace it shows as below. I think im missing some thing small here. Appreciate if you can give a little hint. Thanks nik 06.03.12 12:40:41.286 EP(1): ACTION (match) action goto line 11 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ruleset extern dialing 072333444 06.03.12 12:40:41.286 EP(1): ACTION (match) action extern line 28 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) number 072333444 interfaces sip 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE to CH(1) 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given interface) interface sip 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) interface?@ 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) 06.03.12 12:40:41.287 EP(1): TONE to CH(1) directory default name cause_22 06.03.12 12:40:41.287 EP(1): DISCONNECT to CH(1) cause value=34 location=1-Local-PBX 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC progress coding=3 location=1 descr=8 cause coding=3 location=1 value=34 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC cause coding=3 location=0 value=16 06.03.12 12:40:56.247 EP(1): RELEASE from CH(1) cause value=16 location=0-User 06.03.12 12:40:56.247 EP(1): ACTION hangup On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar wrote: > Hi Andreas, > > It was apperently compiled on my debian while i had misdn libs isntalled. > Now im trying on a fresh debian from the same set of sources which i got it > working and without misdn, it fails to compile gsm. > > Attached is my config output and compile break. > > http://pastebin.com/W6UHn4Lc > > So should i still install misdn even though its not used. > > Rgds > Nik > > > On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg wrote: > >> Alexander Chemeris wrote: >> > Does it mean that that now we can use LCR with other SIP >> > softswitches/PBX'es, like Freeswitch? I do not follow LCR development >> > closely, but that would be a very interesting development. >> > >> yes, this was my intention. gsm and sip interface of lcr will not rely >> on misdn anymore. currently i don't support audio transfer via chan_lcr, >> so chan_lcr will only work with isdn interfaces. the sip interface >> implementation has not much options, so it can only do sipmple >> point-to-point sip connections to a gateway or endpoint. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Tue Mar 6 15:38:14 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Tue, 6 Mar 2012 15:38:14 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Hi Andreas, got it working both ways now. Many thanks for nice work. I will now test it further with transcoding. And start on the documentation. Rgds Nik On Tue, Mar 6, 2012 at 12:51 PM, Nik Pakar wrote: > Hi Andreas, i now have calls coming from external sip->LCR->gsm > > But still cant figure out the dial plan to send a call out on sip, > gsm->LCR->sip > > I tried, > > dialing=072333444 : extern interfaces=sip prefix=072333444 > > But on LCR trace it shows as below. I think im missing some thing small > here. Appreciate if you can give a little hint. > > Thanks > nik > > 06.03.12 12:40:41.286 EP(1): ACTION (match) action goto line 11 > 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ruleset extern > dialing 072333444 > 06.03.12 12:40:41.286 EP(1): ACTION (match) action extern line 28 > 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) number 072333444 > interfaces sip > 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE to CH(1) > 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given interface) > interface sip > 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) interface?@ > 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) > 06.03.12 12:40:41.287 EP(1): TONE to CH(1) directory default name > cause_22 > 06.03.12 12:40:41.287 EP(1): DISCONNECT to CH(1) cause value=34 > location=1-Local-PBX > 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC progress coding=3 > location=1 descr=8 cause coding=3 location=1 value=34 > 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC cause coding=3 > location=0 value=16 > 06.03.12 12:40:56.247 EP(1): RELEASE from CH(1) cause value=16 > location=0-User > 06.03.12 12:40:56.247 EP(1): ACTION hangup > > > On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar wrote: > >> Hi Andreas, >> >> It was apperently compiled on my debian while i had misdn libs isntalled. >> Now im trying on a fresh debian from the same set of sources which i got it >> working and without misdn, it fails to compile gsm. >> >> Attached is my config output and compile break. >> >> http://pastebin.com/W6UHn4Lc >> >> So should i still install misdn even though its not used. >> >> Rgds >> Nik >> >> >> On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg wrote: >> >>> Alexander Chemeris wrote: >>> > Does it mean that that now we can use LCR with other SIP >>> > softswitches/PBX'es, like Freeswitch? I do not follow LCR development >>> > closely, but that would be a very interesting development. >>> > >>> yes, this was my intention. gsm and sip interface of lcr will not rely >>> on misdn anymore. currently i don't support audio transfer via chan_lcr, >>> so chan_lcr will only work with isdn interfaces. the sip interface >>> implementation has not much options, so it can only do sipmple >>> point-to-point sip connections to a gateway or endpoint. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Wed Mar 7 15:17:41 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Wed, 7 Mar 2012 15:17:41 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Hi Andreas, Call signalling all works fine right through out from NITB to LCR and out on SIP. how ever im getting some strange media behaviour. My setup is, [MS]---[nano.BTS]---[NITB/LCR]----[SIP Softswitch] LCR is setup to bridge two interfaces, so what ever comes from gsm goes to sip and what ever comes from sip goes to gsm. Now a test call from a mobile to mobile, should go all the way to the softswitch and come back. All works fine in terms of signalling. But in media, LCR seems sending initial SDP to the softswitch as PCMA:8 not gsm FR. So softswitch expect the media as PCMA and not transcoding. Same if the call goes out from softswitch, still no medial as it think incoming media from LCR is on PCMA. Any idea about this ? This is the LCR trace - http://pastebin.com/5PNKYc5m This is the sip trace from softswitch - http://pastebin.com/cVtx1mFB Rgds Nik On Tue, Mar 6, 2012 at 3:38 PM, Nik Pakar wrote: > Hi Andreas, got it working both ways now. Many thanks for nice work. > > I will now test it further with transcoding. > > And start on the documentation. > > Rgds > Nik > > On Tue, Mar 6, 2012 at 12:51 PM, Nik Pakar wrote: > >> Hi Andreas, i now have calls coming from external sip->LCR->gsm >> >> But still cant figure out the dial plan to send a call out on sip, >> gsm->LCR->sip >> >> I tried, >> >> dialing=072333444 : extern interfaces=sip prefix=072333444 >> >> But on LCR trace it shows as below. I think im missing some thing small >> here. Appreciate if you can give a little hint. >> >> Thanks >> nik >> >> 06.03.12 12:40:41.286 EP(1): ACTION (match) action goto line 11 >> 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ruleset extern >> dialing 072333444 >> 06.03.12 12:40:41.286 EP(1): ACTION (match) action extern line 28 >> 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) number 072333444 >> interfaces sip >> 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE to CH(1) >> 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given interface) >> interface sip >> 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) interface?@ >> 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) >> 06.03.12 12:40:41.287 EP(1): TONE to CH(1) directory default name >> cause_22 >> 06.03.12 12:40:41.287 EP(1): DISCONNECT to CH(1) cause value=34 >> location=1-Local-PBX >> 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC progress coding=3 >> location=1 descr=8 cause coding=3 location=1 value=34 >> 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC cause coding=3 >> location=0 value=16 >> 06.03.12 12:40:56.247 EP(1): RELEASE from CH(1) cause value=16 >> location=0-User >> 06.03.12 12:40:56.247 EP(1): ACTION hangup >> >> >> On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar wrote: >> >>> Hi Andreas, >>> >>> It was apperently compiled on my debian while i had misdn libs >>> isntalled. Now im trying on a fresh debian from the same set of sources >>> which i got it working and without misdn, it fails to compile gsm. >>> >>> Attached is my config output and compile break. >>> >>> http://pastebin.com/W6UHn4Lc >>> >>> So should i still install misdn even though its not used. >>> >>> Rgds >>> Nik >>> >>> >>> On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg >> > wrote: >>> >>>> Alexander Chemeris wrote: >>>> > Does it mean that that now we can use LCR with other SIP >>>> > softswitches/PBX'es, like Freeswitch? I do not follow LCR development >>>> > closely, but that would be a very interesting development. >>>> > >>>> yes, this was my intention. gsm and sip interface of lcr will not rely >>>> on misdn anymore. currently i don't support audio transfer via chan_lcr, >>>> so chan_lcr will only work with isdn interfaces. the sip interface >>>> implementation has not much options, so it can only do sipmple >>>> point-to-point sip connections to a gateway or endpoint. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Wed Mar 7 15:43:11 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Wed, 7 Mar 2012 15:43:11 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Hi Andreas, is the LCR actually transcoding gsm-fr to alaw towards sip side ? Rgds Nik On Wed, Mar 7, 2012 at 3:17 PM, Nik Pakar wrote: > Hi Andreas, > > Call signalling all works fine right through out from NITB to LCR and out > on SIP. how ever im getting some strange media behaviour. > > My setup is, > > [MS]---[nano.BTS]---[NITB/LCR]----[SIP Softswitch] > > LCR is setup to bridge two interfaces, so what ever comes from gsm goes to > sip and what ever comes from sip goes to gsm. > > Now a test call from a mobile to mobile, should go all the way to the > softswitch and come back. > > All works fine in terms of signalling. > > But in media, LCR seems sending initial SDP to the softswitch as PCMA:8 > not gsm FR. > > So softswitch expect the media as PCMA and not transcoding. > > Same if the call goes out from softswitch, still no medial as it think > incoming media from LCR is on PCMA. > > Any idea about this ? > > This is the LCR trace - http://pastebin.com/5PNKYc5m > This is the sip trace from softswitch - http://pastebin.com/cVtx1mFB > > Rgds > Nik > > > On Tue, Mar 6, 2012 at 3:38 PM, Nik Pakar wrote: > >> Hi Andreas, got it working both ways now. Many thanks for nice work. >> >> I will now test it further with transcoding. >> >> And start on the documentation. >> >> Rgds >> Nik >> >> On Tue, Mar 6, 2012 at 12:51 PM, Nik Pakar wrote: >> >>> Hi Andreas, i now have calls coming from external sip->LCR->gsm >>> >>> But still cant figure out the dial plan to send a call out on sip, >>> gsm->LCR->sip >>> >>> I tried, >>> >>> dialing=072333444 : extern interfaces=sip prefix=072333444 >>> >>> But on LCR trace it shows as below. I think im missing some thing small >>> here. Appreciate if you can give a little hint. >>> >>> Thanks >>> nik >>> >>> 06.03.12 12:40:41.286 EP(1): ACTION (match) action goto line 11 >>> 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ruleset >>> extern dialing 072333444 >>> 06.03.12 12:40:41.286 EP(1): ACTION (match) action extern line 28 >>> 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) number 072333444 >>> interfaces sip >>> 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE to CH(1) >>> 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given interface) >>> interface sip >>> 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) interface?@ >>> 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) >>> 06.03.12 12:40:41.287 EP(1): TONE to CH(1) directory default name >>> cause_22 >>> 06.03.12 12:40:41.287 EP(1): DISCONNECT to CH(1) cause value=34 >>> location=1-Local-PBX >>> 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC progress coding=3 >>> location=1 descr=8 cause coding=3 location=1 value=34 >>> 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC cause coding=3 >>> location=0 value=16 >>> 06.03.12 12:40:56.247 EP(1): RELEASE from CH(1) cause value=16 >>> location=0-User >>> 06.03.12 12:40:56.247 EP(1): ACTION hangup >>> >>> >>> On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar wrote: >>> >>>> Hi Andreas, >>>> >>>> It was apperently compiled on my debian while i had misdn libs >>>> isntalled. Now im trying on a fresh debian from the same set of sources >>>> which i got it working and without misdn, it fails to compile gsm. >>>> >>>> Attached is my config output and compile break. >>>> >>>> http://pastebin.com/W6UHn4Lc >>>> >>>> So should i still install misdn even though its not used. >>>> >>>> Rgds >>>> Nik >>>> >>>> >>>> On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg < >>>> andreas at eversberg.eu> wrote: >>>> >>>>> Alexander Chemeris wrote: >>>>> > Does it mean that that now we can use LCR with other SIP >>>>> > softswitches/PBX'es, like Freeswitch? I do not follow LCR development >>>>> > closely, but that would be a very interesting development. >>>>> > >>>>> yes, this was my intention. gsm and sip interface of lcr will not rely >>>>> on misdn anymore. currently i don't support audio transfer via >>>>> chan_lcr, >>>>> so chan_lcr will only work with isdn interfaces. the sip interface >>>>> implementation has not much options, so it can only do sipmple >>>>> point-to-point sip connections to a gateway or endpoint. >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Wed Mar 7 17:36:52 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Wed, 7 Mar 2012 17:36:52 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: It seems BSC is sending payload type GSM to LCR, but LCR send payload type PCMA on the sip channel. 07.03.12 22:45:03.907 CH(69): New call ref LCR<->BSC callref new=0x80000029 07.03.12 22:45:03.907 CH(69): Codec negotiation LCR<->BSC bearer capa='given by MS' speech version='AMR given' ignored='Not suitable for LCR' version='5 given' ignored='Not supported by LCR' version='EFR given' ignored='Not suitable for LCR' version='Full Rate given' version='Half Rate given' ignored='Not suitable for LCR' 07.03.12 22:45:03.908 CH(69): MNCC_SETUP_IND LCR<->BSC calling number=07777201 imsi=413011492012312 dialing number=4290080001 07.03.12 22:45:03.908 CH(69): MNCC_LCHAN_MODIFY LCR<->BSC speech version='Full Rate given' mode 0x01 07.03.12 22:45:03.908 CH(69): MNCC_CALL_PROC_REQ LCR<->BSC progress coding=3 location=1 descr=8 07.03.12 22:45:03.908 CH(69): unknown LCR<->BSC 07.03.12 22:45:03.908 CH(70): NEW handle handle new=0x8d65cc0 07.03.12 22:45:03.908 CH(70): INVITE from uri=sip:07777201 at 192.168.1.30 to uri= sip:4290080001 at 192.168.1.25:4757 rtp ip=103.10.172.30 port=30026,30027 payload=PCMA:8 07.03.12 22:45:03.930 CH(70): RESPOND respond value=183 07.03.12 22:45:03.930 CH(70): Payload received rtp payload=PCMA:8 payload=telephone-event:101 07.03.12 22:45:13.117 CH(69): MNCC_DISC_IND LCR<->BSC cause coding=3 location=0 value=16 07.03.12 22:45:13.148 CH(69): MNCC_REL_REQ LCR<->BSC 07.03.12 22:45:13.148 CH(70): CANCEL cause value=16 07.03.12 22:45:13.169 CH(70): RESPOND respond value=487 On Wed, Mar 7, 2012 at 3:43 PM, Nik Pakar wrote: > Hi Andreas, is the LCR actually transcoding gsm-fr to alaw towards sip > side ? > > Rgds > Nik > > > On Wed, Mar 7, 2012 at 3:17 PM, Nik Pakar wrote: > >> Hi Andreas, >> >> Call signalling all works fine right through out from NITB to LCR and out >> on SIP. how ever im getting some strange media behaviour. >> >> My setup is, >> >> [MS]---[nano.BTS]---[NITB/LCR]----[SIP Softswitch] >> >> LCR is setup to bridge two interfaces, so what ever comes from gsm goes >> to sip and what ever comes from sip goes to gsm. >> >> Now a test call from a mobile to mobile, should go all the way to the >> softswitch and come back. >> >> All works fine in terms of signalling. >> >> But in media, LCR seems sending initial SDP to the softswitch as PCMA:8 >> not gsm FR. >> >> So softswitch expect the media as PCMA and not transcoding. >> >> Same if the call goes out from softswitch, still no medial as it think >> incoming media from LCR is on PCMA. >> >> Any idea about this ? >> >> This is the LCR trace - http://pastebin.com/5PNKYc5m >> This is the sip trace from softswitch - http://pastebin.com/cVtx1mFB >> >> Rgds >> Nik >> >> >> On Tue, Mar 6, 2012 at 3:38 PM, Nik Pakar wrote: >> >>> Hi Andreas, got it working both ways now. Many thanks for nice work. >>> >>> I will now test it further with transcoding. >>> >>> And start on the documentation. >>> >>> Rgds >>> Nik >>> >>> On Tue, Mar 6, 2012 at 12:51 PM, Nik Pakar wrote: >>> >>>> Hi Andreas, i now have calls coming from external sip->LCR->gsm >>>> >>>> But still cant figure out the dial plan to send a call out on sip, >>>> gsm->LCR->sip >>>> >>>> I tried, >>>> >>>> dialing=072333444 : extern interfaces=sip prefix=072333444 >>>> >>>> But on LCR trace it shows as below. I think im missing some thing small >>>> here. Appreciate if you can give a little hint. >>>> >>>> Thanks >>>> nik >>>> >>>> 06.03.12 12:40:41.286 EP(1): ACTION (match) action goto line 11 >>>> 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ruleset >>>> extern dialing 072333444 >>>> 06.03.12 12:40:41.286 EP(1): ACTION (match) action extern line 28 >>>> 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) number 072333444 >>>> interfaces sip >>>> 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE to CH(1) >>>> 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given interface) >>>> interface sip >>>> 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) interface?@ >>>> 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) >>>> 06.03.12 12:40:41.287 EP(1): TONE to CH(1) directory default name >>>> cause_22 >>>> 06.03.12 12:40:41.287 EP(1): DISCONNECT to CH(1) cause value=34 >>>> location=1-Local-PBX >>>> 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC progress coding=3 >>>> location=1 descr=8 cause coding=3 location=1 value=34 >>>> 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC cause coding=3 >>>> location=0 value=16 >>>> 06.03.12 12:40:56.247 EP(1): RELEASE from CH(1) cause value=16 >>>> location=0-User >>>> 06.03.12 12:40:56.247 EP(1): ACTION hangup >>>> >>>> >>>> On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar wrote: >>>> >>>>> Hi Andreas, >>>>> >>>>> It was apperently compiled on my debian while i had misdn libs >>>>> isntalled. Now im trying on a fresh debian from the same set of sources >>>>> which i got it working and without misdn, it fails to compile gsm. >>>>> >>>>> Attached is my config output and compile break. >>>>> >>>>> http://pastebin.com/W6UHn4Lc >>>>> >>>>> So should i still install misdn even though its not used. >>>>> >>>>> Rgds >>>>> Nik >>>>> >>>>> >>>>> On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg < >>>>> andreas at eversberg.eu> wrote: >>>>> >>>>>> Alexander Chemeris wrote: >>>>>> > Does it mean that that now we can use LCR with other SIP >>>>>> > softswitches/PBX'es, like Freeswitch? I do not follow LCR >>>>>> development >>>>>> > closely, but that would be a very interesting development. >>>>>> > >>>>>> yes, this was my intention. gsm and sip interface of lcr will not rely >>>>>> on misdn anymore. currently i don't support audio transfer via >>>>>> chan_lcr, >>>>>> so chan_lcr will only work with isdn interfaces. the sip interface >>>>>> implementation has not much options, so it can only do sipmple >>>>>> point-to-point sip connections to a gateway or endpoint. >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Wed Mar 7 18:32:17 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 7 Mar 2012 22:32:17 +0400 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Nik, You could check whether this is PCMA or GSM-FR with RTP stream bitrate. Capture the stream with Wireshark and look at RTP payload size or use a voice call information dialog (Telephony->VoIP Calls). PCMA bitrate is 64kbit (often 160bytes per 20ms), while bitrate GSM-FR is 13.2kbit (usually 33bytes per 20ms). On Wed, Mar 7, 2012 at 21:36, Nik Pakar wrote: > It seems BSC is sending payload type GSM to LCR, but LCR send payload type > PCMA on the sip channel. > > 07.03.12 22:45:03.907 CH(69): New call ref LCR<->BSC ?callref new=0x80000029 > 07.03.12 22:45:03.907 CH(69): Codec negotiation LCR<->BSC ?bearer > capa='given by MS' ?speech version='AMR given' ignored='Not suitable for > LCR' version='5 given' ignored='Not supported by LCR' version='EFR given' > ignored='Not suitable for LCR' version='Full Rate given' version='Half Rate > given' ignored='Not suitable for LCR' > 07.03.12 22:45:03.908 CH(69): MNCC_SETUP_IND LCR<->BSC ?calling > number=07777201 imsi=413011492012312 ?dialing number=4290080001 > 07.03.12 22:45:03.908 CH(69): MNCC_LCHAN_MODIFY LCR<->BSC ?speech > version='Full Rate given' ?mode 0x01 > 07.03.12 22:45:03.908 CH(69): MNCC_CALL_PROC_REQ LCR<->BSC ?progress > coding=3 location=1 descr=8 > 07.03.12 22:45:03.908 CH(69): unknown LCR<->BSC > 07.03.12 22:45:03.908 CH(70): NEW handle ?handle new=0x8d65cc0 > 07.03.12 22:45:03.908 CH(70): INVITE ?from uri=sip:07777201 at 192.168.1.30 ?to > uri=sip:4290080001 at 192.168.1.25:4757 ?rtp ip=103.10.172.30 port=30026,30027 > payload=PCMA:8 > 07.03.12 22:45:03.930 CH(70): RESPOND ?respond value=183 > 07.03.12 22:45:03.930 CH(70): Payload received ?rtp payload=PCMA:8 > payload=telephone-event:101 > 07.03.12 22:45:13.117 CH(69): MNCC_DISC_IND LCR<->BSC ?cause coding=3 > location=0 value=16 > 07.03.12 22:45:13.148 CH(69): MNCC_REL_REQ LCR<->BSC > 07.03.12 22:45:13.148 CH(70): CANCEL ?cause value=16 > 07.03.12 22:45:13.169 CH(70): RESPOND ?respond value=487 > > > > On Wed, Mar 7, 2012 at 3:43 PM, Nik Pakar wrote: >> >> Hi Andreas, is the LCR actually transcoding gsm-fr to alaw towards sip >> side ? >> >> Rgds >> Nik >> >> >> On Wed, Mar 7, 2012 at 3:17 PM, Nik Pakar wrote: >>> >>> Hi Andreas, >>> >>> Call signalling all works fine right through out from NITB to LCR and out >>> on SIP. how ever im getting some strange media behaviour. >>> >>> My setup is, >>> >>> [MS]---[nano.BTS]---[NITB/LCR]----[SIP Softswitch] >>> >>> LCR is setup to bridge two interfaces, so what ever comes from gsm goes >>> to sip and what ever comes from sip goes to gsm. >>> >>> Now a test call from a mobile to mobile, should go all the way to the >>> softswitch and come back. >>> >>> All works fine in terms of signalling. >>> >>> But in media, LCR seems sending initial SDP to the softswitch as?PCMA:8 >>> not gsm FR. >>> >>> So softswitch expect the media as PCMA and not transcoding. >>> >>> Same if the call goes out from softswitch, still no medial as it think >>> incoming media from LCR is on PCMA. >>> >>> Any idea about this ? >>> >>> This is the LCR trace -? http://pastebin.com/5PNKYc5m >>> This is the sip trace from softswitch -? http://pastebin.com/cVtx1mFB >>> >>> Rgds >>> Nik >>> >>> >>> On Tue, Mar 6, 2012 at 3:38 PM, Nik Pakar wrote: >>>> >>>> Hi Andreas, got it working both ways now. Many thanks for nice work. >>>> >>>> I will now test it further with transcoding. >>>> >>>> And start on the documentation. >>>> >>>> Rgds >>>> Nik >>>> >>>> On Tue, Mar 6, 2012 at 12:51 PM, Nik Pakar wrote: >>>>> >>>>> Hi Andreas, i now have calls coming from external sip->LCR->gsm >>>>> >>>>> But still cant figure out the dial plan to send a call out on sip, >>>>> gsm->LCR->sip >>>>> >>>>> I tried, >>>>> >>>>> dialing=072333444 : extern interfaces=sip prefix=072333444 >>>>> >>>>> But on LCR trace it shows as below. I think im missing some thing small >>>>> here. Appreciate if you can give a little hint. >>>>> >>>>> Thanks >>>>> nik >>>>> >>>>> 06.03.12 12:40:41.286 EP(1): ACTION (match) ?action goto ?line 11 >>>>> 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ?ruleset >>>>> extern ?dialing 072333444 >>>>> 06.03.12 12:40:41.286 EP(1): ACTION (match) ?action extern ?line 28 >>>>> 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) ?number 072333444 >>>>> ?interfaces sip >>>>> 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE ?to CH(1) >>>>> 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given interface) >>>>> ?interface sip >>>>> 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) ?interface?@ >>>>> 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) >>>>> 06.03.12 12:40:41.287 EP(1): TONE ?to CH(1) ?directory default ?name >>>>> cause_22 >>>>> 06.03.12 12:40:41.287 EP(1): DISCONNECT ?to CH(1) ?cause value=34 >>>>> location=1-Local-PBX >>>>> 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC ?progress coding=3 >>>>> location=1 descr=8 ?cause coding=3 location=1 value=34 >>>>> 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC ?cause coding=3 >>>>> location=0 value=16 >>>>> 06.03.12 12:40:56.247 EP(1): RELEASE ?from CH(1) ?cause value=16 >>>>> location=0-User >>>>> 06.03.12 12:40:56.247 EP(1): ACTION hangup >>>>> >>>>> >>>>> On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar wrote: >>>>>> >>>>>> Hi Andreas, >>>>>> >>>>>> It was apperently compiled on my debian while i had misdn libs >>>>>> isntalled. Now im trying on a fresh debian from the same set of sources >>>>>> which i got it working and without misdn, it fails to compile gsm. >>>>>> >>>>>> Attached is my config output and compile break. >>>>>> >>>>>> http://pastebin.com/W6UHn4Lc >>>>>> >>>>>> So should i still install misdn even though its not used. >>>>>> >>>>>> Rgds >>>>>> Nik >>>>>> >>>>>> >>>>>> On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg >>>>>> wrote: >>>>>>> >>>>>>> Alexander Chemeris wrote: >>>>>>> > Does it mean that that now we can use LCR with other SIP >>>>>>> > softswitches/PBX'es, like Freeswitch? I do not follow LCR >>>>>>> > development >>>>>>> > closely, but that would be a very interesting development. >>>>>>> > >>>>>>> yes, this was my intention. gsm and sip interface of lcr will not >>>>>>> rely >>>>>>> on misdn anymore. currently i don't support audio transfer via >>>>>>> chan_lcr, >>>>>>> so chan_lcr will only work with isdn interfaces. the sip interface >>>>>>> implementation has not much options, so it can only do sipmple >>>>>>> point-to-point sip connections to a gateway or endpoint. >>>>>> >>>>>> >>>>> >>>> >>> >> > -- Regards, Alexander Chemeris. From nikpakar at gmail.com Wed Mar 7 22:31:45 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Wed, 7 Mar 2012 22:31:45 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: Hi Alexander, I will check that tomorrow and update. But the problem here is LCR get GSM-FR from MNCC and forward SDP as PCMA on SIP. So it will confuse the softswitch as it see the stream as PCMA even it comes on FR. and if its actually PCMA, then LCR must have transcode it. Either way no audio once call connected. On openbsc console i see some warning on lchan with no rtp. Rgds Nik On Wed, Mar 7, 2012 at 6:32 PM, Alexander Chemeris < alexander.chemeris at gmail.com> wrote: > Nik, > > You could check whether this is PCMA or GSM-FR with RTP stream > bitrate. Capture the stream with Wireshark and look at RTP payload > size or use a voice call information dialog (Telephony->VoIP Calls). > PCMA bitrate is 64kbit (often 160bytes per 20ms), while bitrate GSM-FR > is 13.2kbit (usually 33bytes per 20ms). > > On Wed, Mar 7, 2012 at 21:36, Nik Pakar wrote: > > It seems BSC is sending payload type GSM to LCR, but LCR send payload > type > > PCMA on the sip channel. > > > > 07.03.12 22:45:03.907 CH(69): New call ref LCR<->BSC callref > new=0x80000029 > > 07.03.12 22:45:03.907 CH(69): Codec negotiation LCR<->BSC bearer > > capa='given by MS' speech version='AMR given' ignored='Not suitable for > > LCR' version='5 given' ignored='Not supported by LCR' version='EFR given' > > ignored='Not suitable for LCR' version='Full Rate given' version='Half > Rate > > given' ignored='Not suitable for LCR' > > 07.03.12 22:45:03.908 CH(69): MNCC_SETUP_IND LCR<->BSC calling > > number=07777201 imsi=413011492012312 dialing number=4290080001 > > 07.03.12 22:45:03.908 CH(69): MNCC_LCHAN_MODIFY LCR<->BSC speech > > version='Full Rate given' mode 0x01 > > 07.03.12 22:45:03.908 CH(69): MNCC_CALL_PROC_REQ LCR<->BSC progress > > coding=3 location=1 descr=8 > > 07.03.12 22:45:03.908 CH(69): unknown LCR<->BSC > > 07.03.12 22:45:03.908 CH(70): NEW handle handle new=0x8d65cc0 > > 07.03.12 22:45:03.908 CH(70): INVITE from uri=sip:07777201 at 192.168.1.30 to > > uri=sip:4290080001 at 192.168.1.25:4757 rtp ip=103.10.172.30 > port=30026,30027 > > payload=PCMA:8 > > 07.03.12 22:45:03.930 CH(70): RESPOND respond value=183 > > 07.03.12 22:45:03.930 CH(70): Payload received rtp payload=PCMA:8 > > payload=telephone-event:101 > > 07.03.12 22:45:13.117 CH(69): MNCC_DISC_IND LCR<->BSC cause coding=3 > > location=0 value=16 > > 07.03.12 22:45:13.148 CH(69): MNCC_REL_REQ LCR<->BSC > > 07.03.12 22:45:13.148 CH(70): CANCEL cause value=16 > > 07.03.12 22:45:13.169 CH(70): RESPOND respond value=487 > > > > > > > > On Wed, Mar 7, 2012 at 3:43 PM, Nik Pakar wrote: > >> > >> Hi Andreas, is the LCR actually transcoding gsm-fr to alaw towards sip > >> side ? > >> > >> Rgds > >> Nik > >> > >> > >> On Wed, Mar 7, 2012 at 3:17 PM, Nik Pakar wrote: > >>> > >>> Hi Andreas, > >>> > >>> Call signalling all works fine right through out from NITB to LCR and > out > >>> on SIP. how ever im getting some strange media behaviour. > >>> > >>> My setup is, > >>> > >>> [MS]---[nano.BTS]---[NITB/LCR]----[SIP Softswitch] > >>> > >>> LCR is setup to bridge two interfaces, so what ever comes from gsm goes > >>> to sip and what ever comes from sip goes to gsm. > >>> > >>> Now a test call from a mobile to mobile, should go all the way to the > >>> softswitch and come back. > >>> > >>> All works fine in terms of signalling. > >>> > >>> But in media, LCR seems sending initial SDP to the softswitch as PCMA:8 > >>> not gsm FR. > >>> > >>> So softswitch expect the media as PCMA and not transcoding. > >>> > >>> Same if the call goes out from softswitch, still no medial as it think > >>> incoming media from LCR is on PCMA. > >>> > >>> Any idea about this ? > >>> > >>> This is the LCR trace - http://pastebin.com/5PNKYc5m > >>> This is the sip trace from softswitch - http://pastebin.com/cVtx1mFB > >>> > >>> Rgds > >>> Nik > >>> > >>> > >>> On Tue, Mar 6, 2012 at 3:38 PM, Nik Pakar wrote: > >>>> > >>>> Hi Andreas, got it working both ways now. Many thanks for nice work. > >>>> > >>>> I will now test it further with transcoding. > >>>> > >>>> And start on the documentation. > >>>> > >>>> Rgds > >>>> Nik > >>>> > >>>> On Tue, Mar 6, 2012 at 12:51 PM, Nik Pakar > wrote: > >>>>> > >>>>> Hi Andreas, i now have calls coming from external sip->LCR->gsm > >>>>> > >>>>> But still cant figure out the dial plan to send a call out on sip, > >>>>> gsm->LCR->sip > >>>>> > >>>>> I tried, > >>>>> > >>>>> dialing=072333444 : extern interfaces=sip prefix=072333444 > >>>>> > >>>>> But on LCR trace it shows as below. I think im missing some thing > small > >>>>> here. Appreciate if you can give a little hint. > >>>>> > >>>>> Thanks > >>>>> nik > >>>>> > >>>>> 06.03.12 12:40:41.286 EP(1): ACTION (match) action goto line 11 > >>>>> 06.03.12 12:40:41.286 EP(1): ACTION goto/menu (change to) ruleset > >>>>> extern dialing 072333444 > >>>>> 06.03.12 12:40:41.286 EP(1): ACTION (match) action extern line 28 > >>>>> 06.03.12 12:40:41.286 EP(1): ACTION extern (calling) number > 072333444 > >>>>> interfaces sip > >>>>> 06.03.12 12:40:41.287 EP(1): SETUP ACKNOWLEDGE to CH(1) > >>>>> 06.03.12 12:40:41.287 EP(2): CHANNEL SELECTION (found given > interface) > >>>>> interface sip > >>>>> 06.03.12 12:40:41.287 EP(2): INTERFACE (has no function) interface?@ > >>>>> 06.03.12 12:40:41.287 EP(2): INTERFACE (no free ports found) > >>>>> 06.03.12 12:40:41.287 EP(1): TONE to CH(1) directory default name > >>>>> cause_22 > >>>>> 06.03.12 12:40:41.287 EP(1): DISCONNECT to CH(1) cause value=34 > >>>>> location=1-Local-PBX > >>>>> 06.03.12 12:40:41.287 CH(1): MNCC_DISC_REQ LCR<->BSC progress > coding=3 > >>>>> location=1 descr=8 cause coding=3 location=1 value=34 > >>>>> 06.03.12 12:40:56.246 CH(1): MNCC_REL_IND LCR<->BSC cause coding=3 > >>>>> location=0 value=16 > >>>>> 06.03.12 12:40:56.247 EP(1): RELEASE from CH(1) cause value=16 > >>>>> location=0-User > >>>>> 06.03.12 12:40:56.247 EP(1): ACTION hangup > >>>>> > >>>>> > >>>>> On Tue, Mar 6, 2012 at 7:44 AM, Nik Pakar > wrote: > >>>>>> > >>>>>> Hi Andreas, > >>>>>> > >>>>>> It was apperently compiled on my debian while i had misdn libs > >>>>>> isntalled. Now im trying on a fresh debian from the same set of > sources > >>>>>> which i got it working and without misdn, it fails to compile gsm. > >>>>>> > >>>>>> Attached is my config output and compile break. > >>>>>> > >>>>>> http://pastebin.com/W6UHn4Lc > >>>>>> > >>>>>> So should i still install misdn even though its not used. > >>>>>> > >>>>>> Rgds > >>>>>> Nik > >>>>>> > >>>>>> > >>>>>> On Mon, Mar 5, 2012 at 10:05 AM, Andreas Eversberg > >>>>>> wrote: > >>>>>>> > >>>>>>> Alexander Chemeris wrote: > >>>>>>> > Does it mean that that now we can use LCR with other SIP > >>>>>>> > softswitches/PBX'es, like Freeswitch? I do not follow LCR > >>>>>>> > development > >>>>>>> > closely, but that would be a very interesting development. > >>>>>>> > > >>>>>>> yes, this was my intention. gsm and sip interface of lcr will not > >>>>>>> rely > >>>>>>> on misdn anymore. currently i don't support audio transfer via > >>>>>>> chan_lcr, > >>>>>>> so chan_lcr will only work with isdn interfaces. the sip interface > >>>>>>> implementation has not much options, so it can only do sipmple > >>>>>>> point-to-point sip connections to a gateway or endpoint. > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > > > -- > Regards, > Alexander Chemeris. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Thu Mar 8 08:09:24 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 08 Mar 2012 09:09:24 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> Message-ID: <4F586934.2070305@eversberg.eu> hi nik, since lcr uses alaw (optionally ulaw) internally, it transcodes the audio between alaw and gsm full rate. alternatively you can bridge rtp directly between freeswitch and openbsc, if you use the "bridge " feature at interface.conf. additionally you need to add a line "rtp-bridge" to your interface definition. this rtp-bridge feature only works with the bridge feature, since lcr will not be able to handle audio streams then. since it is still developed, you need to use the "jolly/rtpmux" branch of openbsc. then it will only offer the codec to freeswitch which the phone supports. on the other direction, lcr selects the commonly supported codec. if more codecs are supported, the upper most (prefered) is used. anyway it should work in both cases. (with and without rtp-bridge feature) regards, andreas From nikpakar at gmail.com Thu Mar 8 10:18:46 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 8 Mar 2012 10:18:46 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: <4F586934.2070305@eversberg.eu> References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> <4F586934.2070305@eversberg.eu> Message-ID: Thank you very andreas, for the help and nice integration work. Im going to try this branch now. Is it only this patch to be applied to the rtp_proxy.c for the git clone i have from openbsc ? http://cgit.osmocom.org/cgit/openbsc/commit/?h=jolly/rtpmux On Thu, Mar 8, 2012 at 8:09 AM, jolly wrote: > hi nik, > > since lcr uses alaw (optionally ulaw) internally, it transcodes the > audio between alaw and gsm full rate. > > alternatively you can bridge rtp directly between freeswitch and > openbsc, if you use the "bridge " feature at interface.conf. > additionally you need to add a line "rtp-bridge" to your interface > definition. this rtp-bridge feature only works with the bridge feature, > since lcr will not be able to handle audio streams then. since it is > still developed, you need to use the "jolly/rtpmux" branch of openbsc. > then it will only offer the codec to freeswitch which the phone > supports. on the other direction, lcr selects the commonly supported > codec. if more codecs are supported, the upper most (prefered) is used. > > anyway it should work in both cases. (with and without rtp-bridge feature) > > regards, > > andreas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Thu Mar 8 14:07:09 2012 From: andreas at eversberg.eu (jolly) Date: Thu, 08 Mar 2012 15:07:09 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> <4F586934.2070305@eversberg.eu> Message-ID: <4F58BD0D.60207@eversberg.eu> > > Is it only this patch to be applied to the rtp_proxy.c for the git > clone i have from openbsc ? no, you need most of this branch, because the patch affects the mncc-interface between openbsc and lcr, too. From nikpakar at gmail.com Thu Mar 8 14:25:32 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 8 Mar 2012 14:25:32 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: <4F58BD0D.60207@eversberg.eu> References: <4F546EE8.8020901@eversberg.eu> <4F548FD0.8020603@eversberg.eu> <4F586934.2070305@eversberg.eu> <4F58BD0D.60207@eversberg.eu> Message-ID: Thanks andreas, Im bit new on GIT, thats why asked. I tried git checkout jolly/rtpmux from the openbsc clone directory but i didnt seems synced with the jolly/rtpmux branch. Would you mind give me a little hint on how to clone the rtpmux branch. Thanks and sorry for basic question on git. Rgds Nik On Thu, Mar 8, 2012 at 2:07 PM, jolly wrote: > > > > Is it only this patch to be applied to the rtp_proxy.c for the git > > clone i have from openbsc ? > no, you need most of this branch, because the patch affects the > mncc-interface between openbsc and lcr, too. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Thu Mar 8 15:03:08 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 8 Mar 2012 16:03:08 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F586934.2070305@eversberg.eu> <4F58BD0D.60207@eversberg.eu> Message-ID: <20120308150308.20367.qmail@stuge.se> Nik Pakar wrote: > Would you mind give me a little hint on how to clone the rtpmux branch. > > Thanks and sorry for basic question on git. When you know that you need to apologize you obviously know that you are asking a question that you are not supposed to be asking (here) in the first place. Study the tools! There is amazing material about Git online so you have absolutely no excuse for not trying much harder on your own to accomplish what you are obviously getting paid a lot of money to do. Did you already look around, or are you asking (i.e. expecting) others to help you without trying to find the answer on your own? That is quite unacceptable and will make people hate you, because as you know everyone is very busy with other things than educating you about git. I think you understand this. I strongly recommend http://progit.org/book/ which has very good coverage of git, and is easy to read. You can't expect any success whatsoever in a project where you are new to the development tools, if you aren't willing, eager and able to learn those tools. You will just make people angry in general and angry with you in particular. You must understand that open source communities are a completely different social construct than what you may be used to from commercial customer/supplier relationships. Your behavior on this mailing list (and apparently others) is as if the open source community was a commercial supplier to you and you are rapidly making one faux-pas after another, which naturally results in an incredibly bad standing for you within the community. If you are going to be successful in using an open source component then you must change your mindset and become a part of the community. The only way to do that, really, is to contribute something. //Peter From nikpakar at gmail.com Mon Mar 5 10:19:17 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Mon, 5 Mar 2012 10:19:17 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: <4F546EE8.8020901@eversberg.eu> References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hi Andreas, thousand times thanks for the correct hint. Its indeed crystal clear now. I have tried the git clone from git://git.osmocom.org/openbsc.git but noticed there is still misdn requirement and also no sip support. Then found from the maillist that i should clone git://git.osmocom.eu/openbsc.git instead of .org which shows sip interfaces on the source. How ever there is no configure file on this source. Am i still checking out from the wrong git ? Once again highly appreciate some light on the final bit. Thanks Nik On Mon, Mar 5, 2012 at 7:44 AM, jolly wrote: > > Do I have to have mISDN for LCR even im not going to use any isdn > > interface ? Im trying to connect the NITB to LCR and LCR to asterisk > > all on ip. > > > > Thanks for any help. > > > > Rgds > > Nik > hi nik, > > you don't need misdn to use lcr with sip and gsm anymore. also you don't > need any patch. the lcr and openbsc compile out of the box supporting > each other. the howto is a bit outdated. > > try to compile the lcr from the git. don't use chan_lcr, since it still > works with isdn only. you need to setup a sip interface in interface.conf: > > [sip] > sip [:] > sip 10.0.0.12 10.0.0.34 > earlyb no > tones no > > use asterisk machine for remote ip. if you have asterisk on the same > machine, change the sip port of asterisk and use "remoteip:port". > > regards, > > andreas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Mon Mar 5 10:23:35 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Mon, 5 Mar 2012 10:23:35 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hi Andreas, extreamlly sorry for the blind question. I didnt do autogen to create the configure. Extreamly sorry again. Rgds Nik On Mon, Mar 5, 2012 at 10:19 AM, Nik Pakar wrote: > Hi Andreas, thousand times thanks for the correct hint. > > Its indeed crystal clear now. > > I have tried the git clone from git://git.osmocom.org/openbsc.git but > noticed there is still misdn requirement and also no sip support. > > Then found from the maillist that i should clone > git://git.osmocom.eu/openbsc.git instead of .org which shows sip > interfaces on the source. > > How ever there is no configure file on this source. > > Am i still checking out from the wrong git ? > > Once again highly appreciate some light on the final bit. > > Thanks > Nik > > > On Mon, Mar 5, 2012 at 7:44 AM, jolly wrote: > >> > Do I have to have mISDN for LCR even im not going to use any isdn >> > interface ? Im trying to connect the NITB to LCR and LCR to asterisk >> > all on ip. >> > >> > Thanks for any help. >> > >> > Rgds >> > Nik >> hi nik, >> >> you don't need misdn to use lcr with sip and gsm anymore. also you don't >> need any patch. the lcr and openbsc compile out of the box supporting >> each other. the howto is a bit outdated. >> >> try to compile the lcr from the git. don't use chan_lcr, since it still >> works with isdn only. you need to setup a sip interface in interface.conf: >> >> [sip] >> sip [:] >> sip 10.0.0.12 10.0.0.34 >> earlyb no >> tones no >> >> use asterisk machine for remote ip. if you have asterisk on the same >> machine, change the sip port of asterisk and use "remoteip:port". >> >> regards, >> >> andreas >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Mon Mar 5 11:39:28 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Mon, 5 Mar 2012 11:39:28 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hi Andreas, Every thing works fine. Just one last question. I cant find any sample dialplan option towards gsm and sip interface. tried quite a few didnt worked. Appreciate if you can just give the last hint how would the dial plan should looks like towards gsm and sip. Thanks again. Nik On Mon, Mar 5, 2012 at 10:23 AM, Nik Pakar wrote: > Hi Andreas, extreamlly sorry for the blind question. > > I didnt do autogen to create the configure. > > Extreamly sorry again. > > Rgds > Nik > > > On Mon, Mar 5, 2012 at 10:19 AM, Nik Pakar wrote: > >> Hi Andreas, thousand times thanks for the correct hint. >> >> Its indeed crystal clear now. >> >> I have tried the git clone from git://git.osmocom.org/openbsc.git but >> noticed there is still misdn requirement and also no sip support. >> >> Then found from the maillist that i should clone >> git://git.osmocom.eu/openbsc.git instead of .org which shows sip >> interfaces on the source. >> >> How ever there is no configure file on this source. >> >> Am i still checking out from the wrong git ? >> >> Once again highly appreciate some light on the final bit. >> >> Thanks >> Nik >> >> >> On Mon, Mar 5, 2012 at 7:44 AM, jolly wrote: >> >>> > Do I have to have mISDN for LCR even im not going to use any isdn >>> > interface ? Im trying to connect the NITB to LCR and LCR to asterisk >>> > all on ip. >>> > >>> > Thanks for any help. >>> > >>> > Rgds >>> > Nik >>> hi nik, >>> >>> you don't need misdn to use lcr with sip and gsm anymore. also you don't >>> need any patch. the lcr and openbsc compile out of the box supporting >>> each other. the howto is a bit outdated. >>> >>> try to compile the lcr from the git. don't use chan_lcr, since it still >>> works with isdn only. you need to setup a sip interface in >>> interface.conf: >>> >>> [sip] >>> sip [:] >>> sip 10.0.0.12 10.0.0.34 >>> earlyb no >>> tones no >>> >>> use asterisk machine for remote ip. if you have asterisk on the same >>> machine, change the sip port of asterisk and use "remoteip:port". >>> >>> regards, >>> >>> andreas >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carcellelist at free.fr Mon Mar 5 13:10:53 2012 From: carcellelist at free.fr (carcelle) Date: Mon, 5 Mar 2012 14:10:53 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: <20120305131053.GQ10919@massoud> Dear Nik, i am trying to finalize the build of lcr w/ gsm/sip support *latest lcr version (in /usr/src/lcr) *latest openbsc version (in /usr/src/openbsc/openbsc) *./configure --prefix=/usr/src/lcr/ --with-gsm-bs --with-sip works ok (with libsofia-sip-ua-dev and libncurses5-dev) *make does break gsm_audio.c:20: error: 'gsm' was not expected in this scope Can you tell what option you gave to configure and how did you organize your dirs ? My best, Xavier. On Mon, Mar 05, 2012 at 11:39:28AM +0000, Nik Pakar wrote: > Hi Andreas, > > Every thing works fine. > > Just one last question. I cant find any sample dialplan option towards gsm > and sip interface. tried quite a few didnt worked. > > Appreciate if you can just give the last hint how would the dial plan > should looks like towards gsm and sip. > > Thanks again. > Nik > > On Mon, Mar 5, 2012 at 10:23 AM, Nik Pakar wrote: > > > Hi Andreas, extreamlly sorry for the blind question. > > > > I didnt do autogen to create the configure. > > > > Extreamly sorry again. > > > > Rgds > > Nik > > > > > > On Mon, Mar 5, 2012 at 10:19 AM, Nik Pakar wrote: > > > >> Hi Andreas, thousand times thanks for the correct hint. > >> > >> Its indeed crystal clear now. > >> > >> I have tried the git clone from git://git.osmocom.org/openbsc.git but > >> noticed there is still misdn requirement and also no sip support. > >> > >> Then found from the maillist that i should clone > >> git://git.osmocom.eu/openbsc.git instead of .org which shows sip > >> interfaces on the source. > >> > >> How ever there is no configure file on this source. > >> > >> Am i still checking out from the wrong git ? > >> > >> Once again highly appreciate some light on the final bit. > >> > >> Thanks > >> Nik > >> > >> > >> On Mon, Mar 5, 2012 at 7:44 AM, jolly wrote: > >> > >>> > Do I have to have mISDN for LCR even im not going to use any isdn > >>> > interface ? Im trying to connect the NITB to LCR and LCR to asterisk > >>> > all on ip. > >>> > > >>> > Thanks for any help. > >>> > > >>> > Rgds > >>> > Nik > >>> hi nik, > >>> > >>> you don't need misdn to use lcr with sip and gsm anymore. also you don't > >>> need any patch. the lcr and openbsc compile out of the box supporting > >>> each other. the howto is a bit outdated. > >>> > >>> try to compile the lcr from the git. don't use chan_lcr, since it still > >>> works with isdn only. you need to setup a sip interface in > >>> interface.conf: > >>> > >>> [sip] > >>> sip [:] > >>> sip 10.0.0.12 10.0.0.34 > >>> earlyb no > >>> tones no > >>> > >>> use asterisk machine for remote ip. if you have asterisk on the same > >>> machine, change the sip port of asterisk and use "remoteip:port". > >>> > >>> regards, > >>> > >>> andreas > >>> > >>> > >>> > >> > > From nikpakar at gmail.com Mon Mar 5 13:25:57 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Mon, 5 Mar 2012 13:25:57 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: <20120305131053.GQ10919@massoud> References: <4F546EE8.8020901@eversberg.eu> <20120305131053.GQ10919@massoud> Message-ID: Did you install libgsm ? Im in the last bit of getting it done. Once all done i will redo a documentation. On Mon, Mar 5, 2012 at 1:10 PM, carcelle wrote: > Dear Nik, > > i am trying to finalize the build of lcr w/ gsm/sip support > > *latest lcr version (in /usr/src/lcr) > *latest openbsc version (in /usr/src/openbsc/openbsc) > *./configure --prefix=/usr/src/lcr/ --with-gsm-bs --with-sip > works ok (with libsofia-sip-ua-dev and libncurses5-dev) > *make does break > gsm_audio.c:20: error: 'gsm' was not expected in this scope > > Can you tell what option you gave to configure and how did you organize > your > dirs ? > > My best, > > Xavier. > > On Mon, Mar 05, 2012 at 11:39:28AM +0000, Nik Pakar wrote: > > Hi Andreas, > > > > Every thing works fine. > > > > Just one last question. I cant find any sample dialplan option towards > gsm > > and sip interface. tried quite a few didnt worked. > > > > Appreciate if you can just give the last hint how would the dial plan > > should looks like towards gsm and sip. > > > > Thanks again. > > Nik > > > > On Mon, Mar 5, 2012 at 10:23 AM, Nik Pakar wrote: > > > > > Hi Andreas, extreamlly sorry for the blind question. > > > > > > I didnt do autogen to create the configure. > > > > > > Extreamly sorry again. > > > > > > Rgds > > > Nik > > > > > > > > > On Mon, Mar 5, 2012 at 10:19 AM, Nik Pakar wrote: > > > > > >> Hi Andreas, thousand times thanks for the correct hint. > > >> > > >> Its indeed crystal clear now. > > >> > > >> I have tried the git clone from git://git.osmocom.org/openbsc.git but > > >> noticed there is still misdn requirement and also no sip support. > > >> > > >> Then found from the maillist that i should clone > > >> git://git.osmocom.eu/openbsc.git instead of .org which shows sip > > >> interfaces on the source. > > >> > > >> How ever there is no configure file on this source. > > >> > > >> Am i still checking out from the wrong git ? > > >> > > >> Once again highly appreciate some light on the final bit. > > >> > > >> Thanks > > >> Nik > > >> > > >> > > >> On Mon, Mar 5, 2012 at 7:44 AM, jolly wrote: > > >> > > >>> > Do I have to have mISDN for LCR even im not going to use any isdn > > >>> > interface ? Im trying to connect the NITB to LCR and LCR to > asterisk > > >>> > all on ip. > > >>> > > > >>> > Thanks for any help. > > >>> > > > >>> > Rgds > > >>> > Nik > > >>> hi nik, > > >>> > > >>> you don't need misdn to use lcr with sip and gsm anymore. also you > don't > > >>> need any patch. the lcr and openbsc compile out of the box supporting > > >>> each other. the howto is a bit outdated. > > >>> > > >>> try to compile the lcr from the git. don't use chan_lcr, since it > still > > >>> works with isdn only. you need to setup a sip interface in > > >>> interface.conf: > > >>> > > >>> [sip] > > >>> sip [:] > > >>> sip 10.0.0.12 10.0.0.34 > > >>> earlyb no > > >>> tones no > > >>> > > >>> use asterisk machine for remote ip. if you have asterisk on the same > > >>> machine, change the sip port of asterisk and use "remoteip:port". > > >>> > > >>> regards, > > >>> > > >>> andreas > > >>> > > >>> > > >>> > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Mon Mar 5 14:59:41 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Mon, 5 Mar 2012 14:59:41 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hi Andreas, searched out every possible place to look for a sample routing expression for sofia and for gsm interfaces. But couldnt found any. Would highly appreciate if you can shed little light on that. Thanks nik On Mon, Mar 5, 2012 at 11:39 AM, Nik Pakar wrote: > Hi Andreas, > > Every thing works fine. > > Just one last question. I cant find any sample dialplan option towards gsm > and sip interface. tried quite a few didnt worked. > > Appreciate if you can just give the last hint how would the dial plan > should looks like towards gsm and sip. > > Thanks again. > Nik > > On Mon, Mar 5, 2012 at 10:23 AM, Nik Pakar wrote: > >> Hi Andreas, extreamlly sorry for the blind question. >> >> I didnt do autogen to create the configure. >> >> Extreamly sorry again. >> >> Rgds >> Nik >> >> >> On Mon, Mar 5, 2012 at 10:19 AM, Nik Pakar wrote: >> >>> Hi Andreas, thousand times thanks for the correct hint. >>> >>> Its indeed crystal clear now. >>> >>> I have tried the git clone from git://git.osmocom.org/openbsc.git but >>> noticed there is still misdn requirement and also no sip support. >>> >>> Then found from the maillist that i should clone >>> git://git.osmocom.eu/openbsc.git instead of .org which shows sip >>> interfaces on the source. >>> >>> How ever there is no configure file on this source. >>> >>> Am i still checking out from the wrong git ? >>> >>> Once again highly appreciate some light on the final bit. >>> >>> Thanks >>> Nik >>> >>> >>> On Mon, Mar 5, 2012 at 7:44 AM, jolly wrote: >>> >>>> > Do I have to have mISDN for LCR even im not going to use any isdn >>>> > interface ? Im trying to connect the NITB to LCR and LCR to asterisk >>>> > all on ip. >>>> > >>>> > Thanks for any help. >>>> > >>>> > Rgds >>>> > Nik >>>> hi nik, >>>> >>>> you don't need misdn to use lcr with sip and gsm anymore. also you don't >>>> need any patch. the lcr and openbsc compile out of the box supporting >>>> each other. the howto is a bit outdated. >>>> >>>> try to compile the lcr from the git. don't use chan_lcr, since it still >>>> works with isdn only. you need to setup a sip interface in >>>> interface.conf: >>>> >>>> [sip] >>>> sip [:] >>>> sip 10.0.0.12 10.0.0.34 >>>> earlyb no >>>> tones no >>>> >>>> use asterisk machine for remote ip. if you have asterisk on the same >>>> machine, change the sip port of asterisk and use "remoteip:port". >>>> >>>> regards, >>>> >>>> andreas >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon Mar 5 15:36:31 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 Mar 2012 16:36:31 +0100 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: <20120305153631.3467.qmail@stuge.se> Nik Pakar wrote: > searched out every possible place to look for a sample routing > expression for sofia and for gsm interfaces. But couldnt found any. Wrong approach. You can not depend on examples and help from others to accomplish what you want to do. You must understand that YOU must do the job. YOU must learn how to create the routing that YOU need. > Would highly appreciate if you can shed little light on that. I recommend that you look at the source code to learn how to control routing. That may not be the kind of documentation you are used to, but you can on the other hand know with certainty that what you learn will be relevant for the running code. After you have gained this understanding, I strongly recommend that you then immediately STOP and create documentation for the benefit of others, so that they do not have to spend as much time as you on learning the neccessary things. This is a good way to contribute back to a community which has spent many thousand hours on developing software which you can simply install in order to reach your goal, without any cost. //Peter From don at 00100100.net Wed Mar 14 04:20:24 2012 From: don at 00100100.net (Don Fanning) Date: Tue, 13 Mar 2012 21:20:24 -0700 Subject: Compiling LCR for OpenBSC In-Reply-To: <4F546EE8.8020901@eversberg.eu> References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hello Andreas, What changes need to be done in routing.conf to use pipe via SIP instead of chan_lcr? Thanks, -Don On Sun, Mar 4, 2012 at 11:44 PM, jolly wrote: > > Do I have to have mISDN for LCR even im not going to use any isdn > > interface ? Im trying to connect the NITB to LCR and LCR to asterisk > > all on ip. > > > > Thanks for any help. > > > > Rgds > > Nik > hi nik, > > you don't need misdn to use lcr with sip and gsm anymore. also you don't > need any patch. the lcr and openbsc compile out of the box supporting > each other. the howto is a bit outdated. > > try to compile the lcr from the git. don't use chan_lcr, since it still > works with isdn only. you need to setup a sip interface in interface.conf: > > [sip] > sip [:] > sip 10.0.0.12 10.0.0.34 > earlyb no > tones no > > use asterisk machine for remote ip. if you have asterisk on the same > machine, change the sip port of asterisk and use "remoteip:port". > > regards, > > andreas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Thu Mar 15 12:33:40 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 15 Mar 2012 12:33:40 +0000 Subject: Compiling LCR for OpenBSC In-Reply-To: References: <4F546EE8.8020901@eversberg.eu> Message-ID: Hi Don, You can use interface bridge option on interface.conf, so no need of any routing. sip and gsm interfaces will be bridged and calls coming on one interface will route to the other. Just use bridge sip on interace gsm and bridge gsm interface sip. Rgds Nik On Wed, Mar 14, 2012 at 4:20 AM, Don Fanning wrote: > Hello Andreas, > > What changes need to be done in routing.conf to use pipe via SIP instead > of chan_lcr? > > Thanks, > -Don > > > On Sun, Mar 4, 2012 at 11:44 PM, jolly wrote: > >> > Do I have to have mISDN for LCR even im not going to use any isdn >> > interface ? Im trying to connect the NITB to LCR and LCR to asterisk >> > all on ip. >> > >> > Thanks for any help. >> > >> > Rgds >> > Nik >> hi nik, >> >> you don't need misdn to use lcr with sip and gsm anymore. also you don't >> need any patch. the lcr and openbsc compile out of the box supporting >> each other. the howto is a bit outdated. >> >> try to compile the lcr from the git. don't use chan_lcr, since it still >> works with isdn only. you need to setup a sip interface in interface.conf: >> >> [sip] >> sip [:] >> sip 10.0.0.12 10.0.0.34 >> earlyb no >> tones no >> >> use asterisk machine for remote ip. if you have asterisk on the same >> machine, change the sip port of asterisk and use "remoteip:port". >> >> regards, >> >> andreas >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Sat Mar 3 21:17:16 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 21:17:16 +0000 Subject: BSC_MGCP Message-ID: Dear all, Is this BSC_MGCP is functioning ? Is that mean Open_BSC can be act as a MGCP gateway and can control from a MGCP_CA ? Rgds Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sat Mar 3 21:24:10 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sat, 03 Mar 2012 22:24:10 +0100 Subject: BSC_MGCP In-Reply-To: References: Message-ID: <4F528BFA.6080908@freyther.de> On 03/03/2012 10:17 PM, Nik Pakar wrote: > Dear all, Is this BSC_MGCP is functioning ? > > Is that mean Open_BSC can be act as a MGCP gateway and can control from a > MGCP_CA ? Hi, it is a MGCP Gateway and a CA can allocate endpoints. Currently the BSC and the MGCP GW share a secret (config setting) of where the BTS is asked to send RTP packages too. holger PS: Maybe you want to re-introduce yourself to this group and share what you plan to do. :) From nikpakar at gmail.com Sat Mar 3 21:58:59 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 21:58:59 +0000 Subject: BSC_MGCP In-Reply-To: <4F528BFA.6080908@freyther.de> References: <4F528BFA.6080908@freyther.de> Message-ID: Hi Holger, Many thanks for your reply. Im trying to implement a scalable nanoGSM platform which i can have 100s of nano.BTSs connecting to multiple OpenBSCs/NITBs. This is where i was trying below two options. 1. To get the calls routed in/out from and to NITB 2. Unbundle HLR DB to a central mysql db so all NITBs can talk to that common HLR and possibly a basic central GMSC (sip/mgcp only) can lookup the HLR and route calls to them accordingly. But so far i have failed to get this no.1 done using LCR/asterisk option. So pretty much given up with that. Thats why trying alternatives now. Coming back to MGCP, is this mainly to be used in BSC only mode where MSC server will have SCCP/A with BSC and use MGCP for media ? Or can a NITB act as a MGCP GW while NITB does full msc/hlr/vlr functions and use MGCP to send and receive calls to a MGCP_CA ? Many thanks for all your help. Its a great fantastic job OpenBSC team has done so far. Rgds Nik On Sat, Mar 3, 2012 at 9:24 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 03/03/2012 10:17 PM, Nik Pakar wrote: > > Dear all, Is this BSC_MGCP is functioning ? > > > > Is that mean Open_BSC can be act as a MGCP gateway and can control from a > > MGCP_CA ? > > Hi, > > it is a MGCP Gateway and a CA can allocate endpoints. Currently the BSC and > the MGCP GW share a secret (config setting) of where the BTS is asked to > send > RTP packages too. > > holger > > PS: Maybe you want to re-introduce yourself to this group and share what > you > plan to do. :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Sat Mar 3 23:37:21 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sat, 3 Mar 2012 23:37:21 +0000 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> Message-ID: Hi Holger, Sorry for repeat replies. I just came across this smalltalk implementation you have done for some other elements such as a MSC, HRL, etc., Would that be any use for what im trying to do here with OpenBSC. Thanks & Rgds Nik On Sat, Mar 3, 2012 at 9:58 PM, Nik Pakar wrote: > Hi Holger, > > Many thanks for your reply. > > Im trying to implement a scalable nanoGSM platform which i can have 100s > of nano.BTSs connecting to multiple OpenBSCs/NITBs. This is where i was > trying below two options. > > 1. To get the calls routed in/out from and to NITB > 2. Unbundle HLR DB to a central mysql db so all NITBs can talk to that > common HLR and possibly a basic central GMSC (sip/mgcp only) can lookup the > HLR and route calls to them accordingly. > > But so far i have failed to get this no.1 done using LCR/asterisk option. > So pretty much given up with that. > > Thats why trying alternatives now. > > Coming back to MGCP, is this mainly to be used in BSC only mode where MSC > server will have SCCP/A with BSC and use MGCP for media ? > > Or can a NITB act as a MGCP GW while NITB does full msc/hlr/vlr functions > and use MGCP to send and receive calls to a MGCP_CA ? > > Many thanks for all your help. Its a great fantastic job OpenBSC team has > done so far. > > Rgds > Nik > > > On Sat, Mar 3, 2012 at 9:24 PM, Holger Hans Peter Freyther < > holger at freyther.de> wrote: > >> On 03/03/2012 10:17 PM, Nik Pakar wrote: >> > Dear all, Is this BSC_MGCP is functioning ? >> > >> > Is that mean Open_BSC can be act as a MGCP gateway and can control from >> a >> > MGCP_CA ? >> >> Hi, >> >> it is a MGCP Gateway and a CA can allocate endpoints. Currently the BSC >> and >> the MGCP GW share a secret (config setting) of where the BTS is asked to >> send >> RTP packages too. >> >> holger >> >> PS: Maybe you want to re-introduce yourself to this group and share what >> you >> plan to do. :) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Mar 4 09:36:36 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 04 Mar 2012 10:36:36 +0100 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> Message-ID: <4F5337A4.1080001@freyther.de> On 03/03/2012 10:58 PM, Nik Pakar wrote: > Hi Holger, > > > But so far i have failed to get this no.1 done using LCR/asterisk option. So > pretty much given up with that. :) Hi Nik, we were using nitb/LCR for 27C3/28C3/Camp2012, I have also used LCR/Asterisk very recently for SIP callout. I think you should spend some more time to try to understand why it is failing for you. holger From nikpakar at gmail.com Sun Mar 4 10:26:12 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sun, 4 Mar 2012 10:26:12 +0000 Subject: BSC_MGCP In-Reply-To: <4F5337A4.1080001@freyther.de> References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> Message-ID: Thanks Holger, will give it another try. Would you be please kind enough to let me know whether it should work in below topology. [MS]---[nanoBTS]----[OpenBSC NITB]---(ip)---[LCR]---(ip)--- [Asterisk]----(sip)---> or would it need any E1/ISDN cards in between. Thanks again. Nik On Sun, Mar 4, 2012 at 9:36 AM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 03/03/2012 10:58 PM, Nik Pakar wrote: > > Hi Holger, > > > > > > > But so far i have failed to get this no.1 done using LCR/asterisk > option. So > > pretty much given up with that. > :) > > Hi Nik, > > we were using nitb/LCR for 27C3/28C3/Camp2012, I have also used > LCR/Asterisk > very recently for SIP callout. I think you should spend some more time to > try > to understand why it is failing for you. > > holger > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Sun Mar 4 18:01:00 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 4 Mar 2012 19:01:00 +0100 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> Message-ID: <20120304180100.10318.qmail@stuge.se> Nik Pakar wrote: > Would you be please kind enough to let me know whether it should > work in below topology. > > [MS]---[nanoBTS]----[OpenBSC NITB]---(ip)---[LCR]---(ip)--- > [Asterisk]----(sip)---> > > or would it need any E1/ISDN cards in between. I don't think either is completely true. Best to study the interfaces of the open source software components in detail. Note that since this is open source software and not a commercial product you have to educate yourself using what is available, and you may have to create your own documentation after you have. An alternative may be to buy training services, but if you plan to work on the project and to make it more scalable then I think it's a good idea to learn by doing. //Peter From nikpakar at gmail.com Sun Mar 4 18:21:18 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sun, 4 Mar 2012 18:21:18 +0000 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> Message-ID: Hi Holger, While im still trying this im trying to understand the interface between OpenBSC and LCR. Throughout the process there is no change to be done on the OpenBSC what so ever in order to make all MO calls to be go out on LCR and all calls from LCR to go into MT. Only the LCR is to be configured with a knowledge of BSC and asterisk. Can you give me a little hint on how openbsc would know about LCR and route all calls to the LCR in the presence of it. or is there any kind of socket application from LCR which opens up some thing on BSC which result calls been flow out from it. Sorry if im asking too much. Im just trying to see whether i can get done my own interface out from the BSC. Many many thanks for your feedback. Rgds Nik On Sun, Mar 4, 2012 at 10:26 AM, Nik Pakar wrote: > Thanks Holger, will give it another try. > > Would you be please kind enough to let me know whether it should work in > below topology. > > [MS]---[nanoBTS]----[OpenBSC NITB]---(ip)---[LCR]---(ip)--- > [Asterisk]----(sip)---> > > or would it need any E1/ISDN cards in between. > > Thanks again. > Nik > > > On Sun, Mar 4, 2012 at 9:36 AM, Holger Hans Peter Freyther < > holger at freyther.de> wrote: > >> On 03/03/2012 10:58 PM, Nik Pakar wrote: >> > Hi Holger, >> > >> >> > >> > But so far i have failed to get this no.1 done using LCR/asterisk >> option. So >> > pretty much given up with that. >> :) >> >> Hi Nik, >> >> we were using nitb/LCR for 27C3/28C3/Camp2012, I have also used >> LCR/Asterisk >> very recently for SIP callout. I think you should spend some more time to >> try >> to understand why it is failing for you. >> >> holger >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Sun Mar 4 18:30:58 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 04 Mar 2012 19:30:58 +0100 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> Message-ID: <4F53B4E2.3020306@freyther.de> On 03/04/2012 07:21 PM, Nik Pakar wrote: > Hi Holger, Hi Nik, I think it would be nice if you could improve the existing wiki page[1], what information can you provide right now that should be there? What is missing? E.g. your ascii-art image was a nice start (besides the usage of Unix Domain Sockets between nitb<->LCR and LCR<->asterisk). Our wiki allows to embed graphivz (dot) graphs. Please improve the existing documentation, in the process of doing that you will end up with a working configuration. holger [1] http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR From nikpakar at gmail.com Sun Mar 4 19:00:50 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sun, 4 Mar 2012 19:00:50 +0000 Subject: BSC_MGCP In-Reply-To: <4F53B4E2.3020306@freyther.de> References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> <4F53B4E2.3020306@freyther.de> Message-ID: Hi Holger, I would love involve with this beautiful project and contribute what ever i can. Will definitely like to take up the wiki task. But l think I need little bit of knowledge around the project just before that which im doing right now. I shall give it a start as soon as i have a fare grip on the framework. Re the integration, so its unix sockets as i understand. I will study it bit further on that extend and see whether i can get some thing done. Thanks for your help. Rgds Nik On Sun, Mar 4, 2012 at 6:30 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 03/04/2012 07:21 PM, Nik Pakar wrote: > > Hi Holger, > > Hi Nik, > > I think it would be nice if you could improve the existing wiki page[1], > what > information can you provide right now that should be there? What is > missing? > E.g. your ascii-art image was a nice start (besides the usage of Unix > Domain > Sockets between nitb<->LCR and LCR<->asterisk). Our wiki allows to embed > graphivz (dot) graphs. > > Please improve the existing documentation, in the process of doing that you > will end up with a working configuration. > > holger > > > > > > > [1] http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Sun Mar 4 21:48:54 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Sun, 4 Mar 2012 21:48:54 +0000 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> <4F53B4E2.3020306@freyther.de> Message-ID: Dear all, would some one be please kind enough to let me know which versions of OpenBSC, LCR, mISDN and asterisk should installed together in order to get a working NITB setup with LCR/asterisk. I tried almost all options with latest git clones, and recommended snapshots from LCR repo, all of them fail with various reasons. If some one can just point out which versions go together that would be really really appreciated. Rgds Nik On Sun, Mar 4, 2012 at 7:00 PM, Nik Pakar wrote: > Hi Holger, > > I would love involve with this beautiful project and contribute what ever > i can. Will definitely like to take up the wiki task. > > But l think I need little bit of knowledge around the project just before > that which im doing right now. I shall give it a start as soon as i have a > fare grip on the framework. > > Re the integration, so its unix sockets as i understand. > > I will study it bit further on that extend and see whether i can get some > thing done. > > Thanks for your help. > > Rgds > Nik > > > On Sun, Mar 4, 2012 at 6:30 PM, Holger Hans Peter Freyther < > holger at freyther.de> wrote: > >> On 03/04/2012 07:21 PM, Nik Pakar wrote: >> > Hi Holger, >> >> Hi Nik, >> >> I think it would be nice if you could improve the existing wiki page[1], >> what >> information can you provide right now that should be there? What is >> missing? >> E.g. your ascii-art image was a nice start (besides the usage of Unix >> Domain >> Sockets between nitb<->LCR and LCR<->asterisk). Our wiki allows to embed >> graphivz (dot) graphs. >> >> Please improve the existing documentation, in the process of doing that >> you >> will end up with a working configuration. >> >> holger >> >> >> >> >> >> >> [1] http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon Mar 5 15:22:43 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 Mar 2012 16:22:43 +0100 Subject: BSC_MGCP In-Reply-To: References: <4F528BFA.6080908@freyther.de> <4F5337A4.1080001@freyther.de> <4F53B4E2.3020306@freyther.de> Message-ID: <20120305152243.2140.qmail@stuge.se> Nik Pakar wrote: > I tried almost all options with latest git clones, and recommended > snapshots from LCR repo, It is always best to use the very latest code from version control. > all of them fail with various reasons. You need to investigate and understand why, and resolve the causes. Your basic expectation must be that the error is in your configuration, instead of a problem with any particular version of the code. I am not saying that these projects never have bugs, but I am saying that unlike many other software projects the people working on these projects are tremendously competent developers, and hence everyone naturally makes an effort not to create unneccessary regressions. Asking which versions are compatible means that you assume that regressions have been created by the developers. This is not very nice. There can certainly be bugs and problems in the code, but those who can help you fix the bugs are not able to magically read your screen so you must describe your problem correctly when you have found something that indeed is a bug. Please read and understand http://www.chiark.greenend.org.uk/~sgtatham/bugs.html As for your configuration problems I believe you will also there benefit greatly from reading the short page above linked. You must start communicating in a different way in order for anyone to be able to help you. The linked page explains the details. //Peter From ludovicarrel at yahoo.fr Mon Mar 5 14:14:01 2012 From: ludovicarrel at yahoo.fr (Ludovic Fotso) Date: Mon, 5 Mar 2012 06:14:01 -0800 (PST) Subject: Information about OpenBsc Message-ID: <1330956841.90806.YahooMailNeo@web65508.mail.ac4.yahoo.com> Hello, My Name is Tassy Fotso, I study communication Technologies in Higher Institut of Sahel (Cameroon).please How can I do to get OpenBSC. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Mar 6 14:21:34 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Tue, 06 Mar 2012 15:21:34 +0100 Subject: Information about OpenBsc In-Reply-To: <1330956841.90806.YahooMailNeo@web65508.mail.ac4.yahoo.com> References: <1330956841.90806.YahooMailNeo@web65508.mail.ac4.yahoo.com> Message-ID: <4F561D6E.1000500@freyther.de> On 03/05/2012 03:14 PM, Ludovic Fotso wrote: > Hello, > My Name is Tassy Fotso, I study communication Technologies in Higher Institut > of Sahel (Cameroon).please How can I do to get OpenBSC. > thanks please take a look at http://openbsc.osmocom.org. holger From jayrworthington at gmail.com Mon Mar 5 18:09:38 2012 From: jayrworthington at gmail.com (Jay R. Worthington) Date: Mon, 5 Mar 2012 19:09:38 +0100 Subject: Smoke a CAMEL? Message-ID: Hi y'all, not really sure if this help on building a "full fledged hlr", but the current version 4 of yate supports the MAP part of SS7, as well as CAMEL... http://yate.null.ro/ Regards, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailman at lists.osmocom.org Thu Mar 8 08:14:07 2012 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Thu, 08 Mar 2012 09:14:07 +0100 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: OpenBSC Member: philip.lansink at lan-consult.nl Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery System Subject: Mail delivery failed: returning message to sender Date: Thu, 08 Mar 2012 09:14:06 +0100 Size: 4919 URL: From nikpakar at gmail.com Fri Mar 9 14:30:48 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 9 Mar 2012 14:30:48 +0000 Subject: nanoBTS behind NAT Message-ID: Dear all, will the openbsc setup works with nanoBTSs sitting behind a NAT ? Rgds Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Fri Mar 9 14:37:21 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 09 Mar 2012 15:37:21 +0100 Subject: nanoBTS behind NAT In-Reply-To: References: Message-ID: <4F5A15A1.2020804@freyther.de> On 03/09/2012 03:30 PM, Nik Pakar wrote: > Dear all, will the openbsc setup works with nanoBTSs sitting behind a NAT ? Dear Lord, will Nik Pakar ever try something himself? Will he ever attempt to modify the wiki with the information he got provided with by nice people? amen holger From nikpakar at gmail.com Fri Mar 9 14:46:13 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 9 Mar 2012 14:46:13 +0000 Subject: nanoBTS behind NAT In-Reply-To: <4F5A15A1.2020804@freyther.de> References: <4F5A15A1.2020804@freyther.de> Message-ID: Thats a good one Holger, To be honestly i dont want to compile some thing incomplete which can lead others to go through the same misleading path which im going through. So im trying my best to get things working tested by myself and put that into wiki, instead of start writing every thing i see. Hope that make sense, so others who will be following the wiki will have more time to do some thing new rather than wasting time doing the same troubleshooting which im going right now. So for the God yes, he has instructed me to do it right at once :) Cheers holger, you will see my document very soon. Rgds Nik On Fri, Mar 9, 2012 at 2:37 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 03/09/2012 03:30 PM, Nik Pakar wrote: > > Dear all, will the openbsc setup works with nanoBTSs sitting behind a > NAT ? > > Dear Lord, > > will Nik Pakar ever try something himself? Will he ever attempt to modify > the > wiki with the information he got provided with by nice people? > > amen > holger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Fri Mar 9 14:50:02 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 09 Mar 2012 15:50:02 +0100 Subject: nanoBTS behind NAT In-Reply-To: References: <4F5A15A1.2020804@freyther.de> Message-ID: <4F5A189A.4090301@freyther.de> On 03/09/2012 03:46 PM, Nik Pakar wrote: > Hope that make sense, so others who will be following the wiki will have more > time to do some thing new rather than wasting time doing the same > troubleshooting which im going right now. what have you edited so far? Searching your name in the OpenBSC mailbox shows me 61 messages, I see _zero_ wiki edits, _zero_ patches, _zero_ things that have been fixed. Please stop consuming and produce. From nikpakar at gmail.com Fri Mar 9 15:03:14 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 9 Mar 2012 15:03:14 +0000 Subject: nanoBTS behind NAT In-Reply-To: <4F5A189A.4090301@freyther.de> References: <4F5A15A1.2020804@freyther.de> <4F5A189A.4090301@freyther.de> Message-ID: Hi Holger, i think that been bit rude. Would you expect any one to start playing and messing up with the wiki before even get a grip of what it is. On Fri, Mar 9, 2012 at 2:50 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 03/09/2012 03:46 PM, Nik Pakar wrote: > > > Hope that make sense, so others who will be following the wiki will have > more > > time to do some thing new rather than wasting time doing the same > > troubleshooting which im going right now. > > what have you edited so far? Searching your name in the OpenBSC mailbox > shows > me 61 messages, I see _zero_ wiki edits, _zero_ patches, _zero_ things that > have been fixed. Please stop consuming and produce. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Fri Mar 9 15:23:37 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 09 Mar 2012 16:23:37 +0100 Subject: nanoBTS behind NAT In-Reply-To: References: <4F5A15A1.2020804@freyther.de> <4F5A189A.4090301@freyther.de> Message-ID: <4F5A2079.4050903@freyther.de> On 03/09/2012 04:03 PM, Nik Pakar wrote: > Hi Holger, i think that been bit rude. Would you expect any one to start > playing and messing up with the wiki before even get a grip of what it is. Hi Nik, it is a matter of attitude. You ask other people to hold your hand and get everything explained. On the other hand when I asked you to give back by putting at least your diagram with nitb, LCR, SIP into the wiki.. you couldn't have cared less. The fact is, so far you have generated 63 email messages and have given _nothing_ back. You are a consumer. Did you even try to get an account for the wiki? > > what have you edited so far? Searching your name in the OpenBSC mailbox shows > me 61 messages, I see _zero_ wiki edits, _zero_ patches, _zero_ things that > have been fixed. Please stop consuming and produce. > > > From cr3 at cr3.us Fri Mar 9 15:26:53 2012 From: cr3 at cr3.us (Chris Rankine) Date: Fri, 9 Mar 2012 10:26:53 -0500 Subject: nanoBTS behind NAT In-Reply-To: <4F5A2079.4050903@freyther.de> References: <4F5A15A1.2020804@freyther.de> <4F5A189A.4090301@freyther.de> <4F5A2079.4050903@freyther.de> Message-ID: Ya'll should start a premium support service and make some cash answering questons about free software. On Mar 9, 2012 10:24 AM, "Holger Hans Peter Freyther" wrote: > On 03/09/2012 04:03 PM, Nik Pakar wrote: > > Hi Holger, i think that been bit rude. Would you expect any one to start > > playing and messing up with the wiki before even get a grip of what it > is. > > Hi Nik, > > it is a matter of attitude. You ask other people to hold your hand and get > everything explained. On the other hand when I asked you to give back by > putting at least your diagram with nitb, LCR, SIP into the wiki.. you > couldn't > have cared less. > > The fact is, so far you have generated 63 email messages and have given > _nothing_ back. You are a consumer. Did you even try to get an account for > the > wiki? > > > > > > > > what have you edited so far? Searching your name in the OpenBSC > mailbox shows > > me 61 messages, I see _zero_ wiki edits, _zero_ patches, _zero_ > things that > > have been fixed. Please stop consuming and produce. > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikpakar at gmail.com Fri Mar 9 15:44:47 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Fri, 9 Mar 2012 15:44:47 +0000 Subject: nanoBTS behind NAT In-Reply-To: <4F5A2079.4050903@freyther.de> References: <4F5A15A1.2020804@freyther.de> <4F5A189A.4090301@freyther.de> <4F5A2079.4050903@freyther.de> Message-ID: Hi Holger, i didnt thought you expected me to just put that ascii diagram straight away into wiki, instead i though doing more comprehensive page about the whole setup. Sorry if i misunderstood that. Since i was trying to get a grip on it before jumping in to the wiki, i didnt even request the wiki account, which otherwise i would have done. On Fri, Mar 9, 2012 at 3:23 PM, Holger Hans Peter Freyther < holger at freyther.de> wrote: > On 03/09/2012 04:03 PM, Nik Pakar wrote: > > Hi Holger, i think that been bit rude. Would you expect any one to start > > playing and messing up with the wiki before even get a grip of what it > is. > > Hi Nik, > > it is a matter of attitude. You ask other people to hold your hand and get > everything explained. On the other hand when I asked you to give back by > putting at least your diagram with nitb, LCR, SIP into the wiki.. you > couldn't > have cared less. > > The fact is, so far you have generated 63 email messages and have given > _nothing_ back. You are a consumer. Did you even try to get an account for > the > wiki? > > > > > > > > what have you edited so far? Searching your name in the OpenBSC > mailbox shows > > me 61 messages, I see _zero_ wiki edits, _zero_ patches, _zero_ > things that > > have been fixed. Please stop consuming and produce. > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Mar 10 13:46:20 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Mar 2012 14:46:20 +0100 Subject: nanoBTS behind NAT In-Reply-To: References: <4F5A15A1.2020804@freyther.de> <4F5A189A.4090301@freyther.de> Message-ID: <20120310134620.GS24882@prithivi.gnumonks.org> Nik, let me just state that you are the single and only person who has asked most openbsc usage related questions on this list in the shortest amount of time. Dozens, if not hundreds of other people have managed to compile, configure and run OpenBSC without raising the same number of questions on this list. If anything, this indicates that you are trying to abuse the OpenBSC developers for getting free help in your particular (most likely commercial) application. I suggest you either try more by yourself, or you try to get soem kind of comemrcial training/consulting/support arrangement with any of the people who have the respective experience. This way you would get what you want, in probably much less time, and without putting load on volunteers who hang out on this list and want to invest their time in improving the project and its documentation - rather than helping only one person. All the best, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Fri Mar 9 14:47:21 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 09 Mar 2012 15:47:21 +0100 Subject: nanoBTS behind NAT In-Reply-To: <4F5A15A1.2020804@freyther.de> References: <4F5A15A1.2020804@freyther.de> Message-ID: <4F5A17F9.4010609@freyther.de> On 03/09/2012 03:37 PM, Holger Hans Peter Freyther wrote: > On 03/09/2012 03:30 PM, Nik Pakar wrote: >> Dear all, will the openbsc setup works with nanoBTSs sitting behind a NAT ? > > Dear Lord, > > will Nik Pakar ever try something himself? Will he ever attempt to modify the > wiki with the information he got provided with by nice people? Dear Lord, does Nik Pakar ask you before crossing the street? z. From rogier at virtunix.nl Fri Mar 9 14:41:13 2012 From: rogier at virtunix.nl (Rogier van Eeten) Date: Fri, 09 Mar 2012 15:41:13 +0100 Subject: nanoBTS behind NAT In-Reply-To: References: Message-ID: <4F5A1689.7040502@virtunix.nl> On 03/09/2012 03:30 PM, Nik Pakar wrote: > Dear all, will the openbsc setup works with nanoBTSs sitting behind a NAT ? No, it doesn't. The RTP isn't getting through. You could try something with port forwarding or tunneling. -- Rogier From zone1942 at hotmail.com Sun Mar 11 17:21:19 2012 From: zone1942 at hotmail.com (Kwan) Date: Sun, 11 Mar 2012 17:21:19 +0000 (UTC) Subject: study on openbsc Message-ID: Hello, I am a student from Hong Kong and I take a project about openbsc. I have a BTS that product from interWave. I contacted interWave engineer and he said he can borrow us the E1 card to connect BTS. But I don't know how to make openbsc to support this BTS. I can provide some detail about this BTS if you need. Thank, Kwan From laforge at gnumonks.org Mon Mar 12 08:37:48 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Mar 2012 09:37:48 +0100 Subject: study on openbsc In-Reply-To: References: Message-ID: <20120312083748.GG31786@prithivi.gnumonks.org> Hi Kwan, On Sun, Mar 11, 2012 at 05:21:19PM +0000, Kwan wrote: > I am a student from Hong Kong and I take a project about openbsc. > I have a BTS that product from interWave. Is it really just a BTS or is it a "BSplus" (BTS plus integrated mini-BSC)? > I contacted interWave engineer and he said he can borrow us the E1 > card to connect BTS. But I don't know how to make openbsc to support > this BTS. Adding a new BTS model is possible in OpenBSC, but this of course requires that you understand the BTS and its A-bis dialect very well. I suggest that you study the A-bis protocols RSL (08.58) and OML (12.21) and try to get some real-world protocol traces between your BTS and an Interwave BSC. Using those protocol traces, you can then try to understand the messages and re-implement whatever is required inside OpenBSC. This is typically not a task that can be done in a single afternoon, but it will require some time and dedication. However, it definitely is possible, as we have shown with the support for various other BTS vendors. Feel free to share your traces and any progress and/or questions you have on this list. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From zone1942 at hotmail.com Tue Mar 13 13:38:48 2012 From: zone1942 at hotmail.com (Kwan) Date: Tue, 13 Mar 2012 13:38:48 +0000 (UTC) Subject: study on openbsc References: <20120312083748.GG31786@prithivi.gnumonks.org> Message-ID: Hello Harald Thank for your reply. > Is it really just a BTS or is it a "BSplus" (BTS plus integrated > mini-BSC)? Yes , that is a BSplus. Interwave engineer will come , and take following action: -add an extra BTS configuration -enter the proper BTS parameters to allow register and call. -boot the BTS with its connection to BS+ -after the TRX is online, swap the A-bis E1 of BTS to openBSC. any suggestions? From laforge at gnumonks.org Tue Mar 13 13:44:31 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Mar 2012 14:44:31 +0100 Subject: study on openbsc In-Reply-To: References: <20120312083748.GG31786@prithivi.gnumonks.org> Message-ID: <20120313134431.GC12727@prithivi.gnumonks.org> Hi Kwan, On Tue, Mar 13, 2012 at 01:38:48PM +0000, Kwan wrote: > Yes , that is a BSplus. Interwave engineer will come , and take following action: > -add an extra BTS configuration > -enter the proper BTS parameters to allow register and call. > -boot the BTS with its connection to BS+ > -after the TRX is online, swap the A-bis E1 of BTS to openBSC. To my understanding a BSplus has an integrated BSC and connects direclty ot the MSC using the A(SCCP/BSSAP/BSSMAP) interface. you cannot connect that to OpenBSC. Even if you run the Interwave only as a BTS (without the 'plus'), then you will need detailed documentation and/or protocol traces for their A-bis OML, and then write the code for that in OpenBSC. So even in the most ideal situation, I wuold consider a couple of days software development time are required. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nikpakar at gmail.com Thu Mar 15 11:53:26 2012 From: nikpakar at gmail.com (Nik Pakar) Date: Thu, 15 Mar 2012 11:53:26 +0000 Subject: Unknown payload type on OpenBSC when using rtp-bridge on LCR Message-ID: Hi Andreas, After some extensive testing i have done using jolly/rtpmux branch to get rtp to go directly between bsc and softswitch (yate in this case) i came across following scenario. MO call goes to OpenBSC/LCR then to yate routed back to OpenBSC/LCR and MT. Signalling seems all fine including codec negotiating as through out the path AMR/96 is been negotiated well. But once call connected, no rtp stream exist and i see following error on OpenBSC. received RTP frame with unknown payload type 98 Full topology and logs/trace from openbsc, LCR and yate is on this attachment. What could be the reason for bsc to get payload type 98. http://pastebin.com/rPfMamx0 Rgds Nik -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Mar 15 15:12:14 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 15 Mar 2012 16:12:14 +0100 Subject: Unknown payload type on OpenBSC when using rtp-bridge on LCR In-Reply-To: References: Message-ID: <20120315151214.GD10999@prithivi.gnumonks.org> On Thu, Mar 15, 2012 at 11:53:26AM +0000, Nik Pakar wrote: > What could be the reason for bsc to get payload type 98. http://cgit.osmocom.org/cgit/libosmo-abis/tree/include/osmocom/trau/osmo_ortp.h /*! \brief standard payload type for GSM Full Rate (FR) */ #define RTP_PT_GSM_FULL 3 /*! \brief Osmocom pseudo-static paylaod type for Half Rate (HR) */ #define RTP_PT_GSM_HALF 96 /*! \brief Osmocom pseudo-static paylaod type for Enhanced Full Rate * (EFR) */ #define RTP_PT_GSM_EFR 97 /*! \brief Osmocom pseudo-static paylaod type for Adaptive Multi Rate * (AMR) */ #define RTP_PT_AMR 98 -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Thu Mar 15 16:15:03 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 15 Mar 2012 17:15:03 +0100 Subject: Unknown payload type on OpenBSC when using rtp-bridge on LCR In-Reply-To: References: Message-ID: <20120315161503.14152.qmail@stuge.se> Nik Pakar wrote: > Signalling seems all fine including codec negotiating as through out the > path AMR/96 is been negotiated well. Why do you consider AMR/96 "well"? > received RTP frame with unknown payload type 98 Can "unknown payload type" be more clear? //Peter From pablo at gnumonks.org Fri Mar 16 15:10:04 2012 From: pablo at gnumonks.org (Pablo Neira Ayuso) Date: Fri, 16 Mar 2012 16:10:04 +0100 Subject: LAPD sequence error issues while bootstrapping RBS2308 Message-ID: <20120316151004.GA20594@1984> Hi Andreas, I'm having some problems while bootstrapping RBS2308 with the existing code. I think it is related to LAPD sequence number checkings: lapd.c:595 TX: 02 01 02 00 0c 11 01 80 1e 02 27 17 59 06 0 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 dahdi.c:248 dahdi TX (TS=1): 37 bytes lapd_core.c:1832 msg-len 31 sent 31 left 0 N201 260 t byte 0c lapd.c:345 RX: 02 01 01 04 lapd_core.c:1256 RR received in state LAPD_STATE_MF_EST lapd_core.c:739 ack frame 1 lapd_core.c:216 stop T200 lapd_core.c:208 start T203 lapd_core.c:1780 lapd_send_i() called from line 1294 lapd.c:345 RX: 00 01 02 04 10 1c 1a 02 62 11 1c 11 01 80 lapd_core.c:1463 I received in state LAPD_STATE_MF_EST lapd_core.c:1512 N(S) sequence error: N(S)=1, V(R)=0 ^^^^^^^^^^^^^^ It seems to me that the BSC transmits data while something is still coming from the BTS. Then, BSC's LAPD code silently drops the message (without rejection). Just a bit later the BSC gets a rejection from BTS's RSL layer. lapd.c:595 TX: 00 01 09 00 dahdi.c:248 dahdi TX (TS=1): 6 bytes lapd_core.c:224 stop T203 lapd_core.c:208 start T203 lapd_core.c:1780 lapd_send_i() called from line 1538 lapd.c:345 RX: 00 01 00 04 10 1c 1a 02 62 11 1c 11 01 80 lapd_core.c:1463 I received in state LAPD_STATE_MF_EST lapd_core.c:1546 incrementing V(R) to 1 lapd_core.c:224 stop T203 lapd_core.c:208 start T203 lapd_core.c:1555 message in single I frame abis_rsl.c:1128 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error) So the bootstrapping process never ends and the BTS never comes up. Let me know if you can provide any clue to resolve this issue. Thanks! From andreas at eversberg.eu Wed Mar 21 06:54:32 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Wed, 21 Mar 2012 07:54:32 +0100 Subject: LAPD sequence error issues while bootstrapping RBS2308 In-Reply-To: <20120316151004.GA20594@1984> References: <20120316151004.GA20594@1984> Message-ID: <4F697B28.7030208@eversberg.eu> Pablo Neira Ayuso wrote: > Hi Andreas, > > I'm having some problems while bootstrapping RBS2308 with the existing > code. I think it is related to LAPD sequence number checkings: > > lapd.c:595 TX: 02 01 02 00 0c 11 01 80 1e 02 27 17 59 06 > 0 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 > dahdi.c:248 dahdi TX (TS=1): 37 bytes > lapd_core.c:1832 msg-len 31 sent 31 left 0 N201 260 t byte 0c > lapd.c:345 RX: 02 01 01 04 > lapd_core.c:1256 RR received in state LAPD_STATE_MF_EST > lapd_core.c:739 ack frame 1 > lapd_core.c:216 stop T200 > lapd_core.c:208 start T203 > lapd_core.c:1780 lapd_send_i() called from line 1294 > lapd.c:345 RX: 00 01 02 04 10 1c 1a 02 62 11 1c 11 01 80 > lapd_core.c:1463 I received in state LAPD_STATE_MF_EST > lapd_core.c:1512 N(S) sequence error: N(S)=1, V(R)=0 > ^^^^^^^^^^^^^^ > It seems to me that the BSC transmits data while something is still > coming from the BTS. Then, BSC's LAPD code silently drops the message > (without rejection). > > Just a bit later the BSC gets a rejection from BTS's RSL layer. > > lapd.c:595 TX: 00 01 09 00 > dahdi.c:248 dahdi TX (TS=1): 6 bytes > lapd_core.c:224 stop T203 > lapd_core.c:208 start T203 > lapd_core.c:1780 lapd_send_i() called from line 1538 > lapd.c:345 RX: 00 01 00 04 10 1c 1a 02 62 11 1c 11 01 80 > lapd_core.c:1463 I received in state LAPD_STATE_MF_EST > lapd_core.c:1546 incrementing V(R) to 1 > lapd_core.c:224 stop T203 > lapd_core.c:208 start T203 > lapd_core.c:1555 message in single I frame > abis_rsl.c:1128 (bts=0,trx=0) ERROR REPORT CAUSE=0x62(Message Sequence Error) > > So the bootstrapping process never ends and the BTS never comes up. > > Let me know if you can provide any clue to resolve this issue. > > Thanks! complete log file: http://1984.lsi.us.es/~pablo/osmo-nitb-rbs2308.log hi pablo, the first sequence error (N(S) sequence error) is caused by a missing frame. in this case the frame 0 is expected, but frame 1 is received. this is normal. the lapd protocol sends a REJ message with the current sequence number, so the bts can repeat from there on. it seems that you have some packet loss. in can see many "HDLC abort" messages from dhadi driver in your debug log. maybe you should check the termination. also check if one of the wires from the bts is not connected. the message sequence error report from bts is a layer 3 message. i don't know why this message appears. i guess that the bts does not expect the rsl messages yet. your log file shows that you start two lapd instances with tei 0 (rsl) and one instance with tei (62) oml. i think this is the problem. you must first use oml to start and configure bts, then the bts should establish rsl link itself. at least this is what nokia insite does. regards, andreas From tacooper at vt.edu Mon Mar 19 18:27:28 2012 From: tacooper at vt.edu (Thomas Cooper) Date: Mon, 19 Mar 2012 14:27:28 -0400 Subject: "Osmo-USRP": combining OpenBTS and Osmocom Message-ID: Hey all, I've been working on connecting OpenBTS and osmo-bts ever since Harald formed the openbts-osmo repo (http://cgit.osmocom.org/cgit/openbts-osmo) and left me with a nice muxer framework and L1-L2 separation. I've named it Osmo-USRP but you can call it openbts-osmo or TrueBTS or whatever; it's not a big deal. Unfortunately I'm running short on time for completing my MS research, so testing is nowhere near complete but I figured I'd let the public users help me out a bit here if they want to try it out. Many thanks to Tom Tsou for helping me weed out bugs and test too. I've only scratched the surface of testing it with USRP1, USRP2, single vs. multiple PCs (Ubuntu and Fedora), and multiple BTSs. I've been able to get a stable network of 1 and 2 BTSs across 2 PCs with multiple MSs camped, and voice calls and SMS working. There seem to be a few fickle and unknown issues depending on which PC/Linux flavors/time of day I tested, and of course sometimes it will work for a certain MS but not another. Sometimes MSs won't location update to the network, or will hit errors when establishing a call; in the usual case, this won't even free the TCH so if resources run out the BTS must be rebooted. Just a few issues to name here, and I'm sure there are more out there. The current focus of work (when I can find time) is implementing handover between cells. I'm not even sure if osmo-bts and OpenBTS contain all the supporting functionality for handover (OpenBSC does though). The MSs correctly send SACCH meas reports, the BSC detects and decides to handover, and the TCH is activated, but I think the Handover Command is getting lost in the BTS or the MS Handover Accept bursts are being processed. The newly activated osmo-bts instance segfaults somewhere in LAPDm. I haven't had time lately to pinpoint the error, but just wanted to update on the current status of that. Also, multiple configuration files are needed because I have network parameters hard-coded (just for ease), which is elaborated some in the wiki. I ran into a segfault/bug trying to implement passing in config parameters from OpenBSC, and gave up to pursue more critical aspects of the project. Github repo: https://github.com/tacooper (first release tag for Osmo-USRP = v0.1) README/Guide: https://github.com/tacooper/Osmo-USRP/downloads (issues, configuration, and example setup for single/multi-BTS networks) If you'd like to help out by testing or even working on this project, it is much appreciated, even if only to help me grow my understanding of GSM networks through discussion. Thanks! Tom Cooper From alexander.chemeris at gmail.com Mon Mar 19 19:15:56 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 19 Mar 2012 23:15:56 +0400 Subject: "Osmo-USRP": combining OpenBTS and Osmocom In-Reply-To: References: Message-ID: Thomas, Congratulations for the release! Hopefully we'll see it stabilizing as more people start playing with it. Am I correct, that you use Transceiver52M and the lower part of OpenBTS and the rest is from OsmoBTS? It would be great if the architecture were described somewhere in the docs. On Mon, Mar 19, 2012 at 22:27, Thomas Cooper wrote: > Hey all, > I've been working on connecting OpenBTS and osmo-bts ever since Harald > formed the openbts-osmo repo > (http://cgit.osmocom.org/cgit/openbts-osmo) and left me with a nice > muxer framework and L1-L2 separation. I've named it Osmo-USRP but you > can call it openbts-osmo or TrueBTS or whatever; it's not a big deal. > Unfortunately I'm running short on time for completing my MS research, > so testing is nowhere near complete but I figured I'd let the public > users help me out a bit here if they want to try it out. Many thanks > to Tom Tsou for helping me weed out bugs and test too. > > I've only scratched the surface of testing it with USRP1, USRP2, > single vs. multiple PCs (Ubuntu and Fedora), and multiple BTSs. I've > been able to get a stable network of 1 and 2 BTSs across 2 PCs with > multiple MSs camped, and voice calls and SMS working. There seem to be > a few fickle and unknown issues depending on which PC/Linux > flavors/time of day I tested, and of course sometimes it will work for > a certain MS but not another. Sometimes MSs won't location update to > the network, or will hit errors when establishing a call; in the usual > case, this won't even free the TCH so if resources run out the BTS > must be rebooted. Just a few issues to name here, and I'm sure there > are more out there. > > The current focus of work (when I can find time) is implementing > handover between cells. I'm not even sure if osmo-bts and OpenBTS > contain all the supporting functionality for handover (OpenBSC does > though). The MSs correctly send SACCH meas reports, the BSC detects > and decides to handover, and the TCH is activated, but I think the > Handover Command is getting lost in the BTS or the MS Handover Accept > bursts are being processed. The newly activated osmo-bts instance > segfaults somewhere in LAPDm. I haven't had time lately to pinpoint > the error, but just wanted to update on the current status of that. > > Also, multiple configuration files are needed because I have network > parameters hard-coded (just for ease), which is elaborated some in the > wiki. I ran into a segfault/bug trying to implement passing in config > parameters from OpenBSC, and gave up to pursue more critical aspects > of the project. > > Github repo: > https://github.com/tacooper > (first release tag for Osmo-USRP = v0.1) > > README/Guide: > https://github.com/tacooper/Osmo-USRP/downloads > (issues, configuration, and example setup for single/multi-BTS networks) > > If you'd like to help out by testing or even working on this project, > it is much appreciated, even if only to help me grow my understanding > of GSM networks through discussion. > > Thanks! > Tom Cooper > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From tacooper at vt.edu Mon Mar 19 19:39:12 2012 From: tacooper at vt.edu (Thomas Cooper) Date: Mon, 19 Mar 2012 15:39:12 -0400 Subject: "Osmo-USRP": combining OpenBTS and Osmocom In-Reply-To: References: Message-ID: On Mon, Mar 19, 2012 at 3:15 PM, Alexander Chemeris wrote: > Thomas, > > Congratulations for the release! Hopefully we'll see it stabilizing as > more people start playing with it. > Thanks, I hope so too. > Am I correct, that you use Transceiver52M and the lower part of > OpenBTS and the rest is from OsmoBTS? It would be great if the > architecture were described somewhere in the docs. > That is correct, with a few minimal changes in OsmoBTS to get them to work together. Good idea, I have added another doc file to https://github.com/tacooper/Osmo-USRP/downloads with a basic description. I am just starting to write my thesis so more detailed descriptions will be available as I get to them. > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru From laforge at gnumonks.org Mon Mar 19 21:46:30 2012 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 19 Mar 2012 22:46:30 +0100 Subject: "Osmo-USRP": combining OpenBTS and Osmocom In-Reply-To: References: Message-ID: <20120319214630.GD27124@prithivi.gnumonks.org> Hi Thomas, thanks a lot for your very encoraging post. I should have been working on OpenBTS / osmo-bts integration for a long time now, and to my big embarrassment I still haven't gotten anywhere close to completion, for a variety of reasons :( On Mon, Mar 19, 2012 at 02:27:28PM -0400, Thomas Cooper wrote: > I've been working on connecting OpenBTS and osmo-bts ever since Harald > formed the openbts-osmo repo > (http://cgit.osmocom.org/cgit/openbts-osmo) and left me with a nice > muxer framework and L1-L2 separation. I've named it Osmo-USRP but you > can call it openbts-osmo or TrueBTS or whatever; it's not a big deal. Yes, I agree, naming is not our most important task right now. We can have a vote on it ;) > Unfortunately I'm running short on time for completing my MS research, > so testing is nowhere near complete but I figured I'd let the public > users help me out a bit here if they want to try it out. Many thanks > to Tom Tsou for helping me weed out bugs and test too. I'd really appreciate that and would love to give you write access to the openbts-osmo.git repository in an effort to avoid too many different branches in too many repositories. > I've only scratched the surface of testing it with USRP1, USRP2, > single vs. multiple PCs (Ubuntu and Fedora), and multiple BTSs. I've > been able to get a stable network of 1 and 2 BTSs across 2 PCs with > multiple MSs camped, and voice calls and SMS working. cool. > There seem to be a few fickle and unknown issues depending on which > PC/Linux flavors/time of day I tested, and of course sometimes it will > work for a certain MS but not another. Sometimes MSs won't location > update to the network, or will hit errors when establishing a call; in > the usual case, this won't even free the TCH so if resources run out > the BTS must be rebooted. Just a few issues to name here, and I'm sure > there are more out there. All to be expected, I'm sure we will iron those out over time. > The current focus of work (when I can find time) is implementing > handover between cells. Great. > I'm not even sure if osmo-bts and OpenBTS contain all the supporting > functionality for handover (OpenBSC does though). OpenBSC indeed has complete hand-over support for both E1 as well as Abis/IP based BTSs. osmo-bts does not yet have it implemented. I was about to work on it yesterday, but then decided to work on encryption first. The way it is supposed to happen: * at the time your receive the RSL CHAN ACT REQ, you need to check if it is initial or HO related activation * if it is HO related activation, you need to PH-ACTIVATE the RACH L1 SAPI on the TCH * The L1 will send a PH-RACH.ind on the TCH into osmo-bts * Osmo-BTS will PH-DEACTIVATE the RACH and PH-ACTIVATE the FACCH/TCH/SACCH * L2 establishment works normally after that. > The MSs correctly send SACCH meas reports, the BSC detects > and decides to handover, and the TCH is activated, but I think the > Handover Command is getting lost in the BTS or the MS Handover Accept > bursts are being processed. The HO CMD is a standard L3 message, so I'm quite sure it is transmitted correctly through all the layers like other messages. It's likely that it's simply the access bursts are neither handled in the OpenBTS part nor the osmo-bts part.. > Also, multiple configuration files are needed because I have network > parameters hard-coded (just for ease), which is elaborated some in the > wiki. I ran into a segfault/bug trying to implement passing in config > parameters from OpenBSC, and gave up to pursue more critical aspects > of the project. I agree, this is polishing that can be done at the end of the implementation. > If you'd like to help out by testing or even working on this project, > it is much appreciated, even if only to help me grow my understanding > of GSM networks through discussion. I'll try to find time to review the code and give some feedback. There is going to be a delay as we just have OsmoDevCon coming up, and I'm pretty busy until that is over :/ Keep up the great work, I really love seing all those pieces coming together. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From tacooper at vt.edu Tue Mar 20 01:51:10 2012 From: tacooper at vt.edu (Thomas Cooper) Date: Mon, 19 Mar 2012 21:51:10 -0400 Subject: "Osmo-USRP": combining OpenBTS and Osmocom In-Reply-To: <20120319214630.GD27124@prithivi.gnumonks.org> References: <20120319214630.GD27124@prithivi.gnumonks.org> Message-ID: On Mon, Mar 19, 2012 at 5:46 PM, Harald Welte wrote: > Hi Thomas, > > thanks a lot for your very encoraging post. > > I should have been working on OpenBTS / osmo-bts integration for a long > time now, and to my big embarrassment I still haven't gotten anywhere > close to completion, for a variety of reasons :( It's okay, I'm sure you have a lot of other projects you need to work on; I'm glad to be able to help a little. Your skeleton framework and layer separation were actually very helpful for getting me started since I hadn't had much experience developing OpenBTS or Osmocom. And reading code is a lot easier for me than reading lengthy specs to find a starting point. > > On Mon, Mar 19, 2012 at 02:27:28PM -0400, Thomas Cooper wrote: >> I've been working on connecting OpenBTS and osmo-bts ever since Harald >> formed the openbts-osmo repo >> (http://cgit.osmocom.org/cgit/openbts-osmo) and left me with a nice >> muxer framework and L1-L2 separation. I've named it Osmo-USRP but you >> can call it openbts-osmo or TrueBTS or whatever; it's not a big deal. > > Yes, I agree, naming is not our most important task right now. ?We can > have a vote on it ;) Haha sounds good, although I'm perfectly fine with leaving it named openbts-osmo. I just wasn't sure if any of my code would ever make it into your repo (since you were working on it already and I just needed to finish mine quickly). > >> Unfortunately I'm running short on time for completing my MS research, >> so testing is nowhere near complete but I figured I'd let the public >> users help me out a bit here if they want to try it out. Many thanks >> to Tom Tsou for helping me weed out bugs and test too. > > I'd really appreciate that and would love to give you write access to > the openbts-osmo.git repository in an effort to avoid too many different > branches in too many repositories. Okay that would be great! Of course you should definitely review my code first, as I am still a learning student :) > >> I've only scratched the surface of testing it with USRP1, USRP2, >> single vs. multiple PCs (Ubuntu and Fedora), and multiple BTSs. I've >> been able to get a stable network of 1 and 2 BTSs across 2 PCs with >> multiple MSs camped, and voice calls and SMS working. > > cool. > >> There seem to be a few fickle and unknown issues depending on which >> PC/Linux flavors/time of day I tested, and of course sometimes it will >> work for a certain MS but not another. Sometimes MSs won't location >> update to the network, or will hit errors when establishing a call; in >> the usual case, this won't even free the TCH so if resources run out >> the BTS must be rebooted. Just a few issues to name here, and I'm sure >> there are more out there. > > All to be expected, I'm sure we will iron those out over time. > >> The current focus of work (when I can find time) is implementing >> handover between cells. > > Great. > >> I'm not even sure if osmo-bts and OpenBTS contain all the supporting >> functionality for handover (OpenBSC does though). > > OpenBSC indeed has complete hand-over support for both E1 as well as > Abis/IP based BTSs. > > osmo-bts does not yet have it implemented. ?I was about to work on it > yesterday, but then decided to work on encryption first. > > The way it is supposed to happen: > * at the time your receive the RSL CHAN ACT REQ, you need to check > ?if it is initial or HO related activation > * if it is HO related activation, you need to PH-ACTIVATE the RACH L1 > ?SAPI on the TCH > * The L1 will send a PH-RACH.ind on the TCH into osmo-bts > * Osmo-BTS will PH-DEACTIVATE the RACH and PH-ACTIVATE the FACCH/TCH/SACCH > * L2 establishment works normally after that. Thanks for the great clarification. I had a slight idea about the random access bursts, but this outlines the process perfectly. > >> The MSs correctly send SACCH meas reports, the BSC detects >> and decides to handover, and the TCH is activated, but I think the >> Handover Command is getting lost in the BTS or the MS Handover Accept >> bursts are being processed. > > The HO CMD is a standard L3 message, so I'm quite sure it is transmitted > correctly through all the layers like other messages. ?It's likely that > it's simply the access bursts are neither handled in the OpenBTS part > nor the osmo-bts part.. > >> Also, multiple configuration files are needed because I have network >> parameters hard-coded (just for ease), which is elaborated some in the >> wiki. I ran into a segfault/bug trying to implement passing in config >> parameters from OpenBSC, and gave up to pursue more critical aspects >> of the project. > > I agree, this is polishing that can be done at the end of the > implementation. > >> If you'd like to help out by testing or even working on this project, >> it is much appreciated, even if only to help me grow my understanding >> of GSM networks through discussion. > > I'll try to find time to review the code and give some feedback. ?There > is going to be a delay as we just have OsmoDevCon coming up, and I'm > pretty busy until that is over :/ > > Keep up the great work, I really love seing all those pieces coming > together. Thanks for the encouragement, and any feedback would be terrific! Hopefully my inexperience doesn't show and it isn't too hackish or anything. Also take your time, I know you're a busy guy. > > Regards, > ? ? ? ?Harald > > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Wed Mar 21 09:19:28 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 21 Mar 2012 13:19:28 +0400 Subject: OsmoDevCon video recording Message-ID: Hi all, On Tue, Feb 21, 2012 at 11:54, Harald Welte wrote: > On Tue, Feb 21, 2012 at 08:10:35AM +0100, Sylvain Munaut wrote: >> As for live audio/video stream, I would suggest it's a bit of a >> complication we don't need. We could just do recordings and upload >> them publically or not afterwards depending on the speaker choice. > > that might be an idea, but in fact it would be better to have the > speaker be able to decide not to be recorded in the first place ;) > > Rule number one of data protection: Don't even create/store data that > you don't require to store... (German: "Datensparsamkeit") Following up on this, it seems to me that there is an agreement that we want to record talks where speaker doesn't object against recording. So, I'll try to get a good FullHD camera today and bring it to the conference, but we also need a tripod for a good quality recording. Is there anyone local who could bring one? We don't want to bring one from Moscow. :) -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Thu Mar 22 05:21:37 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 22 Mar 2012 09:21:37 +0400 Subject: OsmoDevCon video recording In-Reply-To: References: Message-ID: An update - we can't find the camera I wanted to take, but I'll grab a simpler one from our hackerspace. Sent from my Android device. -- Regards, Alexander Chemeris CEO, Fairwaves LLC http://fairwaves.ru 21.03.2012 13:19 ???????????? "Alexander Chemeris" < alexander.chemeris at gmail.com> ???????: > Hi all, > > On Tue, Feb 21, 2012 at 11:54, Harald Welte wrote: > > On Tue, Feb 21, 2012 at 08:10:35AM +0100, Sylvain Munaut wrote: > >> As for live audio/video stream, I would suggest it's a bit of a > >> complication we don't need. We could just do recordings and upload > >> them publically or not afterwards depending on the speaker choice. > > > > that might be an idea, but in fact it would be better to have the > > speaker be able to decide not to be recorded in the first place ;) > > > > Rule number one of data protection: Don't even create/store data that > > you don't require to store... (German: "Datensparsamkeit") > > Following up on this, it seems to me that there is an agreement that > we want to record talks where speaker doesn't object against > recording. So, I'll try to get a good FullHD camera today and bring it > to the conference, but we also need a tripod for a good quality > recording. Is there anyone local who could bring one? We don't want to > bring one from Moscow. :) > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t-openbsc at tobias.org Thu Mar 22 15:07:10 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Thu, 22 Mar 2012 16:07:10 +0100 Subject: Supplementary Services / Call Waiting in openbsc Message-ID: <4F6B401E.4000901@tobias.org> Hi, I pushed the branches tobias/supplementary_services to libosmocore and openbsc repositories. The idea is to enhance openbsc to be able to provide Supplementary Services other than USSD. I tried to implement activation, deactivation and interrogation in a generic way. Registration is not yet implemented, also handling of different teleservices is missing (Everything will be treated as requested for "Telephony"). Call Waiting is now implemented on top of those changes (it is one of the SS that doesn't need registration). (De-)Activation and interrogation can be triggered from the phone using either the menu or the MMI codes *43#, #43# and *#43# (see GSM 02.30). So a call to a subscriber will now only proceed if said subscriber isn't busy or CW has been provisioned and activated. (For details see the commit messages.) I know this isn't the most sexy new feature, but I needed it to test something and maybe somebody wants to implement other supplementary services like call forwarding... -Tobias From pablo at gnumonks.org Sat Mar 24 15:17:24 2012 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sat, 24 Mar 2012 16:17:24 +0100 Subject: [PATCH] ofono: add support for Wavecom Q2403 modem Message-ID: <1332602245-17888-1-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso Hi! Harald and me have been working on getting Wavecom Q2403 modem working with ofono. I promise to submit this to ofono mainstream at some point. It includes the udev configuration (see 80-ofono-wavecom.rules). Pablo Neira Ayuso (1): ofono: add support for Wavecom Q2403 modem 80-ofono-wavecom.rules | 6 ++ Makefile.am | 3 + acinclude.m4 | 2 +- drivers/atmodem/sim.c | 8 ++ drivers/atmodem/sms.c | 31 ++++++- drivers/atmodem/vendor.h | 1 + gatchat/gatchat.c | 3 +- plugins/udev.c | 2 + plugins/wavecom_q.c | 192 ++++++++++++++++++++++++++++++++++++++++++++++ 9 files changed, 241 insertions(+), 7 deletions(-) create mode 100644 80-ofono-wavecom.rules create mode 100644 plugins/wavecom_q.c -- 1.7.2.5 From pablo at gnumonks.org Sat Mar 24 15:17:25 2012 From: pablo at gnumonks.org (pablo at gnumonks.org) Date: Sat, 24 Mar 2012 16:17:25 +0100 Subject: [PATCH] ofono: add support for Wavecom Q2403 modem In-Reply-To: <1332602245-17888-1-git-send-email-pablo@gnumonks.org> References: <1332602245-17888-1-git-send-email-pablo@gnumonks.org> Message-ID: <1332602245-17888-2-git-send-email-pablo@gnumonks.org> From: Pablo Neira Ayuso This adds support for voice calls and SMS. In case of problems: * Compile in maintainer mode. * Enable OFONO_AT_DEBUG to check the AT command traces. * Run debugging mode in foreground: ./ofono -n -d This applies to ofono 1.5. Signed-off-by: Pablo Neira Ayuso --- 80-ofono-wavecom.rules | 6 ++ Makefile.am | 3 + acinclude.m4 | 2 +- drivers/atmodem/sim.c | 8 ++ drivers/atmodem/sms.c | 31 ++++++- drivers/atmodem/vendor.h | 1 + gatchat/gatchat.c | 3 +- plugins/udev.c | 2 + plugins/wavecom_q.c | 192 ++++++++++++++++++++++++++++++++++++++++++++++ 9 files changed, 241 insertions(+), 7 deletions(-) create mode 100644 80-ofono-wavecom.rules create mode 100644 plugins/wavecom_q.c diff --git a/80-ofono-wavecom.rules b/80-ofono-wavecom.rules new file mode 100644 index 0000000..6a409a9 --- /dev/null +++ b/80-ofono-wavecom.rules @@ -0,0 +1,6 @@ +ACTION!="add", GOTO="wavecom_q_rules_end" +SUBSYSTEM!="tty", GOTO="wavecom_q_rules_end" + +KERNEL=="ttyUSB*", ENV{OFONO_DRIVER}="wavecom_q" + +LABEL="wavecom_q_rules_end" diff --git a/Makefile.am b/Makefile.am index 0472dfa..f19322d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -350,6 +350,9 @@ builtin_sources += plugins/samsung.c builtin_modules += sim900 builtin_sources += plugins/sim900.c +builtin_modules += wavecom_q +builtin_sources += plugins/wavecom_q.c + if BLUETOOTH builtin_modules += bluetooth builtin_sources += plugins/bluetooth.c plugins/bluetooth.h diff --git a/acinclude.m4 b/acinclude.m4 index ac29c2b..c764f4a 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -15,7 +15,7 @@ AC_DEFUN([COMPILER_FLAGS], [ CFLAGS="-Wall -O2 -D_FORTIFY_SOURCE=2" fi if (test "$USE_MAINTAINER_MODE" = "yes"); then - CFLAGS="$CFLAGS -Werror -Wextra" + CFLAGS="$CFLAGS -Wextra" CFLAGS="$CFLAGS -Wno-unused-parameter" CFLAGS="$CFLAGS -Wno-missing-field-initializers" CFLAGS="$CFLAGS -Wdeclaration-after-statement" diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c index 8ee9822..32cbca8 100644 --- a/drivers/atmodem/sim.c +++ b/drivers/atmodem/sim.c @@ -146,6 +146,14 @@ static void at_sim_read_info(struct ofono_sim *sim, int fileid, return; } } + /* AT+CRSM not supported by Q2403. */ + if (sd->vendor == OFONO_VENDOR_WAVECOM_Q) { + unsigned char access[3] = { 0x00, 0x00, 0x00 }; + + CALLBACK_WITH_SUCCESS(cb, 4, 0, 0, access, + EF_STATUS_VALID, data); + return; + } cbd = cb_data_new(cb, data); diff --git a/drivers/atmodem/sms.c b/drivers/atmodem/sms.c index c31eb39..34f39b8 100644 --- a/drivers/atmodem/sms.c +++ b/drivers/atmodem/sms.c @@ -965,8 +965,12 @@ static gboolean set_cpms(gpointer user_data) const char *incoming = storages[data->incoming]; char buf[128]; - snprintf(buf, sizeof(buf), "AT+CPMS=\"%s\",\"%s\",\"%s\"", - store, store, incoming); + if (data->vendor != OFONO_VENDOR_WAVECOM_Q) { + snprintf(buf, sizeof(buf), "AT+CPMS=\"%s\",\"%s\",\"%s\"", + store, store, incoming); + } else { + snprintf(buf, sizeof(buf), "AT+CPMS=\"%s\"", store); + } g_at_chat_send(data->chat, buf, cpms_prefix, at_cpms_set_cb, sms, NULL); @@ -1018,7 +1022,7 @@ static void at_cpms_query_cb(gboolean ok, GAtResult *result, gboolean supported = FALSE; if (ok) { - int mem = 0; + int mem = 0, mem_max; GAtResultIter iter; const char *store; gboolean me_supported[3]; @@ -1034,7 +1038,23 @@ static void at_cpms_query_cb(gboolean ok, GAtResult *result, if (!g_at_result_iter_next(&iter, "+CPMS:")) goto out; - for (mem = 0; mem < 3; mem++) { + /* Wavecom Q reply replies something like this: + * + * +CPMS: (("SM","BM","SR"),("SM")) + * + * It does not provide the way income messages are stored. + * TS 07.05 allows mem2 and mem3 to be optional. + */ + if (data->vendor == OFONO_VENDOR_WAVECOM_Q) { + /* skip initial `(' */ + if (!g_at_result_iter_open_list(&iter)) + goto out; + + mem_max = 2; + } else + mem_max = 3; + + for (mem = 0; mem < mem_max; mem++) { if (!g_at_result_iter_open_list(&iter)) goto out; @@ -1051,7 +1071,8 @@ static void at_cpms_query_cb(gboolean ok, GAtResult *result, goto out; } - if (!sm_supported[2] && !me_supported[2] && !mt_supported[2]) + if (data->vendor != OFONO_VENDOR_WAVECOM_Q && + !sm_supported[2] && !me_supported[2] && !mt_supported[2]) goto out; if (sm_supported[0] && sm_supported[1]) { diff --git a/drivers/atmodem/vendor.h b/drivers/atmodem/vendor.h index 44b037f..1b296a0 100644 --- a/drivers/atmodem/vendor.h +++ b/drivers/atmodem/vendor.h @@ -39,4 +39,5 @@ enum ofono_vendor { OFONO_VENDOR_SPEEDUP, OFONO_VENDOR_SAMSUNG, OFONO_VENDOR_SIMCOM, + OFONO_VENDOR_WAVECOM_Q, }; diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c index 7a0ef35..eb5d83a 100644 --- a/gatchat/gatchat.c +++ b/gatchat/gatchat.c @@ -478,7 +478,8 @@ static struct terminator_info terminator_table[] = { { "NO ANSWER", -1, FALSE }, { "+CMS ERROR:", 11, FALSE }, { "+CME ERROR:", 11, FALSE }, - { "+EXT ERROR:", 11, FALSE } + { "+EXT ERROR:", 11, FALSE }, + { "+CPIN: READY", -1, TRUE }, }; static void at_chat_add_terminator(struct at_chat *chat, char *terminator, diff --git a/plugins/udev.c b/plugins/udev.c index 8cb87a5..e599296 100644 --- a/plugins/udev.c +++ b/plugins/udev.c @@ -286,6 +286,8 @@ done: add_nokiacdma(modem, udev_device); else if (g_strcmp0(driver, "sim900") == 0) add_sim900(modem, udev_device); + else if (g_strcmp0(driver, "wavecom_q") == 0) + add_calypso(modem, udev_device); } static gboolean devpath_remove(gpointer key, gpointer value, gpointer user_data) diff --git a/plugins/wavecom_q.c b/plugins/wavecom_q.c new file mode 100644 index 0000000..73e478a --- /dev/null +++ b/plugins/wavecom_q.c @@ -0,0 +1,192 @@ +/* + * + * oFono - Open Source Telephony + * + * Copyright (C) 2008-2011 Intel Corporation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + */ + +#ifdef HAVE_CONFIG_H +#include +#endif + +#include +#include + +#include +#include +#include + +#define OFONO_API_SUBJECT_TO_CHANGE +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +static int wavecom_q_probe(struct ofono_modem *modem) +{ + return 0; +} + +static void wavecom_q_remove(struct ofono_modem *modem) +{ +} + +static void wavecom_q_debug(const char *str, void *user_data) +{ + const char *prefix = user_data; + + ofono_info("%s%s", prefix, str); +} + +static int wavecom_q_enable(struct ofono_modem *modem) +{ + GAtChat *chat; + GIOChannel *channel; + GAtSyntax *syntax; + const char *device; + GHashTable *options; + + DBG("%p", modem); + + device = ofono_modem_get_string(modem, "Device"); + if (device == NULL) + return -EINVAL; + + options = g_hash_table_new(g_str_hash, g_str_equal); + + if (options == NULL) + return -ENOMEM; + + g_hash_table_insert(options, "Baud", "115200"); + g_hash_table_insert(options, "Parity", "none"); + g_hash_table_insert(options, "StopBits", "1"); + g_hash_table_insert(options, "DataBits", "8"); + + channel = g_at_tty_open(device, options); + + g_hash_table_destroy(options); + + if (channel == NULL) + return -EIO; + + /* + * Could not figure out whether it is fully compliant or not, use + * permissive for now + * */ + syntax = g_at_syntax_new_gsm_permissive(); + + chat = g_at_chat_new(channel, syntax); + g_at_syntax_unref(syntax); + g_io_channel_unref(channel); + + if (chat == NULL) + return -ENOMEM; + + if (getenv("OFONO_AT_DEBUG")) + g_at_chat_set_debug(chat, wavecom_q_debug, ""); + + ofono_modem_set_data(modem, chat); + + return 0; +} + +static int wavecom_q_disable(struct ofono_modem *modem) +{ + GAtChat *chat = ofono_modem_get_data(modem); + + DBG("%p", modem); + + ofono_modem_set_data(modem, NULL); + + g_at_chat_unref(chat); + + return 0; +} + +static void wavecom_q_pre_sim(struct ofono_modem *modem) +{ + GAtChat *chat = ofono_modem_get_data(modem); + struct ofono_sim *sim; + + DBG("%p", modem); + + ofono_devinfo_create(modem, 0, "atmodem", chat); + sim = ofono_sim_create(modem, OFONO_VENDOR_WAVECOM, "atmodem", chat); + ofono_voicecall_create(modem, 0, "atmodem", chat); + + if (sim) + ofono_sim_inserted_notify(sim, TRUE); +} + +static void wavecom_q_post_sim(struct ofono_modem *modem) +{ + GAtChat *chat = ofono_modem_get_data(modem); + struct ofono_message_waiting *mw; + + DBG("%p", modem); + + ofono_ussd_create(modem, 0, "atmodem", chat); + ofono_call_forwarding_create(modem, 0, "atmodem", chat); + ofono_call_settings_create(modem, 0, "atmodem", chat); + ofono_netreg_create(modem, 0, "atmodem", chat); + ofono_call_meter_create(modem, 0, "atmodem", chat); + ofono_call_barring_create(modem, 0, "atmodem", chat); + /* We need to specify the vendor to support AT+CPMS=? reply. */ + ofono_sms_create(modem, OFONO_VENDOR_WAVECOM_Q, "atmodem", chat); + ofono_phonebook_create(modem, 0, "atmodem", chat); + + mw = ofono_message_waiting_create(modem); + if (mw) + ofono_message_waiting_register(mw); +} + +static struct ofono_modem_driver wavecom_q_driver = { + .name = "wavecom_q", + .probe = wavecom_q_probe, + .remove = wavecom_q_remove, + .enable = wavecom_q_enable, + .disable = wavecom_q_disable, + .pre_sim = wavecom_q_pre_sim, + .post_sim = wavecom_q_post_sim, +}; + +static int wavecom_q_init(void) +{ + return ofono_modem_driver_register(&wavecom_q_driver); +} + +static void wavecom_q_exit(void) +{ + ofono_modem_driver_unregister(&wavecom_q_driver); +} + +OFONO_PLUGIN_DEFINE(wavecom_q, "Wavecom-Q driver", VERSION, + OFONO_PLUGIN_PRIORITY_DEFAULT, wavecom_q_init, wavecom_q_exit) -- 1.7.2.5 From holger at freyther.de Sun Mar 25 21:30:43 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 25 Mar 2012 23:30:43 +0200 Subject: Generate html with coverage info for osmocom Message-ID: <4F6F8E83.4000208@freyther.de> Hi All, I wrote this very simple script to build a bit of osmocom with coverage info, run the tests and use the lcov utility to create html. I am too lazy to upload the result somewhere right now. holger -------------- next part -------------- A non-text attachment was scrubbed... Name: coverage.sh Type: application/x-sh Size: 1225 bytes Desc: not available URL: From holger at freyther.de Sun Mar 25 23:20:14 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 26 Mar 2012 01:20:14 +0200 Subject: Generate html with coverage info for osmocom In-Reply-To: <4F6F8E83.4000208@freyther.de> References: <4F6F8E83.4000208@freyther.de> Message-ID: <4F6FA82E.6030909@freyther.de> On 03/25/2012 11:30 PM, Holger Hans Peter Freyther wrote: > Hi All, > > I wrote this very simple script to build a bit of osmocom with coverage info, > run the tests and use the lcov utility to create html. working version script.... -------------- next part -------------- A non-text attachment was scrubbed... Name: coverage.sh Type: application/x-sh Size: 1302 bytes Desc: not available URL: From refikthesis at googlemail.com Wed Mar 28 15:36:28 2012 From: refikthesis at googlemail.com (Refik Hadzialic) Date: Wed, 28 Mar 2012 17:36:28 +0200 Subject: Question regarding timeouts and RRLP Message-ID: Dear group members, I would like to ask you a question regarding the timeouts and initiating/allocating an SDCCH channel for a subscriber inside of the GSM network. I am trying to modify some parts of OpenBSC (/openbsc/src/libmsc/rrlp.c) and to implement the MS-based RRLP in OpenBSC (to send assistance data in form of almanac, ephemeris, BTS geolocation data and GPS reference time to the MS). At the moment I use the silent sms to start an RRLP request (send RRLP request + assistance data and then send the silent sms). But if it takes too long to send the assistance data OpenBSC starts from the beginning (send rrlp request + assistance data + sms again). I think this is because OpenBSC waits for an ack from the MS for the silent sms (which has not been sent) and therefore it's a timeout issue. As a quick hack I have modified parts of the code and got the RRLP to work (sent successfully these data and I got a position from the MS). Just for the curious one, I commented out three lines just before the return, in /openbsc/src/libmsc/gsm_04_11.c in the function, gsm411_rx_rp_ack, the following lines: //else //gsm411_release_conn(trans->conn); /* free the transaction here */ //trans_free(trans); and I changed one timer value from 10 to 100, in /openbsc/src/libbsc/bsc_rll.c in the function, rll_establish to: osmo_timer_schedule(&rllr->timer, 100, 0);. As I know what I did was wrong (since changing the timers and not releasing the channel properly influences the whole system) but I just did it for the purpose of testing and to see do I send correct data and does the RRLP work at all. I hope you can give me some hints and guides how to allocate a channel for around 130 seconds and to send the RRLP assistance data within that channel without doing the above tricks. Once everything works properly I will provide the RRLP code. Best regards, Refik Hadzialic From coinchon at yahoo.com Thu Mar 29 14:20:25 2012 From: coinchon at yahoo.com (Mathias Coinchon) Date: Thu, 29 Mar 2012 07:20:25 -0700 (PDT) Subject: Call for participation LSM/RMLL In-Reply-To: <1333018174.33900.YahooMailNeo@web39306.mail.mud.yahoo.com> References: <1333018174.33900.YahooMailNeo@web39306.mail.mud.yahoo.com> Message-ID: <1333030825.76488.YahooMailNeo@web39305.mail.mud.yahoo.com> Dear Osmocom community, This email to inform you that the call for participation for the next Libre Software Meeting (LSM or RMLL: Rencontres Mondiales du Logiciel Libre) ends on 31st March: http://2012.rmll.info/en/participate/call-for-papers This edition will take place in Geneva from 7th to 12th July 2012 (7-8 general public days, 9-12 theme focused, professional).? It would be of great interest for the communities to learn about the Osmocom projects in presentations or workshop. Real world applications would be interesting too. So please don't hesitate to directly submit. Don't hesitate also to contact me for more information. Mathias Coinchon -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Mar 29 15:20:16 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Mar 2012 17:20:16 +0200 Subject: Regular Osmocom meeting in Berlin? Message-ID: <20120329152016.GN19456@prithivi.gnumonks.org> Hi all, I was pondering to start a regular Osmocom meeting (monthly or bi-weekly) in Berlin. The idea would be not only to converge the existing developers in Berlin (zecke, roh, prom, tobias, peter, kevin, myself, ...) but to also try to share some knowledge and excitement with other interested hackers in the wider community. A split format for the event might make sense: Have a more or less organized 45min talk about one particular topic + 15min discussion and then switch to an informal meeting style without any particular topic or moderator. For the first half there is a long list of topics intended at informing people about the status and capabilities of the respective projects: OsmocomBB, OsmoTETRA, OsmoGMR, SIMtrace, etc. Regarding the venue, I would suggest to hold it at the Berlin CCC. What do you generally think about this? What day of the week should we be aiming at? Tuesday and Thursday is generally not a good idea, as those are already occupied with other events. If you think it's a good idea, I would request/register the event with the CCC Berlin. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Thu Mar 29 19:41:20 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 29 Mar 2012 21:41:20 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <20120329152016.GN19456@prithivi.gnumonks.org> References: <20120329152016.GN19456@prithivi.gnumonks.org> Message-ID: <20120329194120.30742.qmail@stuge.se> Harald Welte wrote: > I was pondering to start a regular Osmocom meeting (monthly or > bi-weekly) in Berlin. .. > What do you generally think about this? I say go for it. Bi-weekly sounds good. > What day of the week should we be aiming at? I like Wednesday. //Peter From peter.hasse at fokus.fraunhofer.de Fri Mar 30 08:19:40 2012 From: peter.hasse at fokus.fraunhofer.de (Peter Hasse) Date: Fri, 30 Mar 2012 10:19:40 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <20120329194120.30742.qmail@stuge.se> References: <20120329152016.GN19456@prithivi.gnumonks.org> <20120329194120.30742.qmail@stuge.se> Message-ID: <4F756C9C.4070205@fokus.fraunhofer.de> On 29.03.2012 21:41, Peter Stuge wrote: > Harald Welte wrote: >> I was pondering to start a regular Osmocom meeting (monthly or >> bi-weekly) in Berlin. > .. >> What do you generally think about this? > I say go for it. Bi-weekly sounds good. > > >> What day of the week should we be aiming at? > I like Wednesday. +1 > > > //Peter > mfg derpeter -- Peter Hasse Fraunhofer Institute for Open Communication Systems (FOKUS) Resource Optimized Networks (RESCON) Kaiserin-Augusta-Allee 31, D-10589 Berlin Email: Peter.Hasse at fokus.fraunhofer.de Phone: 030/34637297 http://www.fokus.fraunhofer.de From t-openbsc at tobias.org Fri Mar 30 10:06:43 2012 From: t-openbsc at tobias.org (Tobias Engel) Date: Fri, 30 Mar 2012 12:06:43 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <20120329194120.30742.qmail@stuge.se> References: <20120329152016.GN19456@prithivi.gnumonks.org> <20120329194120.30742.qmail@stuge.se> Message-ID: <4F7585B3.5090006@tobias.org> On 29.03.2012 21:41, Peter Stuge wrote: > Harald Welte wrote: >> I was pondering to start a regular Osmocom meeting (monthly or >> bi-weekly) in Berlin. > .. >> What do you generally think about this? > > I say go for it. Bi-weekly sounds good. I would say monthly is more realistic. But I'm also fine with bi-weekly. >> What day of the week should we be aiming at? > > I like Wednesday. Me too. -Tobias From gzsombor at gmail.com Fri Mar 30 11:37:11 2012 From: gzsombor at gmail.com (Zsombor) Date: Fri, 30 Mar 2012 13:37:11 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: References: <20120329152016.GN19456@prithivi.gnumonks.org> <20120329194120.30742.qmail@stuge.se> <4F7585B3.5090006@tobias.org> Message-ID: Can you record the video about the presentations and upload to some video sharing site ? I'm certain, that there would be some interest watching it :) Thanks, Zsombor On 2012.03.30. 13:33, "Tobias Engel" wrote: On 29.03.2012 21:41, Peter Stuge wrote: > Harald Welte wrote: >> I was pondering to start a regular ... I would say monthly is more realistic. But I'm also fine with bi-weekly. >> What day of the week should we be aiming at? > > I like Wednesday. Me too. -Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From shadown at gmail.com Fri Mar 30 11:37:13 2012 From: shadown at gmail.com (Sergio 'shadown' Alvarez) Date: Fri, 30 Mar 2012 13:37:13 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <4F7585B3.5090006@tobias.org> References: <20120329152016.GN19456@prithivi.gnumonks.org> <20120329194120.30742.qmail@stuge.se> <4F7585B3.5090006@tobias.org> Message-ID: The idea sounds great to me too. On Mar 30, 2012, at 12:06 PM, Tobias Engel wrote: > On 29.03.2012 21:41, Peter Stuge wrote: >> Harald Welte wrote: >>> I was pondering to start a regular Osmocom meeting (monthly or >>> bi-weekly) in Berlin. >> .. >>> What do you generally think about this? >> >> I say go for it. Bi-weekly sounds good. > > I would say monthly is more realistic. But I'm also fine with bi-weekly. Bi-weekly would give more chances to people who travel a lot, to at least make it to it once a month. >>> What day of the week should we be aiming at? >> >> I like Wednesday. > > Me too. > > -Tobias > From akibsayyed at gmail.com Fri Mar 30 17:27:29 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 30 Mar 2012 22:57:29 +0530 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: References: <20120329152016.GN19456@prithivi.gnumonks.org> <20120329194120.30742.qmail@stuge.se> <4F7585B3.5090006@tobias.org> Message-ID: even i am in.people who cannot participate please make some arrangement for them like live streaming and chat support. On Fri, Mar 30, 2012 at 5:07 PM, Sergio 'shadown' Alvarez wrote: > The idea sounds great to me too. > > On Mar 30, 2012, at 12:06 PM, Tobias Engel wrote: > >> On 29.03.2012 21:41, Peter Stuge wrote: >>> Harald Welte wrote: >>>> I was pondering to start a regular Osmocom meeting (monthly or >>>> bi-weekly) in Berlin. >>> .. >>>> What do you generally think about this? >>> >>> I say go for it. Bi-weekly sounds good. >> >> I would say monthly is more realistic. But I'm also fine with bi-weekly. > > Bi-weekly would give more chances to people who travel a lot, to at least make it to it once a month. > >>>> What day of the week should we be aiming at? >>> >>> I like Wednesday. >> >> Me too. >> >> -Tobias >> > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 From holger at freyther.de Fri Mar 30 19:13:22 2012 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Fri, 30 Mar 2012 21:13:22 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: References: <20120329152016.GN19456@prithivi.gnumonks.org> <20120329194120.30742.qmail@stuge.se> <4F7585B3.5090006@tobias.org> Message-ID: <4F7605D2.9040008@freyther.de> On 03/30/2012 07:27 PM, Akib Sayyed wrote: > even i am in.people who cannot participate please make some > arrangement for them like live streaming and chat support. > Hi, I don't think this is a good idea. It kills the local atmosphere without having any real benefit. Every decision/code and most likely slides will be public anyway. z. From alexander.chemeris at gmail.com Thu Mar 29 20:31:05 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 30 Mar 2012 00:31:05 +0400 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <20120329152016.GN19456@prithivi.gnumonks.org> References: <20120329152016.GN19456@prithivi.gnumonks.org> Message-ID: Harald, Looks like a great idea to promote open-source in telecom and recruit more devs into the community. Not to mention all other goals. I wish you all the best in setting up this event and I wish I lived in Berlin. :) I have to schedule a new run of my seminars on GSM and OpenBTS in Moscow as well. Hopefully it will bring more attention from Russian audience as well. On Thu, Mar 29, 2012 at 19:20, Harald Welte wrote: > Hi all, > > I was pondering to start a regular Osmocom meeting (monthly or bi-weekly) > in Berlin. > > The idea would be not only to converge the existing developers in Berlin > (zecke, roh, prom, tobias, peter, kevin, myself, ...) but to also try to > share some knowledge and excitement with other interested hackers in the > wider community. > > A split format for the event might make sense: ?Have a more or less > organized 45min talk about one particular topic + 15min discussion and > then switch to an informal meeting style without any particular topic or > moderator. > > For the first half there is a long list of topics intended at informing > people about the status and capabilities of the respective projects: > OsmocomBB, OsmoTETRA, OsmoGMR, SIMtrace, etc. > > Regarding the venue, I would suggest to hold it at the Berlin CCC. > > What do you generally think about this? > > What day of the week should we be aiming at? ?Tuesday and Thursday is > generally not a good idea, as those are already occupied with other > events. > > If you think it's a good idea, I would request/register the event with > the CCC Berlin. > > Regards, > ? ? ? ?Harald > > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From katrin at mobileactive.org Fri Mar 30 19:17:17 2012 From: katrin at mobileactive.org (Katrin Verclas) Date: Fri, 30 Mar 2012 19:17:17 +0000 Subject: Regular Osmocom meeting in Berlin? Message-ID: <113118383-1333135039-cardhu_decombobulator_blackberry.rim.net-1491659690-@b4.c4.bise6.blackberry> Could not disagree more. We live-stream local events all the time with a very unobtrusive webcam/ustream and it bothers no one who is there but benefits all who are not. Best, Katrin ------Original Message------ From: Holger Hans Peter Freyther Sender: baseband-devel-bounces at lists.osmocom.org To: Akib Sayyed Cc: baseband-devel at lists.osmocom.org Cc: openbsc at lists.osmocom.org Subject: Re: Regular Osmocom meeting in Berlin? Sent: Mar 30, 2012 3:13 PM On 03/30/2012 07:27 PM, Akib Sayyed wrote: > even i am in.people who cannot participate please make some > arrangement for them like live streaming and chat support. > Hi, I don't think this is a good idea. It kills the local atmosphere without having any real benefit. Every decision/code and most likely slides will be public anyway. z. Sent via mobile. Hence, short. From akibsayyed at gmail.com Sat Mar 31 02:39:04 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 31 Mar 2012 08:09:04 +0530 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <113118383-1333135039-cardhu_decombobulator_blackberry.rim.net-1491659690-@b4.c4.bise6.blackberry> References: <113118383-1333135039-cardhu_decombobulator_blackberry.rim.net-1491659690-@b4.c4.bise6.blackberry> Message-ID: in my opinion holger is thinking that " it might become odd for people in conference to present as it is being streamed live.or also they wont be able to act freely" i think people are more interested to supporting main aim of meet.so even if there is no proper protocol of communication is very much ok(please correct me if i am wrong) On Sat, Mar 31, 2012 at 12:47 AM, Katrin Verclas wrote: > Could not disagree more. We live-stream local events all the time with a very unobtrusive webcam/ustream and it bothers no one who is there but benefits all who are not. > > Best, > > Katrin > > ------Original Message------ > From: Holger Hans Peter Freyther > Sender: baseband-devel-bounces at lists.osmocom.org > To: Akib Sayyed > Cc: baseband-devel at lists.osmocom.org > Cc: openbsc at lists.osmocom.org > Subject: Re: Regular Osmocom meeting in Berlin? > Sent: Mar 30, 2012 3:13 PM > > On 03/30/2012 07:27 PM, Akib Sayyed wrote: >> even i am in.people who cannot participate please make some >> arrangement for them like live streaming and chat support. >> > > Hi, > > I don't think this is a good idea. It kills the local atmosphere without > having any real benefit. Every decision/code and most likely slides will be > public anyway. > > z. > > > > Sent via mobile. Hence, short. -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 From laforge at gnumonks.org Sat Mar 31 12:01:40 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 31 Mar 2012 14:01:40 +0200 Subject: Recording / Re: Regular Osmocom meeting in Berlin? In-Reply-To: <113118383-1333135039-cardhu_decombobulator_blackberry.rim.net-1491659690-@b4.c4.bise6.blackberry> References: <113118383-1333135039-cardhu_decombobulator_blackberry.rim.net-1491659690-@b4.c4.bise6.blackberry> Message-ID: <20120331120140.GA27922@prithivi.gnumonks.org> Hi Katrin, On Fri, Mar 30, 2012 at 07:17:17PM +0000, Katrin Verclas wrote: > Could not disagree more. We live-stream local events all the time with > a very unobtrusive webcam/ustream and it bothers no one who is there > but benefits all who are not. And I couldn't disagree more with you. The mere existance of the two words 'camera' and 'unobtrusive' in one sentence are a contradiction in terms. If I want to meet with a small group of people and informally discuss technical topic, than that is _very_ different from being live streamed to an unknonwn number of people, any of which could make recordings and I would have to very carefully think about each and every word that I'm saying. That's not a particularly relaxed environment and would kill all the fun there is in having the meeting in the first place. Legally, In Germany this corresponds to "not publicly spoken word" (nicht oeffentlich gesprochenes Wort). It is punishable under law to record or broadcast that. (Clause 201 of German criminal code). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From katrin at mobileactive.org Sat Mar 31 13:37:42 2012 From: katrin at mobileactive.org (Katrin Verclas) Date: Sat, 31 Mar 2012 13:37:42 +0000 Subject: Recording / Re: Regular Osmocom meeting in Berlin? Message-ID: <1893188027-1333201059-cardhu_decombobulator_blackberry.rim.net-1141642911-@b4.c4.bise6.blackberry> It was my understanding from your suggestion that there would be presentations and discussions after those presentations at the meetings, making this not just having a beer with friends but more formal affairs. That would be useful for people elsewhere to see, given that this is a global community. Not sure what German law has to do with putting online or streaming such presentations. Cameras off when it comes to the informal part and beer time.. Love this list otherwise. And will come to Berlin this summer so may attend one or two, regardless :) Cheers from New York. K ------Original Message------ From: Harald Welte To: Katrin Verclas Cc: Holger Hans Peter Freyther Cc: Akib Sayyed Cc: baseband-devel at lists.osmocom.org Cc: openbsc at lists.osmocom.org Subject: Recording / Re: Regular Osmocom meeting in Berlin? Sent: Mar 31, 2012 8:01 AM Hi Katrin, On Fri, Mar 30, 2012 at 07:17:17PM +0000, Katrin Verclas wrote: > Could not disagree more. We live-stream local events all the time with > a very unobtrusive webcam/ustream and it bothers no one who is there > but benefits all who are not. And I couldn't disagree more with you. The mere existance of the two words 'camera' and 'unobtrusive' in one sentence are a contradiction in terms. If I want to meet with a small group of people and informally discuss technical topic, than that is _very_ different from being live streamed to an unknonwn number of people, any of which could make recordings and I would have to very carefully think about each and every word that I'm saying. That's not a particularly relaxed environment and would kill all the fun there is in having the meeting in the first place. Legally, In Germany this corresponds to "not publicly spoken word" (nicht oeffentlich gesprochenes Wort). It is punishable under law to record or broadcast that. (Clause 201 of German criminal code). Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) Sent via mobile. Hence, short. From martin at windycitysdr.com Sat Mar 31 23:08:08 2012 From: martin at windycitysdr.com (Martin O'Shield) Date: Sat, 31 Mar 2012 18:08:08 -0500 Subject: Recording / Re: Regular Osmocom meeting in Berlin? In-Reply-To: <1893188027-1333201059-cardhu_decombobulator_blackberry.rim.net-1141642911-@b4.c4.bise6.blackberry> References: <1893188027-1333201059-cardhu_decombobulator_blackberry.rim.net-1141642911-@b4.c4.bise6.blackberry> Message-ID: Katrin, My reply below: On Sat, Mar 31, 2012 at 8:37 AM, Katrin Verclas wrote: > It was my understanding from your suggestion that there would be > presentations and discussions after those presentations at the meetings, > making this not just having a beer with friends but more formal affairs. > > That would be useful for people elsewhere to see, given that this is a > global community. Not sure what German law has to do with putting online > or streaming such presentations. Cameras off when it comes to the informal > part and beer time.. > > I agree with Katrin! > Love this list otherwise. And will come to Berlin this summer so may > attend one or two, regardless :) > Me Too! :-) > > Cheers from New York. > Cheers from Chicago! > > > K > > > Sincerely, Martin > > ------Original Message------ > From: Harald Welte > To: Katrin Verclas > Cc: Holger Hans Peter Freyther > Cc: Akib Sayyed > Cc: baseband-devel at lists.osmocom.org > Cc: openbsc at lists.osmocom.org > Subject: Recording / Re: Regular Osmocom meeting in Berlin? > Sent: Mar 31, 2012 8:01 AM > > Hi Katrin, > > On Fri, Mar 30, 2012 at 07:17:17PM +0000, Katrin Verclas wrote: > > Could not disagree more. We live-stream local events all the time with > > a very unobtrusive webcam/ustream and it bothers no one who is there > > but benefits all who are not. > > And I couldn't disagree more with you. The mere existance of the two > words 'camera' and 'unobtrusive' in one sentence are a contradiction in > terms. > > If I want to meet with a small group of people and informally discuss > technical topic, than that is _very_ different from being live streamed > to an unknonwn number of people, any of which could make recordings and > I would have to very carefully think about each and every word that I'm > saying. That's not a particularly relaxed environment and would kill > all the fun there is in having the meeting in the first place. > > Legally, In Germany this corresponds to "not publicly spoken word" > (nicht oeffentlich gesprochenes Wort). It is punishable under law to > record or broadcast that. (Clause 201 of German criminal code). > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > Sent via mobile. Hence, short. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at mail.tsaitgaist.info Sat Mar 31 00:18:31 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Sat, 31 Mar 2012 02:18:31 +0200 Subject: Regular Osmocom meeting in Berlin? In-Reply-To: <20120329152016.GN19456@prithivi.gnumonks.org> References: <20120329152016.GN19456@prithivi.gnumonks.org> Message-ID: <1333152922-sup-3490@dennou> Hi, Excerpts from Harald Welte's message of Thu Mar 29 17:20:16 +0200 2012: > > I was pondering to start a regular Osmocom meeting (monthly or bi-weekly) > in Berlin. monthly soung good. bi-weekly could also be a good way to invite/welcome new-comers and introduce them to osmocom (which has 1000 subproject), for individual presentation, workshop, tutorial, ... something informal, so to help in the beginnings. > > The idea would be not only to converge the existing developers in Berlin > (zecke, roh, prom, tobias, peter, kevin, myself, ...) but to also try to > share some knowledge and excitement with other interested hackers in the > wider community. I will be there. > > Regarding the venue, I would suggest to hold it at the Berlin CCC. good place > What day of the week should we be aiming at? Tuesday and Thursday is > generally not a good idea, as those are already occupied with other > events. wednesday is good for me. kevin From jolly at eversberg.eu Thu Mar 8 10:08:37 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 8 Mar 2012 11:08:37 +0100 Subject: [PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much Message-ID: The RTP stream is generated or forwarded by OpenBSC to nanoBTS. Due to switching of streams (hold/retrieve call), packet loss or even stalling of sender's process, the time stamp must be corrected. If outdated packets are received, they get dropped. --- openbsc/src/libtrau/rtp_proxy.c | 80 ++++++++++++++++++++++++++++++----------- 1 file changed, 59 insertions(+), 21 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index ed7479d..3e6c462 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -236,6 +236,12 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, in return 0; } +#define USEC_1S 1000000 +#define USEC_10MS 10000 +#define USEC_20MS 20000 +#define SAMPLES_1S 8000 +#define USEC_SAMPLE 125 + /* "to - from" */ static void tv_difference(struct timeval *diff, const struct timeval *from, const struct timeval *__to) @@ -244,13 +250,60 @@ static void tv_difference(struct timeval *diff, const struct timeval *from, if (to->tv_usec < from->tv_usec) { to->tv_sec -= 1; - to->tv_usec += 1000000; + to->tv_usec += USEC_1S; } diff->tv_usec = to->tv_usec - from->tv_usec; diff->tv_sec = to->tv_sec - from->tv_sec; } +/* add sec,usec to tv */ +static void tv_add(struct timeval *tv, int sec, int usec) +{ + + if (usec < 0) + usec += USEC_1S; + tv->tv_sec += sec; + tv->tv_usec += usec; + if (tv->tv_usec >= USEC_1S) { + tv->tv_sec++; + tv->tv_usec -= USEC_1S; + } +} + +static int correct_timestamp(struct rtp_socket *rs, int duration) +{ + struct timeval tv, tv_diff; + long int usec_diff, frame_diff; + + gettimeofday(&tv, NULL); + tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); + tv_add(&rs->transmit.last_tv, 0, USEC_20MS); + + usec_diff = tv_diff.tv_sec * USEC_1S + tv_diff.tv_usec; + frame_diff = ((usec_diff + (USEC_10MS)) / USEC_20MS); /* round */ + + if (abs(frame_diff - 1) > 1) { + long int frame_diff_excess = frame_diff - 1; + long int sample_diff_excess = frame_diff_excess * duration; + + /* correct last_tv */ + tv_add(&rs->transmit.last_tv, sample_diff_excess / SAMPLES_1S, + (sample_diff_excess % SAMPLES_1S) * USEC_SAMPLE); + /* drop frame, if time stamp is in the past */ + if (frame_diff_excess < 0) + return -1; + LOGP(DLMUX, LOGL_NOTICE, + "Correcting timestamp difference of %ld frames " + "(to %s)\n", frame_diff_excess, + (rs->rx_action == RTP_RECV_L4) ? "app" : "BTS"); + rs->transmit.sequence += frame_diff_excess; + rs->transmit.timestamp += sample_diff_excess; + } + + return 0; +} + /*! \brief encode and send a rtp frame * \param[in] rs RTP socket through which we shall send * \param[in] frame GSM RTP frame to be sent @@ -265,6 +318,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) int duration; /* in samples */ int amr = 0; uint8_t dynamic_pt = 0; + int rc; if (rs->rx_action == RTP_RECV_L4) dynamic_pt = rs->receive.payload_type; @@ -275,6 +329,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rs->transmit.ssrc = rand(); rs->transmit.sequence = random(); rs->transmit.timestamp = random(); + gettimeofday(&rs->transmit.last_tv, NULL); } switch (frame->msg_type) { @@ -313,26 +368,9 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) return -EINVAL; } - { - struct timeval tv, tv_diff; - long int usec_diff, frame_diff; - - gettimeofday(&tv, NULL); - tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); - rs->transmit.last_tv = tv; - - usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec; - frame_diff = (usec_diff / 20000); - - if (abs(frame_diff) > 1) { - long int frame_diff_excess = frame_diff - 1; - - LOGP(DLMUX, LOGL_NOTICE, - "Correcting frame difference of %ld frames\n", frame_diff_excess); - rs->transmit.sequence += frame_diff_excess; - rs->transmit.timestamp += frame_diff_excess * duration; - } - } + rc = correct_timestamp(rs, duration); + if (rc) + return 0; if (frame->msg_type == GSM_BAD_FRAME) return 0; -- 1.8.1.5 --------------090106010400060202050508-- From jolly at eversberg.eu Thu Mar 8 10:08:37 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 8 Mar 2012 11:08:37 +0100 Subject: [PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much Message-ID: The RTP stream is generated or forwarded by OpenBSC to nanoBTS. Due to switching of streams (hold/retrieve call), packet loss or even stalling of sender's process, the time stamp must be corrected. If outdated packets are received, they get dropped. --- openbsc/src/libtrau/rtp_proxy.c | 82 ++++++++++++++++++++++++++++++----------- 1 file changed, 61 insertions(+), 21 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 2284798..88753b6 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -236,6 +236,12 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, in return 0; } +#define USEC_1S 1000000 +#define USEC_10MS 10000 +#define USEC_20MS 20000 +#define SAMPLES_1S 8000 +#define USEC_SAMPLE 125 + /* "to - from" */ static void tv_difference(struct timeval *diff, const struct timeval *from, const struct timeval *__to) @@ -244,13 +250,62 @@ static void tv_difference(struct timeval *diff, const struct timeval *from, if (to->tv_usec < from->tv_usec) { to->tv_sec -= 1; - to->tv_usec += 1000000; + to->tv_usec += USEC_1S; } diff->tv_usec = to->tv_usec - from->tv_usec; diff->tv_sec = to->tv_sec - from->tv_sec; } +/* add sec,usec to tv */ +static void tv_add(struct timeval *tv, int sec, int usec) +{ + + while (usec < 0) { + usec += USEC_1S; + sec--; + } + tv->tv_sec += sec; + tv->tv_usec += usec; + while (tv->tv_usec >= USEC_1S) { + tv->tv_sec++; + tv->tv_usec -= USEC_1S; + } +} + +static int correct_timestamp(struct rtp_socket *rs, int duration) +{ + struct timeval tv, tv_diff; + long int usec_diff, frame_diff; + + gettimeofday(&tv, NULL); + tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); + tv_add(&rs->transmit.last_tv, 0, USEC_20MS); + + usec_diff = tv_diff.tv_sec * USEC_1S + tv_diff.tv_usec; + frame_diff = ((usec_diff + (USEC_10MS)) / USEC_20MS); /* round */ + + if (abs(frame_diff - 1) > 1) { + long int frame_diff_excess = frame_diff - 1; + long int sample_diff_excess = frame_diff_excess * duration; + + /* correct last_tv */ + tv_add(&rs->transmit.last_tv, sample_diff_excess / SAMPLES_1S, + (sample_diff_excess % SAMPLES_1S) * USEC_SAMPLE); + /* drop frame, if time stamp is in the past */ + if (frame_diff_excess < 0) + return -1; + LOGP(DLMUX, LOGL_NOTICE, + "Correcting timestamp difference of %ld frames " + "(to %s)\n", frame_diff_excess, + (rs->rx_action == RTP_RECV_L4) ? "app" : "BTS"); + rs->transmit.sequence += frame_diff_excess; + rs->transmit.timestamp += sample_diff_excess; + } + + return 0; +} + /*! \brief encode and send a rtp frame * \param[in] rs RTP socket through which we shall send * \param[in] frame GSM RTP frame to be sent @@ -265,6 +320,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) int duration; /* in samples */ int amr = 0; uint8_t dynamic_pt = 0; + int rc; if (rs->rx_action == RTP_RECV_L4) dynamic_pt = rs->receive.payload_type; @@ -275,6 +331,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rs->transmit.ssrc = rand(); rs->transmit.sequence = random(); rs->transmit.timestamp = random(); + gettimeofday(&rs->transmit.last_tv, NULL); } switch (frame->msg_type) { @@ -313,26 +370,9 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) return -EINVAL; } - { - struct timeval tv, tv_diff; - long int usec_diff, frame_diff; - - gettimeofday(&tv, NULL); - tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); - rs->transmit.last_tv = tv; - - usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec; - frame_diff = (usec_diff / 20000); - - if (abs(frame_diff) > 1) { - long int frame_diff_excess = frame_diff - 1; - - LOGP(DLMUX, LOGL_NOTICE, - "Correcting frame difference of %ld frames\n", frame_diff_excess); - rs->transmit.sequence += frame_diff_excess; - rs->transmit.timestamp += frame_diff_excess * duration; - } - } + rc = correct_timestamp(rs, duration); + if (rc) + return 0; if (frame->msg_type == GSM_BAD_FRAME) return 0; -- 1.8.1.5 --------------000504080100090805040102-- From jolly at eversberg.eu Thu Mar 8 10:08:37 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 8 Mar 2012 11:08:37 +0100 Subject: [PATCH 8/9] Fixed (ipaccess BTS) delay/silence problems, if RTP stream jitters too much Message-ID: After OpenBSC stalled for some reason (e.g. CPU overload or database access) or after speech frames have been lost (MNCC application problems / hold/retrieve call), the timestamp and the sequence number of the RTP socket state must be corrected. The amount of incrmentation is calculated from the elapsed time. Not incrementing timestamp and sequence number would cause all frames to be dropped by ipaccess BTS, because the BTS expects frames with more recent timestamps. If speech frames are received too fast, they must be dropped. The timestamp and sequence number of the RTP socket state are not changed in this case. Incmenetating timestamp and sequence number would causes high delay at ipaccess BTS, because the BTS would queue the frames until the timestamp matches the current time. There is a simple test case: Make a call between two phones and check the delay. (When using LCR, make a call to the echo test.) The press CTRL+z to suspend OpenBSC process for a few seconds and enter "fg" to continue OpenBSC process. There shall be no change in the delay, even after repeating this test many times. --- openbsc/src/libtrau/rtp_proxy.c | 89 +++++++++++++++++++++++++++-------------- 1 file changed, 60 insertions(+), 29 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 0c4d82b..fa6b629 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -236,19 +236,65 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data, in return 0; } -/* "to - from" */ -static void tv_difference(struct timeval *diff, const struct timeval *from, - const struct timeval *__to) +#define USEC_1S 1000000 +#define USEC_10MS 10000 +#define USEC_20MS 20000 +#define SAMPLES_1S 8000 +#define USEC_SAMPLE 125 + +/* add usec to tv */ +static void tv_add_usec(struct timeval *tv, long int usec) { - struct timeval _to = *__to, *to = &_to; + struct timeval tv_add; - if (to->tv_usec < from->tv_usec) { - to->tv_sec -= 1; - to->tv_usec += 1000000; + tv_add.tv_sec = usec / USEC_1S; + tv_add.tv_usec = usec % USEC_1S; + timeradd(tv, &tv_add, tv); +} + +static int correct_timestamp(struct rtp_socket *rs, int duration) +{ + struct timeval tv, tv_diff; + long int usec_diff, frame_diff; + int usec_duration = duration * USEC_SAMPLE; + + gettimeofday(&tv, NULL); + timersub(&tv, &rs->transmit.last_tv, &tv_diff); + + usec_diff = tv_diff.tv_sec * USEC_1S + tv_diff.tv_usec; + frame_diff = (usec_diff + (usec_duration >> 1)) / usec_duration; /* round */ + + /* Drop frame, if current time to too much in advance of the last_tv. + * < 0 means that the time difference in frames must be at lease 2 + * frames below the expected difference of 1. + */ + if (frame_diff < 0) + return -1; + + /* Increment last_tv by the duration of one frame. */ + tv_add_usec(&rs->transmit.last_tv, usec_duration); + + /* Increment last_tv, if the current time is too much afterwards. + * Also increment timestamp and sequence number of RTP socket state. + * > 2 means that the time difference in frames must be at least 2 + * frames above the expected difference of 1. + */ + if (frame_diff > 2) { + long int frame_diff_excess = frame_diff - 1; + long int sample_diff_excess = frame_diff_excess * duration; + + /* correct last_tv */ + tv_add_usec(&rs->transmit.last_tv, + sample_diff_excess * USEC_SAMPLE); + LOGP(DLMUX, LOGL_NOTICE, + "Correcting timestamp difference of %ld frames " + "(to %s)\n", frame_diff_excess, + (rs->rx_action == RTP_RECV_APP) ? "app" : "BTS"); + rs->transmit.sequence += frame_diff_excess; + rs->transmit.timestamp += sample_diff_excess; } - diff->tv_usec = to->tv_usec - from->tv_usec; - diff->tv_sec = to->tv_sec - from->tv_sec; + return 0; } /*! \brief encode and send a rtp frame @@ -265,6 +311,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) int duration; /* in samples */ int is_amr = 0, is_bfi = 0; uint8_t dynamic_pt = 0; + int rc; if (rs->rx_action == RTP_RECV_APP) dynamic_pt = rs->receive.payload_type; @@ -275,6 +322,7 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rs->transmit.ssrc = rand(); rs->transmit.sequence = random(); rs->transmit.timestamp = random(); + gettimeofday(&rs->transmit.last_tv, NULL); } switch (frame->msg_type) { @@ -311,26 +359,9 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) return -EINVAL; } - { - struct timeval tv, tv_diff; - long int usec_diff, frame_diff; - - gettimeofday(&tv, NULL); - tv_difference(&tv_diff, &rs->transmit.last_tv, &tv); - rs->transmit.last_tv = tv; - - usec_diff = tv_diff.tv_sec * 1000000 + tv_diff.tv_usec; - frame_diff = (usec_diff / 20000); - - if (abs(frame_diff) > 1) { - long int frame_diff_excess = frame_diff - 1; - - LOGP(DLMUX, LOGL_NOTICE, - "Correcting frame difference of %ld frames\n", frame_diff_excess); - rs->transmit.sequence += frame_diff_excess; - rs->transmit.timestamp += frame_diff_excess * duration; - } - } + rc = correct_timestamp(rs, duration); + if (rc) + return 0; if (is_bfi) { /* In case of a bad frame, just count and drop packt. */ -- 1.8.1.5 --------------070804050601000205010809-- From jolly at eversberg.eu Fri Mar 16 07:14:23 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Fri, 16 Mar 2012 08:14:23 +0100 Subject: [PATCH 9/9] Fixed problem of mute audio on some calls Message-ID: When reading from RTP socket, the first read() may fail right after connecting to remote socket. Subsequent read() will work as it should. If the remote socket does not open fast enough, the transmitted RTP payload can cause an ICMP (connection refused) packet reply. This causes the read to fail with errno=111. In all other error cases, the errno is logged at debug level. In all error cases, reading is not disabled. --- openbsc/src/libtrau/rtp_proxy.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 88753b6..bb158e8 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -503,9 +503,16 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss) return -ENOMEM; rc = read(rss->bfd.fd, msg->data, RTP_ALLOC_SIZE); + if (rc == 0) + goto out_free; if (rc <= 0) { - rss->bfd.when &= ~BSC_FD_READ; - return rc; + /* Ignore "connection refused". this happens, If we open the + * socket faster than the remove side. */ + if (errno == 111) + return 0; + DEBUGPC(DLMUX, "Read of RTP socket (%p) failed (errno %d)\n", + rs, errno); + goto out_free; } msgb_put(msg, rc); -- 1.8.1.5 --------------050303020108080701030307-- From jolly at eversberg.eu Fri Mar 16 07:14:23 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Fri, 16 Mar 2012 08:14:23 +0100 Subject: [PATCH 9/9] Fixed problem of mute audio on some calls Message-ID: When reading from RTP socket, the first read() may fail right after connecting to remote socket. Subsequent read() will work as it should. If the remote socket does not open fast enough, the transmitted RTP payload can cause an ICMP (connection refused) packet reply. This causes the read to fail with errno=111. In all other error cases, the errno is logged at debug level. In all error cases, reading is not disabled. --- openbsc/src/libtrau/rtp_proxy.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 88753b6..23d0d1d 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -503,9 +503,16 @@ static int rtp_socket_read(struct rtp_socket *rs, struct rtp_sub_socket *rss) return -ENOMEM; rc = read(rss->bfd.fd, msg->data, RTP_ALLOC_SIZE); - if (rc <= 0) { - rss->bfd.when &= ~BSC_FD_READ; - return rc; + if (rc == 0) + goto out_free; + if (rc < 0) { + /* Ignore "connection refused". this happens, If we open the + * socket faster than the remove side. */ + if (errno == ECONNREFUSED) + goto out_free; + DEBUGPC(DLMUX, "Read of RTP socket (%p) failed (errno %d, " + "%s)\n", rs, errno, strerror(errno)); + goto out_free; } msgb_put(msg, rc); -- 1.8.1.5 --------------060407040809040206020102-- From jolly at eversberg.eu Thu Mar 8 13:39:19 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 8 Mar 2012 14:39:19 +0100 Subject: [PATCH] Add support for AMR frames to MNCC/RTP interface Message-ID: AMR rate is currently fixed to 5.9k. --- openbsc/src/libmsc/gsm_04_08.c | 1 + openbsc/src/libtrau/rtp_proxy.c | 35 ++++++++++++++++++++++++++++++----- 2 files changed, 31 insertions(+), 5 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index df93433..a0650ab 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -2953,6 +2953,7 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg) case GSM_TCHF_FRAME: case GSM_TCHF_FRAME_EFR: case GSM_TCHH_FRAME: + case GSM_TCH_FRAME_AMR: /* Find callref */ trans = trans_find_by_callref(net, data->callref); if (!trans) { diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 143bfa0..913d64d 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -192,21 +192,35 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data) return -EINVAL; } break; + case RTP_PT_AMR: + break; default: DEBUGPC(DLMUX, "received RTP frame with unknown payload " "type %d\n", rtph->payload_type); return -EINVAL; } - new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + payload_len, - "GSM-DATA"); + if (rtph->payload_type == RTP_PT_AMR) { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + 1 + + payload_len, "GSM-DATA"); + } else { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + + payload_len, "GSM-DATA"); + } if (!new_msg) return -ENOMEM; frame = (struct gsm_data_frame *)(new_msg->data); frame->msg_type = msg_type; frame->callref = callref; - memcpy(frame->data, payload, payload_len); - msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + if (rtph->payload_type == RTP_PT_AMR) { + frame->data[0] = payload_len; + msgb_put(new_msg, sizeof(struct gsm_data_frame) + 1 + + payload_len); + memcpy(frame->data + 1, payload, payload_len); + } else { + msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + memcpy(frame->data, payload, payload_len); + } *data = new_msg; return 0; @@ -264,6 +278,11 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) payload_len = RTP_LEN_GSM_HALF; duration = RTP_GSM_DURATION; break; + case GSM_TCH_FRAME_AMR: + payload_type = RTP_PT_AMR; + payload_len = frame->data[0]; + duration = RTP_GSM_DURATION; + break; default: DEBUGPC(DLMUX, "unsupported message type %d\n", frame->msg_type); @@ -305,7 +324,13 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rtph->timestamp = htonl(rs->transmit.timestamp); rs->transmit.timestamp += duration; rtph->ssrc = htonl(rs->transmit.ssrc); - memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, payload_len); + if (frame->msg_type == GSM_TCH_FRAME_AMR) { + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data + 1, + payload_len); + } else { + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, + payload_len); + } msgb_put(msg, sizeof(struct rtp_hdr) + payload_len); msgb_enqueue(&rss->tx_queue, msg); rss->bfd.when |= BSC_FD_WRITE; -- 1.8.3.2 --------------090303090405010206070901-- From jolly at eversberg.eu Thu Mar 8 13:39:19 2012 From: jolly at eversberg.eu (Andreas Eversberg) Date: Thu, 8 Mar 2012 14:39:19 +0100 Subject: [PATCH] Add support for AMR frames to MNCC/RTP interface Message-ID: AMR rate is currently fixed to 5.9k. --- openbsc/src/libmsc/gsm_04_08.c | 1 + openbsc/src/libtrau/rtp_proxy.c | 53 ++++++++++++++++++++++++++++++++++++----- 2 files changed, 48 insertions(+), 6 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index df93433..a0650ab 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -2953,6 +2953,7 @@ int mncc_tx_to_cc(struct gsm_network *net, int msg_type, void *arg) case GSM_TCHF_FRAME: case GSM_TCHF_FRAME_EFR: case GSM_TCHH_FRAME: + case GSM_TCH_FRAME_AMR: /* Find callref */ trans = trans_find_by_callref(net, data->callref); if (!trans) { diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c index 143bfa0..95729ef 100644 --- a/openbsc/src/libtrau/rtp_proxy.c +++ b/openbsc/src/libtrau/rtp_proxy.c @@ -192,21 +192,41 @@ static int rtp_decode(struct msgb *msg, uint32_t callref, struct msgb **data) return -EINVAL; } break; + case RTP_PT_AMR: + break; default: DEBUGPC(DLMUX, "received RTP frame with unknown payload " "type %d\n", rtph->payload_type); return -EINVAL; } - new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + payload_len, - "GSM-DATA"); + if (payload_len > 33) { + DEBUGPC(DLMUX, "RTP payload too large (%d octets)\n", + payload_len); + return -EINVAL; + } + + if (rtph->payload_type == RTP_PT_AMR) { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + 1 + + payload_len, "GSM-DATA (AMR)"); + } else { + new_msg = msgb_alloc(sizeof(struct gsm_data_frame) + + payload_len, "GSM-DATA"); + } if (!new_msg) return -ENOMEM; frame = (struct gsm_data_frame *)(new_msg->data); frame->msg_type = msg_type; frame->callref = callref; - memcpy(frame->data, payload, payload_len); - msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + if (rtph->payload_type == RTP_PT_AMR) { + frame->data[0] = payload_len; + msgb_put(new_msg, sizeof(struct gsm_data_frame) + 1 + + payload_len); + memcpy(frame->data + 1, payload, payload_len); + } else { + msgb_put(new_msg, sizeof(struct gsm_data_frame) + payload_len); + memcpy(frame->data, payload, payload_len); + } *data = new_msg; return 0; @@ -264,6 +284,11 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) payload_len = RTP_LEN_GSM_HALF; duration = RTP_GSM_DURATION; break; + case GSM_TCH_FRAME_AMR: + payload_type = RTP_PT_AMR; + payload_len = frame->data[0]; + duration = RTP_GSM_DURATION; + break; default: DEBUGPC(DLMUX, "unsupported message type %d\n", frame->msg_type); @@ -291,7 +316,18 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) } } - msg = msgb_alloc(sizeof(struct rtp_hdr) + payload_len, "RTP-GSM-FULL"); + if (payload_len > 33) { + DEBUGPC(DLMUX, "RTP payload too large (%d octets)\n", + payload_len); + return -EINVAL; + } + + if (frame->msg_type == GSM_TCH_FRAME_AMR) + msg = msgb_alloc(sizeof(struct rtp_hdr) + payload_len, + "RTP-GSM (AMR)"); + else + msg = msgb_alloc(sizeof(struct rtp_hdr) + payload_len, + "RTP-GSM"); if (!msg) return -ENOMEM; rtph = (struct rtp_hdr *)msg->data; @@ -305,7 +341,12 @@ int rtp_send_frame(struct rtp_socket *rs, struct gsm_data_frame *frame) rtph->timestamp = htonl(rs->transmit.timestamp); rs->transmit.timestamp += duration; rtph->ssrc = htonl(rs->transmit.ssrc); - memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, payload_len); + if (frame->msg_type == GSM_TCH_FRAME_AMR) + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data + 1, + payload_len); + else + memcpy(msg->data + sizeof(struct rtp_hdr), frame->data, + payload_len); msgb_put(msg, sizeof(struct rtp_hdr) + payload_len); msgb_enqueue(&rss->tx_queue, msg); rss->bfd.when |= BSC_FD_WRITE; -- 1.8.1.5 --------------040208000603050009060705--