Hi!
As I know that several of you, including @cquirin and @nt2mku have previously been thinking about carrying PCM30 with IKZ50 over icE1usb/TDMoIP: I’ve now created a redmine issue where we can track the requirements and implementation options of doing that. This is just a quick annoncement here, as some people are reading the forum but are not developers and hence not following new issues in redmine.
Hi!
thanks to the Czech implementation of CAS (signalling K), which has a short “seizure acknowledgement” time, I have never had a transmission over a longer distance via TDMoIP fail because of this. Exchanges or converters that strictly followed the standard, the added delay will unfortunately exceed the set limit of 70 ms 
Unfortunately, I still can’t connect remote “clients” via CAS/R2 or CAS/pulse via TDMoIP (e.g. RAD ipmux) And I have to use asterisk/dahdi.
If this ever works via icE1usb, I’m interested 
You probably won’t have the main problem we introduced in the Czech Republic :-(.
HI!
With regard to this point:
Wouldn’t it be enough to transmit also TS0 in this case? (As far as I understand, this is not transmitted for PRI connections with octoi, or is that wrong?) The TDMoIP connection should be bit transparent in this case, right?
This is true for a simple/dumb TDMoIP (like putting E1 multiframes into UDP packets as I’ve seen with RAD equipment, or in MPLS like it is done by Juniper.
For OCTOI specifically, even transporting TS0 transparently wouldn’t help in its current form, particularly when performing error recovery from lost packets/frames as well as the way how we repeat previous timeslot contents in case of missing frames. The original OCTOI design looks at replicating each TS at the remote end, and not entire multiframes with proper alignment.
Specifically also, the icE1usb firmware and USB transport is currently not prepared for this. As @tnt raised in the related RetroNetCall and in other places: It’s not a lot of work, but it’s tricky and (my opinion) we’d need really good unit tests to know if it does what it’s supposed to do.
That also means that such signaling could never be carried over GEO satellite, back in the day. I would have assumed all signaling protocols would have timers/timeouts that cover at least the usual GEO satellite round-trip-time, but it seems that was not the case
You would need some custom software that would “locally spoof” the seizure acknowledgement instead of waiting for the remote side. Technically likely possible, but it would be a very custom hack somebody with the need for it (e.g. you) would have to implement…
Hi,
according to my experience, transmission in ts0 and in ts16-0 in MF is really very dependent on specific arrangements, and in “national bits” it sometimes requires specific bits, otherwise the MUXs do not work. But usually it can be set statically and it works. In a multiframe, where small bit error rates are usually ignored even by end devices, the correction by repeating the previous correct frame in the multiframe would probably be sufficient.
No. This signaling was designed only for access network (in Czech, I don’t know how else in the world), and the customer was never connected to the satellite. It wouldn’t even be cost-effective at that time.
The satellite only had an operator using SS5, and there it expected more delay.
I understand…it wouldn’t be easy to avoid channel blockages in case the confirmation is not sent by the remote exchange. Even the introduction to IDLE was modified here, and it caused a lot of problems at the time. As a result, the transmission medium would have to understand the signaling enough if it were to be interfered with.
I’m planning the timeout where it can be extended on the exchange side (UE200) so that MFC/R2 is possible - the delay doesn’t matter there, and if it’s agreed on the bits then it will work. Thanks to the delay, the MFCR2 would be pretty slow - more interesting to show visitors
By the way, can you do SS5 on a yate? I tried it once, but I’m not too sure on the EWSD side, I don’t have any counterpart.
I don’t think so, at least I’m not aware it is supported. in yate
@jolly implemented an cc/osmo-cc-ss5-endpoint: OsmoCC SS5 endpoint - Osmocom gitea for osmo-cc. Using that you could interface with other osmo-cc endpoints like SIP, osmocom-analog, osmo-v5, etc.
You cannot do SS5 on EWSD unless you have LTGD with propper card. These LTGD were used in international exchanges. If you have one, we should try some interconnection with my software SS5 implementation.
Yes, this is how it is described in the doc, but I was told that there was a loadtype for the newer LTG, and the old HW was not needed. Unfortunately, it’s a matter of guessing, because I’ve never found a description of the loadtype for individual markets anywhere, and if it’s not found in data regen, I have to try one by one to see if it happens to run when configured.
If the old HW LTGD is really needed, I can’t do it