This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Nik Pakar nikpakar at gmail.comIt 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 <nikpakar at gmail.com> 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 <nikpakar at gmail.com> 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 <nikpakar at gmail.com> 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 <nikpakar at gmail.com> 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 <nikpakar at gmail.com> 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: <http://lists.osmocom.org/pipermail/openbsc/attachments/20120307/e6745149/attachment.htm>