| 00:26.17 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-qosfdyzudndhifri) |
| 00:26.17 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 00:27.53 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/drc) |
| 00:31.34 | *** join/#asterisk-dev skrusty (~skrusty@88.150.145.104) |
| 00:31.34 | *** mode/#asterisk-dev [+o skrusty] by ChanServ |
| 01:00.15 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 01:00.30 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 07:11.12 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 08:15.14 | *** join/#asterisk-dev hehol (~Adium@ip-176-199-151-97.hsi06.unitymediagroup.de) |
| 08:49.26 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 08:49.26 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 11:21.35 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 11:21.35 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 12:33.18 | seanbright | can one of you folks take care of cherry picking the pjproject review for me? |
| 12:33.37 | seanbright | away from a computer for a few days |
| 12:35.30 | file | can do |
| 12:39.20 | seanbright | thanks |
| 12:39.45 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 14:03.15 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:03.15 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:10.11 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 14:15.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:a9e7:7d3b:37dc:9dc0) |
| 14:21.59 | *** join/#asterisk-dev jkroon (~jkroon@41.113.55.160) |
| 14:22.19 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:43.40 | *** join/#asterisk-dev jkroon (~jkroon@41.113.49.172) |
| 15:23.13 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-hujtxskkcfvvncfp) |
| 15:23.13 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:25.33 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-jgegdbzavyywfohj) |
| 15:25.33 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:31.48 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 17:11.58 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.109) |
| 19:31.29 | kharwell | thinking a bit on new codec related diaplan functions to add, or have for pjsip |
| 19:31.32 | kharwell | right now we have PJSIP_MEDIA_OFFER |
| 19:32.07 | kharwell | was thinking about something like PJSIP_MEDIA_REMOTE which would be a read only variable that has the list of codecs from the remote device |
| 19:32.43 | kharwell | and maybe PJSIP_MEDIA_ANSWER which would allow someone to override the codecs that will be sent in an answer to an inbound call |
| 19:32.54 | kharwell | thoughts on those? |
| 19:33.17 | gtjoseph | +1 to both |
| 19:34.10 | kharwell | also what about something like PJSIP_MEDIA_INBOUND. That would allow the user to set a list of inbound codecs overriding those negotiated, that get sent to across the bridge to the outbound side (before sending the offer) |
| 19:34.52 | gtjoseph | hmmm. |
| 19:34.57 | kharwell | or PJSIP_MEDIA_OFFER could be used here. If set on the inbound channel then those codecs are sent across the bridge. For the outbound channel the functionality remains as it is |
| 19:35.40 | gtjoseph | at this point maybe just shadow the endpoint options? |
| 19:35.56 | kharwell | yeah that's almost what I was wondering too |
| 19:36.24 | gtjoseph | would make it easier to understand and correlate |
| 19:36.29 | gtjoseph | behavior |
| 19:36.36 | kharwell | each one would essentially allow overriding of what was negotiated at each point based on the config |
| 19:36.43 | kharwell | yeah |
| 19:36.44 | rmudgett | Do remember when dialplan is executed in this negotiation process. |
| 19:36.57 | kharwell | aah yeah ha that's true |
| 19:37.06 | kharwell | things just don't go back into the dialplan |
| 19:37.20 | gtjoseph | yeah would only work for outbound |
| 19:37.43 | gtjoseph | well, not really |
| 19:37.51 | gtjoseph | hmmm |
| 19:37.52 | kharwell | altering PJSIP_MEDIA_OFFER, or adding PJSIP_MEDIA_INBOUND would still work |
| 19:38.05 | kharwell | as that could be done on the inbound channel prior to dialing |
| 19:38.26 | rmudgett | Maybe we could add codec negotiation interception routines like CONNECTEDLINE |
| 19:38.27 | kharwell | same for PJSIP_MEDIA_ANSWER? |
| 19:38.28 | gtjoseph | actually why wouldn't all 4 not work? |
| 19:38.59 | gtjoseph | incoming_offer would filter what got passed to the core |
| 19:39.25 | gtjoseph | outgoing_offer would filter what gets sent to the remote |
| 19:39.28 | electronic_eel | I'm just an asterisk user, not a dev, so I don't know enough of the implementation side. But I'd really like to control the codecs for inbound and outbound calls in dialplan - to be able to select them based on extension called, callerid and similar things |
| 19:39.31 | kharwell | hrm so I guess both ways might work. in the one case you'd have to set all the values prior to dialing (on the inbound side) and in a pre-dial handler (for outbound stuff) |
| 19:40.10 | gtjoseph | yeah |
| 19:40.24 | kharwell | but adding interception routines like CONNECTEDLINE might make it more intuitive? |
| 19:40.25 | gtjoseph | electronic_eel: i think that's what we're trying for |
| 19:40.40 | gtjoseph | hmmm |
| 19:41.00 | rmudgett | Those interception routines could be available for subsequent reinvites too. |
| 19:41.05 | gtjoseph | i'd wager that most folks don't even know about interception routines :) |
| 19:41.13 | gtjoseph | but yeah |
| 19:42.07 | kharwell | electronic_eel: that's good to know someone already would want to use it. This is with regards to some of the new work we'll be trying to do for codec negotiation in general. If interested some more info can be found here: https://wiki.asterisk.org/wiki/display/AST/Codec+Negotiation Feel free to add comments or concerns there too! |
| 19:43.03 | kharwell | gtjoseph: that's what astricon talks and all our wonderful wiki pages, blog posts, and forums are for. People read those right? :-P |
| 19:43.17 | gtjoseph | HAHAHAHAHA! |
| 19:43.28 | gtjoseph | oh, sorry. did I say that out loud? |
| 19:43.43 | kharwell | I heard it from here |
| 19:44.51 | kharwell | alright I think for now the general idea is there, and what we need. Implementation details can be worked out later once someone gets into it I suppose |
| 19:45.00 | electronic_eel | kharwell: saw this linked here a day ago or so. if I understand this correctly, it is a static setup, to get the codecs right between different endpoints. But what I want is to do it dynamically in dialplan, based on for example caller ids |
| 19:45.38 | gtjoseph | yeah, thats the plan |
| 19:46.05 | gtjoseph | what's specified in the dialplan would override what was statically configured |
| 19:46.25 | electronic_eel | I have some problems with the gateways between some carriers not working correctly if I enable G.722. I can ususally detect the problematic carrier based on the caller id |
| 19:47.23 | gtjoseph | couldn't that be solved by setting the codecs on the pjsip endpoint? |
| 19:47.33 | gtjoseph | endpoint for the carrier, that is |
| 19:48.23 | electronic_eel | I have a connection to my sip provider, that is my pjsip endpoint. my sip provider routes the call to another carrier. the problem is this gateway between the carriers, not to my sip provider |
| 19:48.32 | gtjoseph | ah I gotcha. |
| 19:48.39 | gtjoseph | good use case then |
| 19:49.19 | gtjoseph | You should add that as a comment on the wiki page so we don't forget it. |
| 19:50.59 | electronic_eel | gtjoseph: currently the page has no section about setting stuff in dialplan, PJSIP_MEDIA_INBOUND and so on. do you want me to add that with my usecase? |
| 19:51.10 | gtjoseph | sure! |
| 20:03.09 | kharwell | okay I updated the Codec Negotiation wiki page with some of what was mentioned here about the dialplan functions. |
| 20:03.49 | kharwell | We should be able to have one for each associated option that allows overriding of that option at its point in the call negotiation process |
| 20:15.25 | electronic_eel | you seem to be planning upcoming features - do you also have plans to allow inserting custom headers in more kinds of sip requests? |
| 20:15.43 | electronic_eel | for example I'd like to send an UPDATE with a custom header |
| 20:16.58 | electronic_eel | this would allow me to use the ssawc feature of polycom phones (open a webbrowser with a specific url during a call) |
| 20:17.22 | file | the Sangoma team isn't working on it, but we can't speak for the rest of the community |
| 20:21.08 | electronic_eel | is more control about custom headers a common feature request? I've read some sip interop specs from some carriers, and they often mention custom headers, not only for the invite |
| 20:21.31 | file | I see it on IRC or the forums maybe 2-3 times a year? |
| 20:24.24 | electronic_eel | the only workaround I could come up with, except from dirty patching into asterisk/pjsip, would be installing a extra kamailio in between. or is there a more lightweight workaround? |
| 20:34.33 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:b019:ad9:d540:d402) |
| 21:43.46 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 22:06.48 | *** join/#asterisk-dev jkroon (~jkroon@41.114.52.238) |
| 23:17.40 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.109) |