| 00:36.49 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 01:06.44 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 01:53.31 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 02:33.09 | *** join/#asterisk-dev roramirez (~rodrigo@186-78-29-106.baf.movistar.cl) |
| 02:35.00 | *** join/#asterisk-dev dant_ (~dant@120.28.157.15) |
| 02:54.37 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |
| 02:55.38 | coreyfarrell | roramirez: once you cherry-pick that channel.h review to 13 I'll +1 both |
| 06:19.20 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:4103:e301:4fa2:c4c6) |
| 06:55.20 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:55.20 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:05.06 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-hvsjeqhojmnuosiu) |
| 07:42.32 | *** join/#asterisk-dev dant (~dant@120.28.157.15) |
| 11:47.41 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 11:47.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:06.50 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 13:51.23 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 15:57.29 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 16:14.38 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:34.16 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 16:34.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:04.58 | mjordan | file: code question! |
| 17:05.02 | file | 4 |
| 17:05.34 | mjordan | file: in res_pjsip_session, we create the SDP response to an offer immediately upon receiving the offer. Is there a reason why we create it immediately instead of waiting until we send a 183 or 200? |
| 17:06.07 | file | it depends on if the PJSIP SDP negotiator usage within the INVITE session code will allow you to do that at that point |
| 17:06.19 | file | and the order in which stuff is invoked |
| 17:06.23 | file | it sounds like it SHOULD be fine |
| 17:07.05 | mjordan | I'm thinking of moving the SDP generation to ast_sip_session_send_response |
| 17:07.26 | mjordan | probably before handle_outgoing_response, as normally the SDP would have existed by then |
| 17:08.22 | file | not every 200 has an SDP |
| 17:09.08 | mjordan | so, maybe I'm reading this wrong |
| 17:09.56 | mjordan | but if session_inv_on_rx_offer, we just simply create the answer and stick it on the session |
| 17:10.13 | mjordan | after putting the offer on the session |
| 17:10.33 | file | I don't remember the flow of how INVITE session does it |
| 17:10.44 | mjordan | it is a bit broken up |
| 17:11.07 | file | that may or may not be invoked on INVITE |
| 17:11.22 | mjordan | yeah, if they defer it, then we wouldn't get it. Hum. |
| 17:11.33 | mjordan | Maybe I shouldn't move that, but I really need a way to update the generated SDP |
| 17:11.50 | file | experiment! |
| 17:11.58 | file | break the world |
| 17:12.01 | mjordan | I'm trying to figure out a way to tell res_pjsip_session "your native format capabilities have changed" |
| 17:12.09 | mjordan | you need to update the response you would normally send |
| 17:13.08 | mjordan | I'm starting to think that doesn't really exist |
| 17:13.54 | file | yeah, you'd need to work out the execution for the INVITE session SDP negotiation and the last possible moment you can provide an answer |
| 17:14.18 | mjordan | well |
| 17:14.22 | file | I'm fairly certain you can't update afterwards because the SDP negotiation has completed |
| 17:14.28 | mjordan | it also looks like you may be able to call pjsip_inv_set_sdp_answer multiple times |
| 17:14.42 | mjordan | file: right, this can only work if we haven't sent a 183 or 200 |
| 17:14.50 | mjordan | otherwise, you have to send a refresh |
| 17:15.48 | mjordan | file: trying to solve this problem: Inbound offer (g,u,a) => over channel chain => Outbound offer (g,u,a) |
| 17:15.55 | file | I don't think you can call pjsip_inv_set_sdp_answer after you've done |
| 17:15.55 | mjordan | But the far end response with (u,a) |
| 17:16.16 | file | even if you haven't sent a response |
| 17:17.03 | file | that calls into pjmedia_sdp_neg_set_local_answer, which changes the negotiation state and so subsequent calls will return an error |
| 17:17.31 | file | so you have to defer setting the SDP answer at all until the last possible moment |
| 17:17.45 | mjordan | blech. |
| 17:17.53 | mjordan | that's unfortunate. |
| 17:18.14 | mjordan | the problem with that is you don't know, when sending a response, if you've actually gotten an offer yet |
| 17:20.35 | *** join/#asterisk-dev dant_ (~dant@120.28.157.15) |
| 17:22.15 | file | an offer from whom |
| 17:23.46 | mjordan | file: take the following situation |
| 17:24.00 | mjordan | Alice offers g,u,a to Asterisk. Asterisk (with some tweaks), offers g,u,a to Bob. |
| 17:24.13 | mjordan | Bob, being a jackwagon, responds with u,a. |
| 17:24.23 | mjordan | Today, that would force transcoding, even though Alice offered a compatible set of codecs. |
| 17:24.30 | file | oui |
| 17:24.57 | mjordan | What I've done is taken the response from Bob (u,a), dropped it into a new control frame, and sent that ahead of the rippling Progress or Answer control frame |
| 17:25.04 | file | yup |
| 17:25.22 | mjordan | so we have a format_cap that represents what the far end wants, which can update a Local channel chain all the way down to Alice |
| 17:25.29 | file | yup yup |
| 17:25.31 | mjordan | however, Alice has already set her response in the SDP |
| 17:25.34 | mjordan | which is now wrong |
| 17:25.41 | file | yup |
| 17:25.52 | mjordan | I need the intersection of the req_cap on the session plus what came in on the control frame |
| 17:25.58 | mjordan | alas, we've already generated the SDP. |
| 17:26.10 | mjordan | So if I get one of these magical control frames, I have to tell Asterisk to re-generate the response SDP to Alice |
| 17:26.22 | mjordan | barring that, defer generating it until we send the 183/200 |
| 17:26.26 | mjordan | back to Alice |
| 17:26.30 | file | oh god someone at my door |
| 17:26.33 | mjordan | lawl |
| 17:26.36 | file | ignores |
| 17:26.45 | file | the only way you can do it is deferring, or refresh |
| 17:26.54 | mjordan | yeah |
| 17:27.01 | file | deferral should be possible |
| 17:27.04 | mjordan | we could Answer, then immediately send a media refresh |
| 17:27.15 | mjordan | but I'd rather defer |
| 17:27.29 | mjordan | the nice thing about this frame is it could be used for adhoc media refreshes via another mechanism |
| 17:27.38 | file | yup yup |
| 17:27.42 | mjordan | but that's a latter thought |
| 17:28.00 | mjordan | I shall see about deferring the generation of the SDP. |
| 17:28.31 | file | you'll need to do a check for whether you are offering or answering |
| 17:28.47 | file | that should be the only gotcha |
| 17:30.34 | mjordan | at least we cache the inv_session |
| 17:33.16 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 17:34.33 | mjordan | hm. I think I will move almost all of session_inv_on_rx_offer to the sending of the response, and just cache the offer there. |
| 17:34.43 | mjordan | We need the offer when we generate the local SDP. |
| 17:34.52 | file | you can get it from the SDP negotiator |
| 17:35.17 | file | maybe >_> |
| 17:35.23 | file | yup |
| 17:35.30 | file | pjmedia_sdp_neg_get_neg_remote |
| 17:36.27 | mjordan | oh good, otherwise I was going to have to clone it |
| 17:47.34 | mjordan | file: something like this, I think - http://pastebin.com/HXChDyhf |
| 17:48.36 | file | hum |
| 17:48.49 | file | don't you have to handle the offer earlier so the channel has the formats from it? |
| 17:49.10 | mjordan | hm. |
| 17:49.20 | mjordan | Maybe, I'll take a look at that. |
| 17:49.31 | file | otherwise how would the channel you've called have the right formats? |
| 17:50.09 | mjordan | true, in which case I can leave that in session_on_rx_offer, and just remove it from that function |
| 17:50.51 | mjordan | I'll see what that does :-) |
| 17:50.57 | file | IMPLODE |
| 17:53.44 | *** join/#asterisk-dev pchero (~pchero@0x555140b5.adsl.cybercity.dk) |
| 17:59.55 | gtjoseph | mjordan: is renaming a macro considered ABI breaking? AST_VECTOR_INSERT should really be AST_VECTOR_REPLACE and it's not widely used. |
| 18:00.00 | mjordan | crazy, so far the SDP offer/answer tests are passing. |
| 18:00.13 | mjordan | gtjoseph: er... it probably would be |
| 18:00.34 | mjordan | maybe. |
| 18:00.43 | gtjoseph | even though compiled sources would have a snapshot? |
| 18:00.48 | gtjoseph | of the original |
| 18:00.58 | mjordan | true, they would. But why not just make that change in master? |
| 18:01.27 | gtjoseph | because I have a real AST_VECTOR_INSERT that i'd want to go in 13 |
| 18:01.36 | mjordan | ah |
| 18:01.45 | mjordan | what will the difference be? |
| 18:02.06 | gtjoseph | INSERT does a true insert. it shifts existing elements right to make room for the new element |
| 18:02.49 | gtjoseph | the current INSERT overwrites the element at the specified index. |
| 18:05.21 | mjordan | file: not bad, only one test failed |
| 18:05.33 | file | mjordan, you didn't try hard enough |
| 18:05.34 | mjordan | gtjoseph: I'd say go for it. |
| 18:05.44 | gtjoseph | cool, thx |
| 18:05.47 | mjordan | file: I know, right? I'm actually surprised this test is passing now |
| 18:07.59 | mjordan | and now, shopping |
| 18:08.03 | mjordan | wanders off |
| 19:33.13 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-fdmowuwzxhbyuflj) |
| 19:35.14 | coreyfarrell | I'm looking at updating optional_api to automatically reference to the provider modules on use, I have a couple questions. why do we allow OPTIONAL_API to be disabled? is OPTIONAL_API meant to be usable by the core as consumer or provider? |
| 20:25.28 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 20:44.49 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 20:49.27 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 22:37.13 | mjordan | coreyfarrell: IIRC, OPTIONAL_API can be disabled as some compilers don't support it. I think. |
| 22:37.35 | mjordan | coreyfarrell: for your second question, I can't think of a scenario where the core would be a consumer. |
| 23:03.00 | coreyfarrell | yeah I actually looked into the question of core usage, there are a couple main/*.c that include headers that provide optional api. non are really needed so I'm preparing a patch for that. |
| 23:06.29 | coreyfarrell | about the compiler support thing I thought that was no longer an issue in 13/master. I can't see any compiler magic in the current versions, other than using __attribute__((constructor)), but lots of non-optional code uses that. |
| 23:19.22 | *** join/#asterisk-dev ZX81 (~Adium@186.73.87.90) |
| 23:50.52 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip70-162-151-19.ph.ph.cox.net) |