{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":684796178,"defaultBranch":"master","name":"yate","ownerLogin":"eventphone","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-08-29T21:51:36.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/38015698?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1711577184.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"a9ebbf29628654d1ea5405a0070ffad4f63e83ac","ref":"refs/heads/eh24","pushedAt":"2024-03-27T22:06:24.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"garw","name":"Martin Lang (Garwin)","path":"/garw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5400781?s=80&v=4"},"commit":{"message":"callfork: Add debug message for bug hunting\n\nAt 37C3 we experienced yate crashes that are caused\nby freed forkchilds that are still in the slave\nlist although they should've been removed.\n\nI suspect that this is caused by a scenario where they're\nremoved before they even have been added. In order to gather\nevidence for this suspicion, add a log message to the place\nin the code that is more or less the only occasion in\nwhich this may happen.","shortMessageHtmlLink":"callfork: Add debug message for bug hunting"}},{"before":"ef0d8d4c6ab58c976671a94e2531e0bf6c098171","after":"e0a20c4fe410dede4b40d7d42c3e8c7cde3383c2","ref":"refs/heads/upstream","pushedAt":"2024-01-23T18:52:21.000Z","pushType":"push","commitsCount":32,"pusher":{"login":"sur5r","name":"Jakob Haufe","path":"/sur5r","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1111369?s=80&v=4"},"commit":{"message":"Re-written transmission of HEP packets.\nEnqueue packets into an internal queue so that it does not affect captured layers.\nAdded congestion mechanisms.","shortMessageHtmlLink":"Re-written transmission of HEP packets."}},{"before":"78271d729ba160e5090ed27bd4cd928109411d9f","after":"3f500c15d38b6c4120634e5287b8501045498c66","ref":"refs/heads/master","pushedAt":"2024-01-16T19:35:42.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"sur5r","name":"Jakob Haufe","path":"/sur5r","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1111369?s=80&v=4"},"commit":{"message":"ISUP: support transfer capability interworking with Q.931\n\nA Q.931 call has the 'transfer-cap' attribute set to 'udi' for data\ncalls.  The ISUP module must pick this up and encode it in the\nUseServiceInformation IE to preserve this vital information.  Inversely,\na call arriving via ISUP must put its transfer-capability into the\n'transfer-cap' attribute, so that when it's routed to Q.931 it is\npreserved.\n\nWithout this transfer-capability transparency, no UDI/RDI data calls\nor ISDN video calls can transition on the Q931/ISUP boundary\n\nSee also https://github.com/yatevoip/yate/issues/12","shortMessageHtmlLink":"ISUP: support transfer capability interworking with Q.931"}},{"before":"ef0d8d4c6ab58c976671a94e2531e0bf6c098171","after":"78271d729ba160e5090ed27bd4cd928109411d9f","ref":"refs/heads/master","pushedAt":"2023-10-02T23:34:15.000Z","pushType":"push","commitsCount":14,"pusher":{"login":"sur5r","name":"Jakob Haufe","path":"/sur5r","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1111369?s=80&v=4"},"commit":{"message":"zapcard: revert buffer length back to 160 (20ms)\n\nwhile the smaller buffer length had a positive impact on\nISDN data calls, it breaks yate's handling of SIP/RTP to TDM calls.\nYate will start to emit 16ms packets with a buffer length of 128,\nwhich will lead to broken call audio with many SIP providers.","shortMessageHtmlLink":"zapcard: revert buffer length back to 160 (20ms)"}},{"before":null,"after":"ef0d8d4c6ab58c976671a94e2531e0bf6c098171","ref":"refs/heads/upstream","pushedAt":"2023-10-02T22:47:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"sur5r","name":"Jakob Haufe","path":"/sur5r","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1111369?s=80&v=4"},"commit":{"message":"Fix SIP packet capturing for TCP.\n\nWait for whole SIP packet to be received/sent before sending it to the capture.\nCapturing at socket level would send HEP packets containing SIP fragments.","shortMessageHtmlLink":"Fix SIP packet capturing for TCP."}},{"before":null,"after":"e19fff778d97f798d9040f933e7d04c84b2a2ca1","ref":"refs/heads/poc_contributions","pushedAt":"2023-09-30T15:54:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"garw","name":"Martin Lang (Garwin)","path":"/garw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/5400781?s=80&v=4"},"commit":{"message":"Callfork: Inconsistent group progression\n\nCallforks support three types of call legs:\n- regular\n- auxiliar\n- persistent\n\nThese different types change the behavior of how groups progress.\nIf no regular calls are left in a group, the fork progresses\nimmediately to the next group, drops all auxiliar children and keeps\nthe persistent ones. However, there is inconsistent behavior depending\non whether the creation of a call leg is successful or not.\n\nCurrently, the check if there are regular calls left in the current\ngroup is only implemented in lostSlave(). So, if you have a group\nwith one persistent member (ringback) and one regular member, you can\nobserve different behavior in the case that routing for the member fails\nand in the situation that the call is started but then rejected on a remote\nend.\n\nIf the regular member is remote, forkSlave() will succeed and initiate a sip\ncall. The callContinue() function will return. Then, the sip call might fail\nbecause the remote member is offline. Now lostSlave() is called, the module\ndetects that this was the last regular member and immediately progresses\nto the next group.\n\nIf the regular member, however, is local, the routing knows that the member\nis offline and fails. In this case forkSlave() will fail. Nonetheless, forks = 1\nbecause creation of the persistent slave (ringback) was succesful. Consequently,\nthe call continues but it is ringing nowhere. In case that the next group is timed,\nthe caller will just hear the ringback for a while. If the next group isn't timed\nbut expected to progress if all calls in the current group have failed, the call\nis actually stuck and the caller will hear the ringback indefinately while it is\nnowhere ringing.\n\nThis patch fixes this behavior by checking if regular call legs are active before\nreturning from callContinue(). If this isn't the case, it will trigger progression\nto the next group immediately.","shortMessageHtmlLink":"Callfork: Inconsistent group progression"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wMy0yN1QyMjowNjoyNC4wMDAwMDBazwAAAAQhL4Ro","endCursor":"Y3Vyc29yOnYyOpK7MjAyMy0wOS0zMFQxNTo1NDoxMS4wMDAwMDBazwAAAAOMd6ex"}},"title":"Activity · eventphone/yate"}