Restcomm weekly meeting notes May 3rd, 2017
73 views
Skip to first unread message
Jean Deruelle
May 4, 2017, 6:32:43 AM5/4/17
to mobicents-public, rest...@googlegroups.com
Don't forget to register for our Restconn - Restcomm Conference in Czech Republic, Prague from 23 to 25 May, register at https://www.eventbrite.com/e/restconn-tickets-19010382566
Attendees:
Sergey P, Kostyantyn, George, Orestis, Lefteris, Guilherme, Antonis, Despina, Sergey V, Jaime, Alex
SummarySergey P, Kostyantyn, George, Orestis, Lefteris, Guilherme, Antonis, Despina, Sergey V, Jaime, Alex
#1 JAIN SLEE - Telscale JAIN SLEE 7.0 moving forward with EAP 7 support. Release expected this month
#2 Load Balancer - Customer support. Improvements on HTTP response size limits
#3 Restcomm Connect and RVD - Restcomm 8.2.0 in progress. RVD UI revamped to match Dashboard and Olympus. RVD Video features work in progress. Multiprovider Support. Multitenancy Organizations work
#4 Restcomm Video - XMS - Video Conferencing successfully tested. Still need to iron out some issues and then update TADHack environment
#5 Restcomm as a Service - SMSC Productization
#6 Restcomm SDKs/Clients/WebRTC Test Tool - Continuous Testing on Olympus UI in progress, webrtc screensharing progress. Olympus Web improvements and new UI merged to master
#3 Restcomm Connect and RVD - Restcomm 8.2.0 in progress. RVD UI revamped to match Dashboard and Olympus. RVD Video features work in progress. Multiprovider Support. Multitenancy Organizations work
#4 Restcomm Video - XMS - Video Conferencing successfully tested. Still need to iron out some issues and then update TADHack environment
#5 Restcomm as a Service - SMSC Productization
#6 Restcomm SDKs/Clients/WebRTC Test Tool - Continuous Testing on Olympus UI in progress, webrtc screensharing progress. Olympus Web improvements and new UI merged to master
#8 Restcomm UI/UX Design - Marketing work
#9 Media Server -no news
#10 SIP Servlets/SIP Stack/PerfCorder - Non blocking work in progress
#11 jSS7/SMSC/USSD/CAMEL GW - jSS7 7.3 planned and SMPP release planned for next week
#12 GeoLocation/GMLC - no news
#13 jDiameter/Charging Server - DRA support and OCS Health monitoring module. New sprint started
#9 Media Server -no news
#10 SIP Servlets/SIP Stack/PerfCorder - Non blocking work in progress
#11 jSS7/SMSC/USSD/CAMEL GW - jSS7 7.3 planned and SMPP release planned for next week
#12 GeoLocation/GMLC - no news
#13 jDiameter/Charging Server - DRA support and OCS Health monitoring module. New sprint started
Hi @/all
Agenda
#1 JAIN SLEE
#2 Load Balancer
#3 Restcomm Connect & RVD
#4 RestComm Video - XMS
#5 Restcomm as a Service
#6 Restcomm SDKs/Clients
#7 Restcomm UI/UX Design
#8 Media Server
#9 SIP Servlets/SIP Stack
#10 jSS7/SMSC/USSD
#11 GeoLocation/GMLC
#12 jDiameter/Charging Server
#2 Load Balancer
#3 Restcomm Connect & RVD
#4 RestComm Video - XMS
#5 Restcomm as a Service
#6 Restcomm SDKs/Clients
#7 Restcomm UI/UX Design
#8 Media Server
#9 SIP Servlets/SIP Stack
#10 jSS7/SMSC/USSD
#11 GeoLocation/GMLC
#12 jDiameter/Charging Server
yes, I have update for 3 weeks
Finished with TelScale jSS7 7.2.2 and RAs for RestComm and TelScale JSLEE 7.x
Worked and tested on SMPP Extensions and SMPP RA for RestComm and TelScale JSLEE
- Worked on Diameter with creating single module jdiameter-ha-impl. Was added changes to Cluster on master and infinispan branches
Tried to create single module (jboss instead of jboss-5 and wildfly-10) in SIP-HA project, but SIP-HA jboss-5 module has ManagedMobicentsSipCache and JBossCacheSipCache that must be more investigated for this purpose (creating single module). So now SIP-HA has both modules (jboss-5 and wildfly-10), I only removed ManagedMobicentsSipCache and JBossCacheSipCache from last one with all tests
Rebuild Cluster, Diameter, SIP HA and all CI jobs for RestComm JSLEE Release 7.0.1.Final
- Now I have 5 failed tests on TCK
Started preparing Cluster, Diameter and SIP HA for TelScale JSLEE 7.0.0
Investigated OVOO/Unifonic SMSC Gateway ticket
- Investigated tickets about working with Databases in SLEE application
and plan:
Fix TCK bugs
Finish with SMPP
Finish with RestComm JSLEE 7.0.1
Prepare all for TelScale JSLEE 7.0.0: Diameter, SS7, SMPP, etc
Build TelScale JSLEE 7.0.0 (7.0.1)
Fix all issues on github for 7.1.0
- Build RestComm/TelScale JSLEE 7.1.0
@SergeyLee @brainslog diameter is ready for jboss 5 and wildfly 10 now as a single module ?
and I forgot about JSLEE 6.1.6 with this Diameter
@SergeyLee you backported the changes from jSS7 7.3 to jSS7 7.2 for being able to run on both jboss 5 and wildfly ?
about releasing a jSS7 7.3 that you can use in SLEE 7
but if you have jSS7 7.2.2 working before 7.3 is out that works too
when do you plan Telscale SLEE 7 release ?
what is left on SMPP for the release ?
except today
and this contributor ...
@SergeyLee ok , what is left on SMPP ?
I guess if you plan next week we may be able to ship jSS7 7.3
ok, so I should to add building jSS7 7.3 before
please include it
just wanted to share this contributor has commited a patch for that issue
and followed by comments for some fixes
i think is ready to merge
also, we should look for something more challenging to give him
apparently he is interested in joining telestax
or both
shoudl be ported to all active branches
@SergeyLee can you also check the list of issues we can give to this contributor and sync up with @jaimecasero on that ?
but not sure its good if he cant reproduce it
at least it has something to do with activities,and hopefully the eventrouter
now I want to fix TCK bugs and build new RestComm JSLEE Release
it needs to happen no later than 17th of May
@knosach can you update ?
This is my first business day after GSS training. Half day I was in visa center so not so much news:
Working on issue with TooLongFrameException in http response.
Working on issue with TooLongFrameException in http response.
@gvagenas can you update for you and the team ?
So from my side, I prepared patch for issue
- #2117 about a race condition when using LCM that prevents Call actors to be properly cleaned up
- #2121 about a workaround for Supervisor endpoint that blocks waiting for MonitoringService metrics. The real reason of this issue is not yet clear
- Zendesk ticket 34217 about Dial forking with Fone.do DIDs (work in progress)
Also prepared 8.2.0 sprint 2 that includes
- P2P CI perf job
- Fix Conference perf job`
- PR 1940 for call sid
- PR for issue 708 about Regex support
thats all from me
@croufay anything from you?
@otsakir anything from your side?
RVD
- Wrapped RVD UI revamp, ran some tests and merged to master. The binary will be tested in staging before getting uploaded to cloud. This wrapps RVD Milestone 2.
RestComm/visual-designer#121 - Started working on Milestone 3 that includes RCML Video support in RVD after discussing with Gui. Currently working on RestComm/visual-designer#128.
- Also fixed #118 and #48 (bug)
- Investigated running standalone RVD and posted some comments on that.
Restcomm/RVD
- Reviewed design document for porting project management to Dashboard. Broughts up some issues on authentication. I will need some more time to investigate the two possible solutions (using SSL certificates or custom shared tokens)
that's all from me
@ghjansen any update on Restcomm-Connect from your side ?
@leftyb your update?
@maria-farooq your update?
@maria-farooq @leftyb when do we plan to have new RVD UI on staging ?
@gvagenas #2117 was unplanned ?
Not any updates from me here.
@deruelle #2121 is linked to a cloud incident (ZD-34261). #2117 came up during review and testing of PR-1940
#4 RestComm Video - XMS
@ghjansen can you please update ?
- Restcomm/Restcomm-Connect#2056: Contributed in the investigation of the issue
- Reported issues Restcomm/Restcomm-Connect#2069, Restcomm/Restcomm-Connect#2070 and Restcomm/Restcomm-Connect#2077
- Restcomm/Restcomm-Connect#1552: Had the first video conference working with Olympus, there are only few pendings related to text overlay that i'm taking care now also in sync with Dialogic
- Merged master into Restcomm/Restcomm-Connect PRs #1946 and #1892, so video Play and Record verbs can be merged back to master
- Restcomm/Restcomm-Connect#2055: Discovered an issue with the configuration file for TADHack docker container, also a jboss-cli bug (https://issues.jboss.org/browse/WFLY-1664) that has a workaround which seems to be working well now
- Synched with @otsakir about RVD work for video compatibility
- right now finishing a adjustment i noticed for Restcomm/Restcomm-Connect#1552 about text overlay, after that i will merge everything again and create the new container to update TADHack env
Congrats !! That's a big milestone !
one thing I didn't test is the Olympus Mobile clients with it, did you try that ?
!
sorry the phone just ringed
@deruelle i tested one day using Olympus on mobile and the video didnt worked
the sintoms was that, for those who were already in the conference, there was the beep of somebody that joined, but the video frame inside the conference and for the mobile client was black
also, from mobile side the call was kept ringing
@ghjansen the docker image is ready now to be able to update TADHack ?
the final test is pending on my instance, so im just finishing that detail with text overlay to create the new build
sure, agreed
I meant all build and startup issues are fixed for Docker right, no blocker anymore ?
hope no more nasty issues show up
thanks, please create an issue about the mobile SDKs with videoconferencing
so we have it tracked down
#5 Restcomm as a Service
@leftyb can you please update
I believe @maria-farooq is no back yet
Not too much from my side:
Apart from the GSS Training last week.
- Worked and initial testing on latest RC docker image (Controlled RC link to LB after RC is properly up.)
- Productization of the SMSC container (Work in-progress).
- Participated on various meetings.
- Provided support on an issue that came up on cloud.
That is all from me.
Productization of the SMSC container => what do we have so far ?
On the SMSC working now on the perfcorder integration. Will push by the end of the day.
#6 Restcomm SDKs/Clients
Last week wasn't full as I was traveling and also took some time off. So for the remaining of the week:
- Followed up with backlog that had grown pretty big due to my trip in India and trip logistics
- Followed up with android-QoS, to plan for some marketing to go together with upcoming release
- Followed up with screen sharing partner, still having issue getting the second call issue resolved, we 'll be meeting tomorrow to sync on that
- Worked on various customer issues
Fixed Android sprint issues:
- Fixed #556: Add more UI tests apart from outgoing call
- Fixed #555: Introduce REST client facilities in UI tests
Wrapped up sprint and started new one together with housekeeping in GitHub/ZenHub, did retrospective and sprint planning meeting with Jean
That's all from me @deruelle
hopefully screen sharing gets to move a bit
Not much for R&D from my side for the last 2 weeks. I am working with the marketing team on product presentations. Half of my
new sprint started yesterday is focused on marketing needs. Apart of that I will work to finalise consoles UX revamp.
new sprint started yesterday is focused on marketing needs. Apart of that I will work to finalise consoles UX revamp.
Thats from me @deruelle
#8 Media Server
@hrosa is off this week
#9 SIP Servlets/SIP Stack
@jaimecasero can you update ?
im starting roadmap activities again
already reworked the spritn board
workign on nonBlocking connect feature
last week was GSS training, as everybody knows
so thats all from me
do you have the link to it ?
anything missing?
cool I thought non blocking would take longer to wrap up
well, i expect to close nonBlocking in 1 weel, and there is one week left until sprint end
lets see anyway
i will close nonBlocking first
nonBlocking is mostly implemented, but testing proved it was dropping some packets
so,i need to find this scenario,create tests and fix
probably some concurrent condition
#10 jSS7/SMSC/USSD
My update is for 2 weks
SMSC GW:
- checking of a case of delayed of sending submit_sm_response back to a SMPP client
We found a root reason.
To fix it we need to update SMPP RA so it will sends messages in asynch way - I checked logs from one of our customers and found errors that may be of lack of threads locking
in delivery part of SMSC GW
I prepared a patvh for this, it is still needed to test at the customer side - checked and committed 3 PRs from one of our contributors:
RestComm/smscgateway#200 - MProcMessage - adding of MessageId parameter
RestComm/smscgateway#201 - Adding of processing time into CDRs
RestComm/smscgateway#202 - SLEE based statistics in TX/RX SMPP Services
I committed into a master branch, but manual updates are missed, we still need them - checking PR for RestComm/smscgateway#179 - Making of message routing depending on TVL value
This is not yet fully done too - provided fix for issue RestComm/smscgateway#194 - Exception when creating of createDeliveryReceiptMessage() in TxSbb
- RestComm/smscgateway#195 - http get replace + with space number - fixed by Tran
- fixed ticket - RestComm/smscgateway#203 - Missing of originatorSccpAddress in diameter requests (AVP code 2008)
- accepted PR from Tran for RestComm/smscgateway#176 - Authentication with Cassandra by using user and password
- RestComm/smscgateway#205 PR - Add tlv options to Web UI. Update docs. - this is a final fix for an issue:
RestComm/smscgateway#179 - Making of message routing depending on TVL value
JSS7:
- accepted PR for issue RestComm/jss7#223 - SLS should support odd or even number
- fixed RestComm/jss7#235 - fixing issues with m3ua stack options configuring
smpp-extensions / SMPP RA:
- testing jboss5 / WldFly version. It works as expected after some fixes now
We need to merge branch and fix some proviles issues
To make an official release of SMPP-extensions / RA we need to add a manual (this is the biggest missed part) - addeed PR from Tran RestComm/smpp-extensions#12 - linkDropServer need to be considered deliver_sm responded for RECEIVER bind type
that's it from me for today
when do you plan jSS7 7.3 release ?
along with SMPP RA
#11 GeoLocation/GMLC
@FerUy is off
#12 jDiameter/Charging Server
@brainslog can you please update ?
I have been working mostly on Diameter routing issue (RestComm/jdiameter#73) and a resource monitoring feature for OCS.
Also worked on several pending issues and pull requests for Diameter, regarding Sprint1 (https://github.com/RestComm/jdiameter/milestone/5?closed=1) and we've re-arranged the sprints for Diameter and will start the Sprint2 (https://github.com/RestComm/jdiameter/milestone/6) tomorrow.
Also worked on several pending issues and pull requests for Diameter, regarding Sprint1 (https://github.com/RestComm/jdiameter/milestone/5?closed=1) and we've re-arranged the sprints for Diameter and will start the Sprint2 (https://github.com/RestComm/jdiameter/milestone/6) tomorrow.
that's it from me
Not much, I've been working on fixing the video for different resolutions plus a couple fixes/features to the contact list. Will merge the 2.x-PREVIEW branch to master and work on defining a sprint for Olympus as well
there was no sprint yet for Olympus, those were some "loose" pending issues
ok good we are putting proper sprints into this so we stop the looseness :D
that's a wrap up
Jean Deruelle
May 10, 2017, 7:24:39 PM5/10/17
to rest...@googlegroups.com, mobicents-public
Don't forget to register for our Restconn - Restcomm Conference in Czech Republic, Prague from 23 to 25 May, register at https://www.eventbrite.com/e/restconn-tickets-19010382566
Attendees:
Sergey P, Kostyantyn, George, Maria, Orestis, Lefteris, Aziz, Guilherme, Antonis, Despina, Henrique, Sergey V, Jaime, Alex
Sergey P, Kostyantyn, George, Maria, Orestis, Lefteris, Aziz, Guilherme, Antonis, Despina, Henrique, Sergey V, Jaime, Alex
#1 JAIN SLEE - Telscale JAIN SLEE 7.0 moving forward with EAP 7 support. TCK bug on race condition.
#2 Load Balancer - Customer support. Improvements on HTTP response size limits and node failure detection
#3 Restcomm Connect and RVD - Restcomm 8.2.0 in progress. Customer support + Various bug fixes. RVD enhancements for Video. SMS Multiprovider Support completed, Moving to Voice Multiproviders.
#4 Restcomm Video - XMS - Video Text overlay fixes. TADHack environment updated with Video Conferencing. Ironing out a bug on Music on Hold
#5 Restcomm as a Service - SMSC Docker Productization completed and deployed with new Connect upgrade
#6 Restcomm SDKs/Clients/WebRTC Test Tool - Refactor of UI for Messages. WebRTC getStats dumps at end of calls. Customer support
#3 Restcomm Connect and RVD - Restcomm 8.2.0 in progress. Customer support + Various bug fixes. RVD enhancements for Video. SMS Multiprovider Support completed, Moving to Voice Multiproviders.
#4 Restcomm Video - XMS - Video Text overlay fixes. TADHack environment updated with Video Conferencing. Ironing out a bug on Music on Hold
#5 Restcomm as a Service - SMSC Docker Productization completed and deployed with new Connect upgrade
#6 Restcomm SDKs/Clients/WebRTC Test Tool - Refactor of UI for Messages. WebRTC getStats dumps at end of calls. Customer support
#8 Restcomm UI/UX Design - Marketing work
#9 Media Server - Pcap replay tool for unit testing working. Fixed bug on transcoding broken for .wav tracks encoded with ulaw or alaw.
#10 SIP Servlets/SIP Stack/PerfCorder - Non blocking work in progress. Graceful startup working, fine tuning may still be needed
#11 jSS7/SMSC/USSD/CAMEL GW - jSS7 7.3 planned and SMPP release planned for this week. Lots of PR for SMSC
#10 SIP Servlets/SIP Stack/PerfCorder - Non blocking work in progress. Graceful startup working, fine tuning may still be needed
#11 jSS7/SMSC/USSD/CAMEL GW - jSS7 7.3 planned and SMPP release planned for this week. Lots of PR for SMSC
#12 GeoLocation/GMLC - no news
#13 jDiameter/Charging Server - Customer support. Mem Lead Fix.Supporting handling of messages from undefined realms brainstorm.
Agenda
#1 JAIN SLEE
#2 Load Balancer
#3 Restcomm Connect & RVD
#4 RestComm Video - XMS
#5 Restcomm as a Service
#6 Restcomm SDKs/Clients
#7 Restcomm UI/UX Design
#8 Media Server
#9 SIP Servlets/SIP Stack
#10 jSS7/SMSC/USSD
#11 GeoLocation/GMLC
#12 jDiameter/Charging Server
#2 Load Balancer
#3 Restcomm Connect & RVD
#4 RestComm Video - XMS
#5 Restcomm as a Service
#6 Restcomm SDKs/Clients
#7 Restcomm UI/UX Design
#8 Media Server
#9 SIP Servlets/SIP Stack
#10 jSS7/SMSC/USSD
#11 GeoLocation/GMLC
#12 jDiameter/Charging Server
#1 JAIN SLEE
I worked on TCK bug with transactions. And found strange behaviour for TCK Testsuite with JSLEE7/Wildfly.
Now I am investigating TCK Testsuite on both servers (JBoss 5 and WildFly) and have some notices on RMI usage.
im trying to help Sergey
apparently wildfly is using more threads than expected
there is an SLEE impl based on threadlocals that is failing becuase threading is different
yes, and its RMI try to use stream protocol instead of SimpleOpProtocol
but we still need to find root cuase
sure
but I wrote that we have not bugs with threadlocals
only with RMI
I thought we passed the TCK for wildfly community version already
what changed ?
if something has changed in the environment that affects those assumptions, then we may need to revisit the threadlocall impl
since it depends on whether the same thread that started the TX is reused to finish it
but I guess that I found that TCK Testsuite was migrated with little bug... after more deeper log inspecting
or without some flag for RMI
let discuss this in slack
what else on SLEE ?
to be able to release it ?
1-2 hours
and continue investigating TCK after that
#2 Load Balancer
@knosach can you update ?
Last week I worked on:
- fixed RestComm/load-balancer#103 (TooLongFrameException in HttpChunkAggregator). Completely removed HttpChunkAggregator form logic of LB. Need to update on cloud.
- almost finish with RestComm/load-balancer#109 (Remove Node if get HTTP response with error)
#3 Restcomm Connect & RVD
I worked on the following:
- Restcomm/Restcomm-Connect#1940 for call-sid to include instance id
- Restcomm/Restcomm-Connect#2007 for multi-provider extension
- Restcomm/Restcomm-Connect#1806 for REGEX support on the IncomingPhoneNumbers
- Restcomm/Restcomm-Connect#1023 exception on P2P Message
- Restcomm/Restcomm-Connect#2134 ExtensionsConfiguration bug
- Telscale Restcomm-Connect testsuite fixes
- Zendesk 34261 cloud incident
Currently I am working on a patch for 34261
BUSY outgoing calls are not properly cleaned up
And from the jmap I can see the same for Canceled outgoing calls but haven’t confirmed that with the testsuite yet
Thats all from me
@croufay do you have an update here?
@otsakir your update?
RVD
- Added Video support to RVD. Enabled new new video attributes to RCML and UI and make this options through configuration. Issues: visual-designer#128, visual-designer#130, visual-designer#130, visual-designer#139 and restcomm#2133.
- Started working on RVD standalone operation and currently on issue #138 on configuration decoupling. have some trouble on
how i could test this thing before switching to staging environment.
that's all for me
@leftyb your update?
@maria-farooq your update?
I am logged in from mobile app and dont have detailed update but summary is like following
Working on organizations phase 1 And after first round of implementation i am working on test suit and fixing several issues in there
I think by the end of this week we will be able to start testing on staging
That's all
In github
not much to update:
-SMSC SMPP Simulator changes. RestComm/smscgateway#180
-Voice Design proposals.
-Addressing SMS Merge comments. RestComm/Restcomm-Connect#2007
-SMSC SMPP Simulator changes. RestComm/smscgateway#180
-Voice Design proposals.
-Addressing SMS Merge comments. RestComm/Restcomm-Connect#2007
that is all. I sholud finish with one implementation 2b tmrw
great work @abdulazizali77 . We need test cases for the Sms and to prepare the Extension API before we start the Voice part
Hi, Team... sorry I had carpool and dog walking duties this morning-- my wife is out of town
Great to have to at gitter Aziz
Great work on sms multi provider support
Great work on sms multi provider support
thanks @gvagenas
@maria-farooq looking forward to testing the changes to org on staging next week
@otsakir thanks for making the RVD Video happens on time for Restconn ;)
and @gvagenas for the PR reviews on time
speaking of video
#4 RestComm Video - XMS
- RestComm/Restcomm-Connect#1552: Finished the adjustments related to text overlay for video, setting the respective attribute on participant's media session instead of conference media session
- Synched with Dialogic on Restconn presentation
- RestComm/Restcomm-Connect#2130: Merged all work for video, built new docker container and updated TADHack environment
now troubleshooting something in TADHack env
what is the plan for cloud.restcomm.com today?
@ghjansen do you think you can deploy a new version including the RVD changes from @otsakir today
i guess it would be better to patch including new RVD changes @deruelle … but i can try as it fits better
we need to merge it to master first
right
@deruelle i understand when you said "deploy a new version” to create new binaries etc, so i said that maybe include the changes from @otsakir in the running environment would be easier and faster
but thats only an ideia, no problem to build from sketch
and update TADHack when binaries are ready
but it's better to run on a tagged version
ok, let me investigate the current issue an i’ll take care of it
looks like we should be able to finish Video RCML on time for Restconn right @ghjansen ?
that would mean only API will be left for after Restconn
and i’m rushing to have it, believe me
thanks @ghjansen
#5 Restcomm as a Service
@leftyb @maria-farooq @abdulazizali77 @knosach any updates here ?
My update:
Mainly last week working on SMSC docker container productization and cloud upgrade:
- automatic configuration.
- perfcorder integration.
- Logentries + slack integration.
Recover Staging SMSC server after issues we had with specific node.
Testing new sip-servlet modification for LB keepalive after RC is properly up.
- Using SIPP to generate calls and launching second node most of the time we had 100% success (Some tests we had 2 to 6 calls failing).
Gave support on various issues on cloud.
- Client issue WAV files encoding.
- Unexpected node removal (collect logs and investigation in progress).
preparing for cloud upgrade with latest new developments and patches.
That is my main update
@leftyb on
Using SIPP to generate calls and launching second node most of the time we had 100% success (Some tests we had 2 to 6 calls failing).
SIMULTANEOUS_CALLS: 100, MAXIMUM_CALLS: 700, CALL_RATE: 30this is an example of a test case.
I tested with old container.
so we can push ahead with this improvement but can you collect the logs for @knosach investigation
so we go for 0 failed calls all time
unless the traffic peak is breaking the container
but yes let me collect logs on that failed calls.
if we open the traffic to a fresh initiated container, it will take a bit of time to get to the best performance
so even a 30 CAPS rate could cuase some problems for initial calls
ideally LB should open the "tap" slowly
not sure this is possible
But I think for our current load, the solution is good.
I mean my tests were way much more than the usual current traffic .
@atsakiridis can you update ?
Some work on current sprint:
- Fixed android #577: Fix xirsys credentials for Android
- Working on android issue: #567: Convey delivery status in the UI of the messages:
Adaptor, UI changes, db schema changes are in place and now working on introducing DB upgrade logic, so that you guys don't have to wipe all contacts out when this fix lands to master ;), and so that we have a way to handle upgrades going forward
Community/Partner/Contributors:
- Followed up with community, contributors & interns
- Had meeting with screen sharing partner; no news this week due to workload
- Jean had a meeting with android-qos on marketing aspects; partner will be working on integrating android-QoS with Olympus
Internal & serviceability:
- Followed up with various internal discussions & support, investigating 'call already ongoing' issue, still no actionable clues on that :(
- Did some housekeeping in SDKs issues in GitHub
- Updated Olympus code with latest fix in webrtcomm so that we can see WebRTC stats in logs in cloud (issue #113)
- Updated Restcomm Connect wiki on how to run natively on OSX
- Followed up with JJ on his Restconn subject and had meeting about it
Other than that:
- Worked on Restcomm-Connect #1023: Restcomm exception prevents 200 OK response to MESSAGE to be sent to message sender
And finally working on various customer issues, which have been taking most of my time this week
That's all from me @deruelle
Hello?
Thanks
Unfortunately I have been working on it pretty slowly mainly due to customer issues
that spiked this week
#113 is very nice
The only thing is that
for now it's not pretty
I mean formatting is messy
because Google changed some key names in getStats
so I decided to just print it unparsed
for now
But still very valuable info
@marca56 for the getStats output you mean?
in the future
for WebRTC calls
@deruelle right in the future we can consider better reporting for sure
@ipsilantide can you please update ?
@deruelle she won't make it, I think she notified in slack
#8 Media Server
@hrosa can you please update ?
I'm proud to announce a new PCAP framework that allows users to read from PCAP files and inject traffic into the Media Server. This shall prove very useful for testing purposes and others.
RestComm/mediaserver#436
I started to create new test cases for DTMF Detection. This will help us fine-tune in-band DTMF Detection to cover as many clients as possible.
I've also worked on a patch for Media Player. Transcoding was broken for .wav tracks encoded with ulaw or alaw.
I will now prepare a new sprint to start working on Netty migration for RTP stack.
That is all from me.
did you start to run some pcap yet on DTMF ?
;)
love it when a plan comes together slowly but surely
yes
for a couple of RFC2833 cases
it worked fine, so is promising
ideally
we want to create separate test cases for each client & version
or staging for that
as we did in India
#9 SIP Servlets/SIP Stack
on roadmap side
we started a sprint again
to cover remaining of nonBlocking feature
apart form that, ive been involved in other activities not related to this topic
another news is graceful shutdown feature seems to be working as expected
so, we can potentially merge this code and make it available for the community
this has been discussed already with Lefty
thats all from my side
great job on the graceful startup feature :D
if positive i will start perf testing
if that is what you meant
as the "site" generation actvitiy came in the middle
will try to wrap up that soon,and come back to work
#10 jSS7/SMSC/USSD
@vetss can you please update ?
JSS7:
- checked contributors update RestComm/jss7#224 - SCCP Routing based on callingGT (accepted into master branch not fully done, waiting for finishing)
- checking contributors update RestComm/jss7#234 - Adding of CsvStatsPrinter (into JSS7 / SMSC stat) - added now
- accepted PR RestComm/jss7#194 - Issue#192 sccprelay (into a non-netty branch only, simple update into RA is needed)
I need to add also a fix for SCTP lib (and a fix from Sergey Lee for releasing) before JSS7 7.3 releasing
smpp-extensions, smpp RA:
- checked and commented of PR for asynch message sending in SMPP RA - RestComm/jain-slee.smpp#8
for this task we need: unit test (desirable), update for SMSC GW SBB, test at a live server - after checking customer logs - found SmppActivity leaks in case of no submit_sm_response from a peer - RestComm/jain-slee.smpp#9
the most probably it is from missed events from cloud-hopper side and it is difficult to reproduce
my opinion we need to add a timer (as a workaround) and logging and try to find out a case and how to fix it
As we agreed we will release SMPP RA without issues 8 and 9
SMSC GW:
- accepting a PR for issue RestComm/smscgateway#191 - Enhancement: Enable sending of arbitrary Tlv/Optional Parameters in SMPP Simulator
- accepting a PR for issue RestComm/smscgateway#201 - Adding of processing time into CDRs (added my fixes, more or less done, needed more clear counters desription)
- accepting a PR for issue RestComm/smscgateway#200 - MProcMessage - adding of MessageId parameter (the issue is fixed now)
- found wrong logging for issue RestComm/smscgateway#186 - SLEE event issues : events from different Activitues throws at different threads (fixed)
that's it for today
sorry, JSS7 release we need to fix into SCTP lib (that is for diameter)
on RestComm/jss7#224 ? what effort is left to do it for master as well ?
what is the planned date for jSS7 7.3 ?
224 - manual & GUI, but it is not included in non-netty branch (at least now), so no affect to JSS7 7.3
ok
Thanks @vetss
#11 GeoLocation/GMLC
@FerUy can you update ?
hi @deruelle
Another busy week on other tasks and travelling, so not as much progress I was planning, which is the following:
GMLC
2.0.0.FINAL-Sprint1
- RestComm/gmlc#1, RestComm/gmlc#91 and RestComm/gmlc#92.
- For the latter, we need RestComm/jss7#100 to be finished, so I'm resuming on that too.
JAIN-SLEE.Diameter
- Resuming work also with RestComm/jain-slee.diameter#15 and RestComm/jain-slee.diameter#16 (which are already very big and pretty advanced). Pull requests will be pushed once RestComm/jdiameter#48 is peer reviewed and merged with master (or I could do the PRs as WIPs warning @brainslog about it).
Also had a call with @atsakiridis and @jjsenay regarding an IoT solution to discuss in Restconn which concerns the whole Geolocation project, very exciting.
And that's it for this week.
#12 jDiameter/Charging Server
@brainslog can you please update ?
Regarding Diameter I have started Sprint #2, with the following issues:
- Fixing a possible memory leak for some Diameter Applications sessions (Ro, Rx, Gx and enhancements for CCA) RestComm/jdiameter#23
- Supporting handling of messages from undefined realms (RestComm/jdiameter#74) - this has been split into two different works, first the ability to answer to requests coming FROM a realm we don't have configured and a second feature which is actually accepting/processing requests TO a realm which isn't our own.. this one is more complex and dubious on how to proper implement it.
- Unplanned work for customers regarding RestComm/jdiameter#73
to track them separately
I have both pretty much ready, but that second one, I am not very sure how far we should go with it, if at all
should I break it into 2 and split the story points between the two issues ?
can you check with @SummaNetworks that reported the issue if TO is needed at all ?
well, the actual issue descripton refers more to that scenario than to the first, although I know both are needed
is that the stack need to accept process requests/responses
coming from 2 realms
right ?
what you described is the first scenario... we receive a message from "realm.provider1.com", which is a realm we don't know about
we are configured to managed multiple realms ourselves for traffic segregation ?
so we are configured as jdiameter.provider1.com and jdiameter.provider2.com
right, more like it. we receive a mesasge addressed to realm "realm.acme.com" when our realm is "mobicents.org"
and requests coming from provider1 need to be handled by our local configured realm jdiameter.provider1.com ?
for realm restcomm.org
no ?
or have 2 realms
provider1.restcomm.org and provider2.restcomm.org configured
and have a single realm
but we can do multi tenancy
the realm doesn't have to be a resolvable name, it's just a "domain" to contain multple peers
that seems to allow the stack to configure multiple realms then ?
each realm containing multiple peers
I see how this could be useful for having the stack act as DRA I think
to balance and route traffic from multiple realms
because when the server is answering back it adds it's own identity, the realm and hostname
by example using one Server to serve multiple realm is cost effective
like slack uses domains
org1.slack.com would use the same backend servers as org2.slack.com
instead of spinning up a server per realm
would allow configuration of multiple realms for the stack be possible ?
if it receives a request aimed to that realm it would still reply back with the identity configured
realm and hostname
well, that brings several issues... when establishing a connection, which realm(s) to use
for those use case ?
like destination realm or origin realm
yes
no, that's not controllable by the app.. connection establishment or mangement is not for the applications
not the connection establishment itself
so the stack can do the connection establishement based on this hint
yes, the origin-realm can be added, although on the stack IIRC, we force the right values, replacing by the configured ones
but the connection establishment comes before the apps exist
what I meant was to have multiple occurrences of LocalPeer in the config file
as it seems on the network side
right, but that makes sense, as it is normal a peer connecting to multiple peers
I see what you mean, but I don't think that's a good approach
can you do a design document with diagrams on topology and pitfalls issues
?
the same stack serving multiple peers and realms.. then load balancing on top of that
it will likely bring a multitude of issues
ok, will do that
ok thanks
and a DRA for routing
I would like a holistic view of how this scenario is typically solved from a topology perspective
and why can't it work in the current scenario ?
the question here is they want to receive whatever comes, with no need to configure multiple peer.. so if they connect to 100 operators and each operator wants them to use a different realm
because I don't think that even the multiple LocalPeers config is good for them
I would assume each operator interconnect would require some interop anyway and proper configuration
just accepting
* is more simple :)so we don't spend too much time on this if this is just a matter of not doing proper configuration
and we provide recommendation on how this should be done
currently we are able to manage more than one operator using our service, each operator needs a unique realm, but now it is impossible to use it in a real environment due to stack restriction, stack only can manage one realm for the local peer. Now we have to install two machines, with two stacks to process two different realms, but the idea is to allow more than one operator in the same machine using the same stack/service/mobicents
well, multiple peers means also multiple IPs or ports
they want https://github.com/RestComm/jdiameter/blob/master/examples/charging-server-simulator/src/main/resources/config-server.xml#L9 multiple realms in that LocalPeer ?
each operator needs a unique realmit seems that it would be multiple realms
like
Realms="operator1,operator2,operator3" realmthat ties back to the realms defined in https://github.com/RestComm/jdiameter/blob/master/examples/charging-server-simulator/src/main/resources/config-server.xml#L45
anything, is the stack ignoring the Destination-Realm value of the AVPs and just process the request even if not meant for it
but I'll work on a doc and also ping @SummaNetworks regarding this
yes it needs clarification
so we understand the real business need and see what and if it makes sense
were you able to work on perf tests CI job as well based on the scripts provided ?
not yet. what they changed in the scripts is the timeout for the messages and have better granularity at response times
ok
and write the doc in parallel of the tests running ;)
Thanks everyone, that's a wrap up for today
Reply all
Reply to author
Forward
0 new messages