| 00:00.23 | kpfleming | but to answer your question... no, with a static configuration, the R-URI and the To header would still have the external IP address in them, since that's the only address Asterisk would have available |
| 00:07.29 | Micc_ | in what case would it not work to just use the internal IP? |
| 00:07.40 | kpfleming | that's not what i said |
| 00:08.01 | kpfleming | this is not about what IP address is used, it's about whether the Contact URI that the device supplied is used (unmodified) or not used (at all) |
| 00:09.04 | kpfleming | if the device registers a Contact URI that looks like "sip:45678;user=phone@x.x.x.x:5060;transport=TLS;account=456", then it may not even work if you replace '45678' with '1234', because the device expects the entirety of the Contact URI that it supplied to be used when an INVITE is sent to it |
| 00:09.27 | kpfleming | it could easily reject the INVITE with a 404 response in that case |
| 00:09.37 | Micc_ | ok, I think I see. |
| 00:09.57 | kpfleming | even Asterisk will do this; when Asterisk registers with another SIP server, it generates a random value in the Contact URI, and it expects to see that random value in the R-URI in the incoming INVITE |
| 00:10.17 | kpfleming | good, glad i could explain it, it's not an easy thing to describe :-) |
| 00:11.48 | Micc_ | yeah I know. So for my case I could parse out the ip from the contact and create a new pvt->sa with it in set_address_from_contact, since the uri is not anything special in this case. |
| 00:12.00 | kpfleming | yes, you could |
| 00:12.15 | kpfleming | the IP and port, in case the device really cares about that |
| 00:12.29 | Micc_ | this would be much easier if they had a free public ip I could use. |
| 00:12.57 | kpfleming | but really, you should just parse out the 'user' part of the Contact URI, replace it with the new 'user' part that you specified in the dialplan, and leave the rest of the Contact URI as it was originally supplied |
| 00:13.48 | Micc_ | oh right because in this case it would work to just replace the user with the phone number. |
| 00:13.53 | kpfleming | yep |
| 00:13.58 | kpfleming | that's the optional behavior i referred to earlier |
| 00:14.16 | kpfleming | just replacing the user part of the stored Contact URI for the INVITE being constructed |
| 00:14.23 | Micc_ | so can you point me to the right line of code to make that change? |
| 00:14.32 | kpfleming | no, unfortunately i can't |
| 00:14.41 | kpfleming | i'd have to research it and i'm about to head home |
| 00:15.08 | kpfleming | but it isn't going to be just changing a line of code, it's going to be writing new code to split apart the Contact URI and put it back together |
| 00:20.37 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 00:20.37 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 00:21.34 | Micc_ | I know |
| 00:21.50 | Micc_ | I just need to figure out where to put that call to a new function that I write. |
| 00:22.05 | Micc_ | but I don't know how to use all the special asterisk string functions. |
| 00:22.17 | Micc_ | so it won't be proper, but it should work. |
| 00:24.24 | kpfleming | well, that's a start |
| 00:24.34 | kpfleming | have fun |
| 00:48.13 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 00:48.17 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 01:04.49 | *** join/#asterisk-dev Micc_ (~Micc@c-24-19-33-189.hsd1.wa.comcast.net) |
| 01:09.30 | Micc_ | I see there is a port_str2int, is there something like that for an ip address like ip_str2sa? |
| 01:32.27 | Micc_ | is peer something under pvt? like pvt->peer->sa would be valid? |
| 01:38.02 | Micc_ | relatedpeer is what it is |
| 02:22.41 | Micc_ | I don't think I'm finding the right place to change the To header yet. |
| 02:23.03 | Micc_ | I thought I could do it in __set_address_from_contact but it doesn't seem to be getting called |
| 02:27.33 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:27.33 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:01.01 | Micc_ | is there some documentation somewhere on how to add new options to a sip peer? |
| 03:01.14 | Micc_ | so I can put new things into sip.conf |
| 03:13.48 | mjordan | Micc_: no, but there are well defined patterns used throughout Asterisk for obtaining configuration information from a config file / realtime |
| 03:15.59 | mjordan | You may want to look at config.h and see how modules load variables from config files using it - there are some smaller modules that you could use as an example before diving into chan_sip |
| 03:26.19 | Micc_ | I figured I would store it in the sip_pvt but that seems like a lot of work, I guess I could just read it out of the config file on every call. |
| 03:48.07 | mjordan | if its peer data, if should be stored in sip_peer |
| 04:11.24 | *** join/#asterisk-dev Micc_ (~Micc@c-24-19-33-189.hsd1.wa.comcast.net) |
| 04:11.37 | Micc_ | I think I did it. seems to be working pretty well. |
| 05:20.05 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 06:36.48 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 06:59.19 | *** join/#asterisk-dev irroot (~gregory@41.49.48.39) |
| 07:12.02 | *** join/#asterisk-dev irroot (~gregory@41.53.142.98) |
| 07:45.08 | *** join/#asterisk-dev irroot (~gregory@197.170.5.135) |
| 08:05.35 | *** join/#asterisk-dev lftsy (~lftsy@194.38.160.113) |
| 08:13.07 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 08:13.08 | schmidts | good morning |
| 08:21.55 | schmidts | could someone please try to check asterisk.org |
| 08:22.07 | schmidts | dig asterisk.org |
| 08:22.15 | schmidts | ;; QUESTION SECTION: |
| 08:22.15 | schmidts | ;asterisk.org.INA |
| 08:22.21 | schmidts | dont gives me an answer |
| 08:22.27 | schmidts | is it my dns or something else? |
| 08:22.50 | schmidts | ok looks like a dns problem at my side, google can resolve it |
| 08:26.58 | schmidts | ok its not my dns server the one from digium are down |
| 08:27.11 | schmidts | dig asterisk.org @NSX1.DIGIUM.COM |
| 08:27.11 | schmidts | ; <<>> DiG 9.3.4-P1.2 <<>> asterisk.org @NSX1.DIGIUM.COM |
| 08:27.11 | schmidts | ; (1 server found) |
| 08:27.11 | schmidts | ;; global options: printcmd |
| 08:27.11 | schmidts | ;; connection timed out; no servers could be reached |
| 08:28.17 | wdoekes2 | .. and it's back |
| 08:28.40 | schmidts | yes ;) |
| 08:29.16 | wdoekes2 | but 2/3 nameservers are still down |
| 08:33.30 | schmidts | maybe everybody wants to download asterisk 10 and the are just in heavy load ;) |
| 08:41.01 | *** join/#asterisk-dev irroot (~gregory@197.172.135.97) |
| 09:23.51 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 09:23.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:41.01 | schmidts | am i wrong or shouldnt this be Kbit instead of Khz? * New highly optimized and customizable ConfBridge application capable of mixing |
| 09:41.01 | schmidts | <PROTECTED> |
| 10:00.50 | wdoekes2 | and it's gone again |
| 10:01.06 | wdoekes2 | and my caching nameservers seem to be very poor at caching ;) |
| 10:11.43 | schmidts | :( |
| 10:12.09 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 10:12.17 | schmidts | wdoekes2 meanwhile could you help understand bit flags, this is something i have never realled checked completly ;) |
| 10:12.29 | schmidts | for example if have these: |
| 10:12.34 | schmidts | #define SIP_PAGE2_FAX_DETECT_CNG (1 << 24) /*!< DP: Fax Detection support - detect CNG in audio */ |
| 10:12.42 | schmidts | and this: #define SIP_PAGE2_FAX_DETECT_BOTH (3 << 24) |
| 10:12.56 | schmidts | and then i do this: ast_test_flag(&p->flags[1], SIP_PAGE2_FAX_DETECT_CNG) |
| 10:13.06 | schmidts | will this be true if the BOTH flag is set? |
| 10:13.20 | wdoekes2 | yes |
| 10:13.52 | wdoekes2 | since both holds binary 11 and you're checking for 01 |
| 10:15.33 | schmidts | ok got it |
| 10:15.38 | schmidts | maybe ;) |
| 10:15.40 | schmidts | thanks |
| 10:18.48 | schmidts | is there allready a dialplan function or application to disable faxdetect on a call base? |
| 10:43.44 | *** join/#asterisk-dev _ys (~Miranda@HS3-193-119.xG.SPb.SkyLink.RU) |
| 10:46.32 | _ys | hi, asterisk.org is down now? |
| 11:05.07 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 11:13.29 | *** join/#asterisk-dev schmidts (~schmidts@2001:858:4:0:66b9:e8ff:fec3:ae88) |
| 11:13.40 | schmidts | _ys the ns server at digium are down |
| 11:16.08 | _ys | Hmm |
| 11:16.09 | _ys | ok |
| 11:46.16 | wdoekes2 | some of them work every now and then |
| 11:48.34 | *** join/#asterisk-dev irroot (~gregory@41.48.183.170) |
| 12:10.17 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:10.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:19.05 | schmidts | good morning kpfleming |
| 12:22.38 | kpfleming | good morning indeed |
| 12:34.45 | *** join/#asterisk-dev fobus912 (~fobus912@41.214.229.46) |
| 12:36.43 | fobus912 | Hi all |
| 12:36.57 | fobus912 | I have quick question for you guys if you do not mind |
| 12:37.17 | fobus912 | is it possible to have a different register expiration time than the subsribtion time |
| 12:37.45 | fobus912 | *subscription* |
| 12:52.34 | fobus912 | anyone please |
| 12:52.56 | schmidts | fobus912 sure why not? thats two complete different things |
| 12:53.50 | fobus912 | but how can we set different expire header |
| 12:53.53 | fobus912 | for each message |
| 12:54.19 | schmidts | fobus912 the client normally does this |
| 12:54.23 | *** join/#asterisk-dev lftsy (~lftsy@212.147.5.206) |
| 12:54.44 | fobus912 | i cannot change from the client |
| 12:55.04 | fobus912 | this normally should be done from the client it self |
| 12:55.15 | fobus912 | but we can always include in the 200 ok for each |
| 12:55.17 | fobus912 | message |
| 12:55.22 | fobus912 | a different expire header |
| 12:56.34 | fobus912 | the only condition is that expire in the reply should be less than the valu |
| 12:56.37 | schmidts | fobus912 i dont know what you want to do but maybe you should take a look at a sip proxy, its very easy to change expire headers there |
| 12:56.49 | fobus912 | Right |
| 12:57.06 | fobus912 | i was just wondering if this is possible as well with Asterisk |
| 12:57.42 | *** join/#asterisk-dev irroot (~gregory@197.173.154.36) |
| 12:58.03 | fobus912 | Thanks for your time schmidts |
| 12:58.23 | schmidts | fobus912 no thats not really possible with asterisk cause you cannot change single sip packets |
| 12:58.46 | fobus912 | Alright Thanks for the confirmation |
| 13:04.24 | leifmadsen | kpfleming: ping |
| 13:06.16 | kpfleming | leifmadsen: pong |
| 13:06.59 | leifmadsen | kpfleming: just msg'd you |
| 13:07.00 | leifmadsen | thx |
| 13:46.09 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xmsjudsldnusspap) |
| 13:46.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:54.38 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-ishptjdcipvewlwl) |
| 13:54.38 | *** mode/#asterisk-dev [+o mnicholson] by ChanServ |
| 14:01.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-eassybcjfabdgbos) |
| 14:01.55 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-kgokuvbfgczvtekx) |
| 14:01.55 | *** mode/#asterisk-dev [+o mnicholson] by ChanServ |
| 14:02.35 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-aylfrarqobggwvcu) |
| 14:02.36 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:02.59 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-lcuecnvqqdynzchc) |
| 14:02.59 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:16.46 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-hbihgwlrjyuculch) |
| 15:03.40 | schmidts | where do i have to create information for the XML documentation? |
| 15:04.01 | mjordan | schmidts: what do you mean by create information? |
| 15:04.15 | mjordan | are you looking to update the XML documentation for a module? |
| 15:04.59 | schmidts | i have added a function to chan_sip.c and i get these warning when loading chan_sip.so |
| 15:05.11 | schmidts | xmldoc.c:1839 xmldoc_build_field: Couldn't find function SIPFAXDETECT in XML documentation |
| 15:05.46 | schmidts | IMHO this xml description is on top of chan_sip.c where all the other xml information for functions are located, but i allready have written it there |
| 15:05.47 | jsmith | schmidts: Yeah, the XML documentation is in the code -- you should be able to find examples in the source code for other functions |
| 15:06.00 | jsmith | schmidts: Ah, looks like you know that already :-/ |
| 15:06.17 | schmidts | jsmith like this http://pastebin.com/ktT08naf ? |
| 15:06.18 | schmidts | ;) |
| 15:06.18 | jsmith | If I remember correctly, you also have to register it |
| 15:06.32 | schmidts | jsmith ahh ok |
| 15:06.53 | mjordan | jsmith: yup |
| 15:07.19 | schmidts | with ast_custom_function_register ? |
| 15:07.42 | schmidts | the function itself works fine its just complaining about the missing xml information |
| 15:09.10 | mjordan | odd, that should be it |
| 15:10.29 | mjordan | whats the name in your ast_custom_function? |
| 15:11.22 | schmidts | moment i will pastebin the whole diff |
| 15:12.37 | schmidts | http://pastebin.com/D1Ye60qP |
| 15:13.54 | mjordan | schmidts: what happens if you escape your '/' character with a <literal> tag |
| 15:14.04 | mjordan | line 17 of your diff |
| 15:14.17 | mjordan | '/' is a special character in XML, so it may be that your XML node is malformed |
| 15:14.24 | schmidts | ah ok i see |
| 15:15.31 | mjordan | (you may be better off just using //, honestly) |
| 15:16.08 | schmidts | doesnt change anything still got the same warning |
| 15:17.06 | schmidts | i have to go now, but i will put it on reviewboard |
| 15:17.10 | mjordan | ok |
| 15:17.24 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:27.07 | *** join/#asterisk-dev Ulrar (~Ulrar@2a01:e0b:1:136:62eb:69ff:fe8f:18a0) |
| 15:27.36 | *** join/#asterisk-dev irroot (~gregory@41.51.78.197) |
| 15:28.42 | Ulrar | Hi, I have made some modules, and they segfault in case of reload. I load the conf with ast_config_log, and for a reload I ast_config_destroy and then ast_config_load. Is it there right way ? I've looked on other code modules and they ast_config_load without destroying the old conf |
| 15:45.23 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:45.23 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:47.33 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-pysbwbsvfzixfwmb) |
| 15:47.55 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 15:47.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:57.41 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:57.42 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:00.58 | kpfleming | leifmadsen: ping |
| 16:01.13 | leifmadsen | kpfleming: ohai |
| 16:02.05 | kpfleming | we need to locate all pages on asterisk.org/wiki.asterisk.org/etc. that show release dates and support periods for asterisk releases, and update the asterisk 10 release date to be yesterday, and update the end-of-support dates to be 1year/2years from the release date, since the release slipped |
| 16:04.48 | leifmadsen | ok np |
| 16:05.59 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 16:06.00 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:09.31 | leifmadsen | kpfleming: ok, wiki versions page updated and gliffy diagram setup to better reflect the new state |
| 16:09.35 | leifmadsen | (of asterisk 10) |
| 16:09.46 | kpfleming | thanks! that was fast. |
| 16:09.56 | leifmadsen | ya :) |
| 16:10.04 | leifmadsen | I'm not sure if there is really anywhere else to update |
| 16:10.11 | leifmadsen | that is the defacto info for release dates |
| 16:10.21 | leifmadsen | anything else is just speculation :) |
| 16:11.29 | leifmadsen | kpfleming: oh as I'm going through this wiki, I just realized we have pictures we need to upload to the AstriDevCon 2011 page of the attendees :) |
| 16:11.40 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:11.43 | acidfoo | leifmadsen, im still waiting to see them :P |
| 16:11.45 | kpfleming | yeah... i have them on my home computer |
| 16:11.59 | leifmadsen | ya, I have them on my NAS now I think... maybe I'll see what I have today |
| 16:12.09 | leifmadsen | kpfleming: what you don't have them in THE CLOUD?! |
| 16:12.19 | kpfleming | i don't |
| 16:12.27 | kpfleming | well, they are in my private cloud |
| 16:13.01 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 16:13.08 | file | your private cloud? tmi! |
| 16:13.27 | oej | Arrrggh. "Private cloud" comes from Microsoft Marketing |
| 16:13.38 | leifmadsen | I don't understand what the problem is with that term |
| 16:14.00 | leifmadsen | I can certainly build cloud infrastructure for private use |
| 16:19.50 | oej | I guess I'm too old for new marketing bullshit terminology. We've had private networks to hosted services for years. |
| 16:22.07 | leifmadsen | sure |
| 16:22.15 | leifmadsen | so your problem is with the term "cloud" |
| 16:22.20 | leifmadsen | much like file |
| 16:25.22 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 16:25.47 | pabelanger | my jcolp private cloud is working fine today! |
| 16:25.50 | pabelanger | that is all |
| 16:28.46 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.16.145) |
| 17:08.16 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 17:08.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:30.21 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 18:01.05 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 18:03.54 | p3nguin | The jabber_patch_ammends.patch that I was given to fix the jabber component problem doesn't work against 1.8.8.0. Was the problem addressed so I can discard the patch, or does a new patch need to be made? I didn't see anything in the changelog about fixing it, but I also don't really know exactly what to look for. |
| 18:06.09 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:21f:d0ff:fea1:568e) |
| 18:15.51 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:15.51 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:20.54 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 18:20.54 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:04.34 | jrose_atDigium | ASTERISK-18565 - What this patch does is if saycids is on in voicemail, it checks for a valid sound file with the same name as the caller id field in the $VM_SPOOLDIR/callerids (actually, it used Callerids, but I changed it to callerids)... and if it finds one, it plays that instead of the caller id number. Does this actually seem like something we should be doing? I don't think the name thing is a problem, but the storing of c |
| 19:04.34 | jrose_atDigium | aller id mappings to sound files in the voicemail directory strikes me as a little weird. |
| 19:04.44 | jrose_atDigium | https://issues.asterisk.org/jira/browse/ASTERISK-18565 |
| 19:05.37 | kpfleming | where else would they be stored? this is a function of app_voicemail, it seems to be logical for the data to be stored in the voicemail area |
| 19:07.46 | jrose_atDigium | Well yeah, but recording them isn't a function of voicemail, it only plays them if they just happen to be there. |
| 19:08.46 | jrose_atDigium | That's just a matter of documentation. I'm just thinking there are other possible areas where this might have relevant use. I haven't thought of any just yet. |
| 19:08.59 | WIMPy | They might also be useful in various other places. Confbridge, followme, whatever |
| 19:09.06 | jrose_atDigium | Yeah, there you go. |
| 19:10.45 | *** join/#asterisk-dev kenhunt (~kenhunt@nat/digium/x-idqdekuewigouupp) |
| 19:11.11 | WIMPy | However I used to do it with a layer in between. A list of caller ids and a list of samples so that I could add samples like "mobile", "home" or "work" to the actual name. |
| 19:12.49 | kpfleming | well, if you want to propose a more suitable location, that's certainly fine |
| 19:13.54 | jrose_atDigium | I'm currently thinking something along the lines of SPOOL/recordings/callerids |
| 19:14.13 | jrose_atDigium | or SPOOL/recordings/callerid_mapping |
| 19:15.31 | mjordan | jrose_atDigium: if you're going to make this generic beyond app_voicemail, you may want to consider what you can place in app.c as opposed to app-voicemail |
| 19:15.57 | jrose_atDigium | There is nothing in this patch that pertains beyond voicemail really. |
| 19:16.11 | jrose_atDigium | mjordan: ^ |
| 19:16.43 | jrose_atDigium | I suppose a more generic approach could be taken to checking if the mapping exists and playing it though. |
| 19:18.44 | mjordan | well, if you're going to make the location of the sound files generic, such that any app can use them, then the code that's responsible for recording / playing them back should be in a generic location as well, regardless of whether or not you've modified any other apps to use it |
| 19:19.07 | mjordan | otherwise why bother putting them in a non-voicemail location? :-) |
| 19:19.44 | jrose_atDigium | There isn't any code that is responsible for recording them just yet, but yeah, that's what I meant. |
| 19:31.05 | jrose_atDigium | Honestly, I'm not thinking recording them should necessarily be a globally accessible to everyone type of thing that is available from apps since they would be shared. Sounds like something that would invite mischief. |
| 19:32.08 | jrose_atDigium | So yeah, leave recording and setups to allow recording of them in the hands of PBX administrators via dialplan. |
| 19:33.08 | mjordan | jrose_atDigium: huh? |
| 19:33.38 | jrose_atDigium | Well, if for instance you had an option in voicemail to record the name of a person who left you a message... |
| 19:33.41 | mjordan | right now apps.c defines how we do a lot of recording, and that is shared. For example, the names of voicemail users (which is a recording) can be read by both app_voicemail and app_directory |
| 19:34.08 | mjordan | the low level file stuff has a mechanism to lock the directory when something is being written to protect concurrent access |
| 19:35.50 | mjordan | unless I'm misunderstanding your concerns, which is quite possible :-) |
| 19:36.57 | jrose_atDigium | Well, no, that wasn't really what my concern was. I'm just saying that I don't think a recording function specific to this caller id mapping stuff needs to be made because it isn't really something that seems to need deployed from broader applications that use them. |
| 19:37.28 | jrose_atDigium | Like voicemailmain doesn't need to give people the option to record the names of callers who leave you a voicemail without having their names already recorded. |
| 19:37.57 | jrose_atDigium | *and if it were shared, someone could record something like "that jerk from down the hall" and right now that would be their name for everyone from then on until someone manually deleted it. |
| 19:38.39 | jrose_atDigium | So if there is a situation where a user needs to record names for caller IDs, it seems like something you would just use the Record app for. |
| 19:39.27 | jrose_atDigium | Anyway, it's beyond the scope of this patch. All that we really need for now in app.c is a function to check for the recording if it's there and play it. |
| 19:39.37 | mjordan | which we should already have. |
| 19:40.12 | mjordan | play_and_record (and its various relatives) should be able to take any path |
| 19:40.40 | mjordan | so.. yeah. |
| 19:40.59 | jrose_atDigium | Yeah, but I'd like to be able to just supply a caller id number to the function and then have the function do the rest. |
| 19:41.20 | mjordan | I don't disagree with you, but that breaks the model we've used in app.c so far. |
| 19:41.36 | mjordan | up to you :-) |
| 19:41.53 | jrose_atDigium | Oh, and the channel it needs to be played on of course. |
| 19:42.09 | jrose_atDigium | I'll whip something up and post a review request for it later on. |
| 19:44.44 | *** join/#asterisk-dev oej (~olle@87.96.134.129) |
| 19:44.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:55.42 | jrose_atDigium | Actually in retrospect, voicemail needs to evaluate whether the recorded callerid name exists before committing to playing it since it will only play vm-from if it does exist, so there's really no point in creating a new app.c function for that purpose. I'll just stick with ast_fileexists in the meantime. |
| 21:34.57 | *** join/#asterisk-dev Micc (~Micc@c-24-19-33-189.hsd1.wa.comcast.net) |
| 21:36.15 | Micc | kpfleming, you got a minute to talk about that contact header nat issue? I did manage to fix it for myself, but I have some ideas for how to solve the problem for others. |
| 21:40.04 | mjordan | Micc: kpfleming isn't in the channel currently. If you feel that you have a solution that may be beneficial to others, you're more then welcome to post the patch to reviewboard |
| 21:43.33 | Micc | No, I don't have a patch yet. I just wanted to talk with him about what kind of patch would work best. I'd like to chat with him since it was a kindo f complex thing and it was fresh in his mind. |
| 21:44.09 | Micc | mjordan, you were there yesterday I think too. Do you remember what we talked about? |
| 21:52.43 | mjordan | to some extent, yes |
| 21:54.43 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:54.44 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:04.12 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 22:04.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 22:22.28 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 22:47.58 | kpfleming | Micc: i'm back now, for a bit anyway |
| 22:55.14 | Micc | ok, so I was thinking wouldn't it work if instead of not trusting the contact header at all, could it be parsed and rewrote with a new username? |
| 22:55.26 | Micc | then if they add other tokens and things it would still work. |
| 22:55.45 | Micc | wouldn't that be the right thing to do in every case? |
| 22:55.48 | kpfleming | no |
| 22:56.08 | kpfleming | because the other parameters that might be present in the contact URI could be dependent on or related to the username in the URI itself |
| 22:56.24 | kpfleming | if the username gets changed, those parameters may be useless, or cause broken behavior |
| 22:56.49 | kpfleming | that's why it has to be optional, because it's uncommon and could cause problems |
| 22:57.09 | Micc | ok, that sounds like an oversite in the sip protocol. |
| 22:57.27 | kpfleming | no, not at all. what makes you say that? |
| 22:59.04 | Micc | Because in my case if my device happened to add some crazy parameters like your saying, there would be nothing I could do to fix it unless asterisk could take some type of contact rewrite rules. |
| 22:59.15 | Micc | that would only be applied per peer. |
| 23:00.08 | kpfleming | but you missed the point i made yesterday. in your scenario, you are mis-using REGISTER. the REGISTER method allows a SIP UA to register an *entire* Contact URI that must be used to deliver INVITE requests to it. the Contact URI supplied by the UA to the registrar must not be modified, period. |
| 23:00.36 | Micc | It might not be common, but it is part of the protocol to have the host part of the contact match your host to make sure its not a request for someone else, isn't it? |
| 23:00.37 | *** join/#asterisk-dev seraphie (~erin@75.76.38.159) |
| 23:00.49 | kpfleming | no, it is not |
| 23:01.08 | Micc | If the protocol wasn't written that you need to verify the host part, then this is really a bug on adtran's side in their ta904. |
| 23:01.12 | kpfleming | it is impossible for a UA to receive a request for 'someone else' by accident |
| 23:01.50 | Micc | yes, I realize that, but what does the sip spec say? |
| 23:01.53 | kpfleming | most UAs, including Asterisk, will do some verification of the host-part of the request URI, so this is not unusual |
| 23:02.15 | kpfleming | the SIP RFCs do not describe every possible scenario and behavior |
| 23:02.24 | kpfleming | they describe what is required, and optional, behavior |
| 23:02.41 | kpfleming | thousands of other scenarios are possible, and may or may not be useful and practical |
| 23:02.48 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-lcuecnvqqdynzchc) |
| 23:03.14 | kpfleming | a SIP UA can choose to do any validation it desires on the request URI supplied in an INVITE request. |
| 23:03.19 | WIMPy | Err. You can easily get an invite that was'nt for you if you're on a dynamic IP. |
| 23:03.52 | kpfleming | well, i don't know that i'd say 'easily', since dynamic IPs don't typically change that frequently, but yes, this is a possible scenario. |
| 23:04.17 | kpfleming | the underlying problem here though has nothing to do with SIP though, it's caused by the NAT in the middle. |
| 23:04.43 | kpfleming | if the Adtran device is going to 'verify' that the host-part of the request URI is correct, it needs to have knowledge of what its external IP address is. |
| 23:06.08 | Micc | yeah that sounds like an adtran problem then. I asked them if there was a way to add the external ip, but they said no, so seems like they screwed up. |
| 23:09.58 | kpfleming | unless, of course, they say that they don't support their product being used behind a NAT :-) |
| 23:21.46 | Micc | well I don't have any other customers that use any devices that have other parameters in the username, so I'll just leave my little fix in until I need to make it an optional thing. |
| 23:22.10 | Micc | it only kicks in if extension is dialed and the device is behind nat, so thats only 1 customer at the moment. |
| 23:22.46 | kpfleming | glad it works for you... it's nice to have the source code so you can do stuff like that :-) |
| 23:23.24 | Micc | yeah, that is the only thing that would have worked for this customer at the moment. We could have ordered another internet connection but that takes about a week. |
| 23:23.43 | Micc | open source to the rescue. |
| 23:25.15 | Micc | the hardest part was finding the place to put the new code in. |
| 23:25.20 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 23:25.42 | Micc | once I found it should go in initreqprep, it was pretty simple since theres already a parse_uri. |
| 23:28.06 | kpfleming | that's usually what happens with bugfixes too... 95% of the time is spent figuring out what is wrong and where the fix needs to go... the rest is pretty easy. |
| 23:29.33 | Micc | there are a few things I'm not going to try to fix again, multi-tenant parking and blf. The code is all over the place for those. |
| 23:30.14 | Micc | although I did make a patch to not send the ringing blf state change. |
| 23:32.53 | Micc | thanks for your help. I'm out till next time I need to fix something. |
| 23:32.59 | kpfleming | you are most welcome |
| 23:33.14 | *** part/#asterisk-dev Micc (~Micc@c-24-19-33-189.hsd1.wa.comcast.net) |
| 23:42.26 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:42.26 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 23:45.32 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |