| 03:31.37 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:89c2:6298:1f7a:4d44) |
| 06:07.53 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 06:57.34 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:57.34 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:06.07 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:08.15 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.62) |
| 07:12.42 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 09:44.09 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 10:03.57 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 10:10.39 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 10:12.43 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 10:29.42 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 11:10.48 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 11:27.37 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 12:02.36 | tsearle | file, is there a reason why chan_pjsip ignores AST_CONTROL_SRCCHANGE ? |
| 12:02.59 | file | not explicitly |
| 12:03.08 | file | many things in PJSIP were not done until they were needed |
| 12:03.16 | file | or until an issue was run into |
| 12:03.30 | tsearle | my best guess is that the control frame is unable to specify which stream had the ssrc change... |
| 12:04.10 | file | well, streams didn't exist until a few versions after PJSIP support came into existence |
| 12:04.13 | file | so, not exactly |
| 12:04.40 | tsearle | well I'm having an issue where one leg has a ssrc change resulting in the bridged leg having jitter |
| 12:05.11 | tsearle | because it preserves the timestaps of the new stream, but doesn't change the ssrc nor set the marker |
| 12:05.25 | file | ok |
| 12:05.57 | tsearle | was thinking that setting the ssrc change on the audio stream on recipt of this control frame would fix this |
| 12:06.01 | tsearle | what do you think? |
| 12:06.13 | file | potentially? |
| 12:06.17 | file | my only concern is WebRTC |
| 12:06.30 | file | you can't just change the SSRC with it |
| 12:07.19 | tsearle | what is needed in the webrtc case? a new re-invite with the ssrc in sdp? |
| 12:07.22 | file | yes. |
| 12:07.41 | file | you have to change the bundle association as well if it occurs |
| 12:08.17 | tsearle | ok |
| 12:09.05 | file | actually the bundle may be okay since the remote side should use the same SSRC... but you still have to renegotiate to say the SSRC of what is going to be sent... in a pure audio scenario the browser MAY be forgiving |
| 12:09.18 | tsearle | well then perhaps a cheaper solution, would be to keep the ssrc but make this control frame trigger setting the marker bit? |
| 12:10.00 | file | there's a control frame for that |
| 12:10.17 | file | well, an API into RTP to do that |
| 12:10.22 | file | which is triggered based on a control frame usually |
| 12:11.30 | file | SRCUPDATE, and ast_rtp_update_source |
| 12:11.51 | tsearle | well res_rtp_asterisk generates the SRCCHANGE frame |
| 12:12.09 | tsearle | and in this case, the bad sonus equimpent is doing s SSRC chagne without setting a marker bet |
| 12:12.19 | file | right, SRCUPDATE and SRCCHANGE are two different things |
| 12:12.26 | file | I'm merely saying that a control frame and function already exists for this |
| 12:12.27 | tsearle | and chan_pjsip ignores SRCUPDATE too |
| 12:12.40 | file | so you can utilize those and see within your specific scenario whether it actually helps or not |
| 12:12.48 | file | before going down a potentially complicated SSRC route |
| 12:13.13 | tsearle | so I can map both SRCUPDATE and SRCCHANGE to ast_rtp_instance_update_source and see if that helps |
| 12:13.20 | file | I don't know if it will or will not because different media stacks behave differently given the same changes |
| 12:13.56 | tsearle | I'm going from sonus <-> asterisk13 <-> asterisk 1.6(libss7) |
| 12:14.01 | tsearle | what can possibly go wrong? :D |
| 12:14.09 | file | Sonus is horrible. |
| 12:14.19 | tsearle | I 100% agree |
| 12:14.51 | tsearle | I had to write our proprietary dtmf_inband_mute feature because of them |
| 12:15.03 | tsearle | and soo many other dtmf fixes to get the jitter just right |
| 12:15.23 | tsearle | most of the latter has been pushed upstream though :D |
| 12:16.20 | tsearle | but going back to the control frames |
| 12:16.47 | tsearle | when you get SRCCHANGE or SRCUPDATE, it seems there is no what to know if it is the audio or the video stream ? |
| 12:17.21 | tsearle | is it ok to assume that the control frame is talking about the audio? |
| 12:19.29 | tsearle | though I suppose a more long-term solution would be to add media type to the control frame |
| 12:21.14 | file | there is no way to know |
| 12:21.21 | file | (currently) |
| 12:21.54 | file | 16 and above could include the information, because frames there have a stream identifier field for use |
| 12:33.00 | tsearle | ref your gerrit comment, is there anyway that webrtc can use the p2p bridge? I wouldn't think so |
| 12:33.57 | file | whoops, I meant to remove that |
| 12:34.27 | file | ignore it |
| 12:34.38 | tsearle | thanks :D |
| 12:50.43 | *** join/#asterisk-dev sduthil (~sduthil@107-179-252-17.cpe.teksavvy.com) |
| 12:55.07 | pchero_work | OMG⦠I'm so sorry -_-;;; Why it was deleted? -_-;;; |
| 12:56.52 | pchero_work | Ah, in the patch set 7.. -_-;;; |
| 12:57.32 | pchero_work | Thanks that catch. |
| 13:02.53 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.62) |
| 13:23.52 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.56) |
| 14:04.18 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-bvgfywwkngtidtga) |
| 14:04.18 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:19.41 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 14:19.41 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 14:23.27 | gtjoseph | seanbright: read this when you get a chance and tell me what it says... https://www.telekom.de/hilfe/downloads/1tr114.pdf |
| 14:24.12 | seanbright | A DNS query to request the actual SRV record set shall be done before sending a REGISTER or re-REGISTER request. |
| 14:24.42 | seanbright | wait... you say to tell you what it says... hold on |
| 14:25.07 | seanbright | Technical Technical Specification of the SIP (Gm) interface between the User Equipment (UE) and the IMS platform of Deutsche Telekom |
| 14:25.15 | seanbright | 1 TR 114 |
| 14:25.23 | seanbright | Version: V4.1.0 |
| 14:25.30 | seanbright | Publisher |
| 14:25.33 | file | gtjoseph: your request was not specific enough. |
| 14:25.38 | gtjoseph | i should have been more specific |
| 14:25.41 | seanbright | Deutsche Telekom Technik GmbH |
| 14:25.44 | seanbright | this is going to take a while |
| 14:26.00 | seanbright | i wish i cared about this problem |
| 14:26.15 | seanbright | i'm very much in the "if it is not in an RFC, you can fuck yourself" camp |
| 14:27.01 | seanbright | this is why i don't get asked to go to client meetings |
| 14:27.29 | gtjoseph | wise decision |
| 14:35.51 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-qtoepreteihjuhst) |
| 14:35.51 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:22.11 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 16:08.56 | gtjoseph | kharwell: i'm a little confused on the codec options after looking in more detail... if incoming_call_offer_prefs is remote do we just ignore Alice's endpoint allowed codecs altogether? |
| 16:09.56 | gtjoseph | I.E. what do we pass to the core? |
| 16:13.49 | gtjoseph | NM. I think I got it. it's always an ORd list. |
| 16:14.06 | kharwell | no we get the joint list between the two and order it according to the remote list, and pass that to the core |
| 16:14.28 | gtjoseph | yeah. had to read it a few times. |
| 16:14.31 | kharwell | yeah |
| 16:15.24 | gtjoseph | here's another question though... |
| 16:16.26 | gtjoseph | if the option is one of the _single's how is that different from preferred_codec_only |
| 16:17.16 | kharwell | it's not, or shouldn't be. The new option with a *_single specified would be the same. |
| 16:17.33 | kharwell | we can dump the old option probably? |
| 16:17.41 | gtjoseph | so should preferred_codec_only be removed from the wiki? |
| 16:17.43 | kharwell | but kept it around for now for backwards compat |
| 16:17.52 | gtjoseph | ah gotcha |
| 16:18.07 | kharwell | which wiki? |
| 16:18.17 | gtjoseph | your codec wiki page |
| 16:18.31 | kharwell | I dunno I'll go with what others think though. If the new option does what that did prob no reason to keep it? It is master only |
| 16:19.06 | file | can't just remove it like that, even in master |
| 16:19.28 | kharwell | ah, yeah on that wiki I was trying to list the new options and all current ones to help solidify what was being worked with |
| 16:19.53 | gtjoseph | i'd make the code disregard that option if any of the new options are present |
| 16:20.04 | kharwell | file: no worries we'd put in an upgrade note :-P |
| 16:20.04 | gtjoseph | and note that in your wiki |
| 16:20.29 | file | :P |
| 16:21.24 | kharwell | I think I made it so the code just does the same thing for both options. THat means though the old option can override what's on the new if *_single is not specified |
| 16:21.39 | kharwell | That'd be a user config problem though |
| 16:21.46 | gtjoseph | yeah that could get confusing though |
| 16:23.08 | kharwell | maybe a warning then? If we can't remove the option then it should still do something |
| 16:23.41 | file | if you configure both, then _apply can spit out an error and reject - because you shouldn't use them both together |
| 16:23.59 | gtjoseph | +1 |
| 16:24.00 | file | either use the old option, or move to the new configuration options imo |
| 16:24.07 | gtjoseph | +2 |
| 16:24.34 | kharwell | fine by me |
| 16:25.19 | gtjoseph | another question... ast_sip_session_join_incoming_call_offer_cap works on format_caps but should we really work on topology and streams instead? |
| 16:27.13 | gtjoseph | I ask because sessopn/create_local_sdp works on topology and streams |
| 16:27.46 | kharwell | don't think so? There are multiple codecs/formats per stream so we want to order by the codecs |
| 16:27.53 | kharwell | for each stream |
| 16:28.31 | gtjoseph | hmmm |
| 16:30.01 | kharwell | unless I'm confusing streams with topologies. It's been a while since I've looked at that code. Each stream matches with SDP definition right? Like audio or video stream |
| 16:42.09 | gtjoseph | kharwell: so yeah, each stream can have multiple caps but what i'm wondering where to place the code for outgoing. i'll keep thinking. |
| 16:42.21 | gtjoseph | also something i don't think we discussed.... direct media. |
| 16:43.23 | gtjoseph | afaik we only use the endpoint codecs on an outgoing call if direct media is involved |
| 16:44.02 | kharwell | the outgoing caps can go on the same "caps" data structure that was added on the pjsip session media struct. On that side of the call it just won't have the outgoing set, and vice versa |
| 16:44.02 | gtjoseph | do we care any more? |
| 16:44.56 | gtjoseph | yep. was thinking more of should the code go in res_pjsip_sdp_rtp or in res_pjsip_session |
| 16:45.49 | gtjoseph | i'm also looking at ast_sip_session_join_incoming_call_offer_cap to see if we can make it more generic so i don't have to duplicate the code. |
| 16:46.05 | kharwell | I thought the way it currently worked is we use the endpoint's configured codecs ordered by the caller's codecs that were passed across the bridge (for outgoing) |
| 16:46.14 | gtjoseph | back to directmedia though... should we just ignore the fact that directmedia is involved now? |
| 16:47.16 | gtjoseph | well, res_pjsip_sdp_rtp has this in create_outgoing_sdp_stream: https://pastebin.com/uesgTJ6H |
| 16:47.31 | kharwell | I debated the sdp_rtp vs session stuff. After thinking a bit imo sdp_rtp should really be up under and part of res_pjsips_session and not be it's own module. Not only does it depend on session, but manipulates, and sets items on it, etc... |
| 16:47.49 | gtjoseph | :) |
| 16:48.13 | gtjoseph | after we get everything working functionally, we'll probably want to do a refactor :) |
| 16:48.15 | kharwell | regarding direct media. I think we can ignore it for now |
| 16:48.25 | gtjoseph | kk |
| 17:18.13 | *** join/#asterisk-dev tsearle (~tsearle@d8D876A4B.access.telenet.be) |
| 17:18.13 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 17:18.21 | tsearle | sorry seems I broke testsuite |
| 17:18.45 | tsearle | https://gerrit.asterisk.org/c/testsuite/+/13905 |
| 17:18.55 | tsearle | that should fix it |
| 17:19.24 | tsearle | sorry about that |
| 17:20.20 | tsearle | actually no it won't |
| 17:21.42 | tsearle | there, replacing 9 with six should do it |
| 17:34.51 | seanbright | we should reorganize ast_frame in 18 |
| 17:35.27 | seanbright | according to pahole there are 16 bytes of padding due to alignment |
| 17:35.37 | seanbright | (on 64 bit machines anyway) |
| 17:39.06 | seanbright | and remove linkedlists.h too... |
| 17:39.13 | seanbright | #ColpHardFacts |
| 17:41.06 | file | have you secured a license from me for the use of that hash tag? |
| 17:42.06 | seanbright | you and your licensing |
| 17:57.21 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.99) |
| 21:04.27 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.107) |
| 23:03.19 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.107) |
| 23:24.28 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.107) |