Re: [asterisk-dev] Mailing List Future

[Olle E. Johansson]

> On 4 Dec 2023, at 13:38, Joshua C. Colp  wrote:
> 
> The mailing lists have remained unchanged since deployed.
…and the archives for everything is still around.

Mail is boring but very very long-term stable.

Forums are cool, sexy and keeps changing so we loose history because the cost 
of mirgrating old postings and comments is way too high and the marketing 
department that runs the forums seldom understand the need to keep it 
persistent…

I would encourage keeping a development mailing list.

/O
> 
> For self hosting they would need to be completely redone on fresh 
> infrastructure, fresh distro, fresh software, and hopefully things would 
> possibly import. They'd also need to be updated to conform to current 
> standards on sending so that that they don't appear as spam as often. (For me 
> 25% of emails from the lists go to my spam currently and require manual 
> involvement)
> 
> For hosted we'd need support for over 2500+ subscribers for the -dev list if 
> it were to be imported. For commercial entities we could possibly import, but 
> for something like someone doing that work and effort and hosting I would not 
> be comfortable providing such information, and people would need to sign up 
> fresh again. It would also not be something I would be willing to spend money 
> on due to the low use of the lists.
> 
> Past that - can you explain why it's a bad idea? I've looked at the 
> interactions for the past few years and while some have existed, they've been 
> minimal over all.
> 
> On Mon, Dec 4, 2023 at 8:28 AM Jaco Kroon  > wrote:
>> Hi,
>> 
>> My 5c.  Killing the dev list is a bad idea.
>> 
>> Most developers could not care about having to poll forums.  It also means 
>> that stuff that would previously get an audience will now get none.
>> 
>> github discussions are better than forums at least.
>> 
>> May I inquire as to the problem you're having with the ML?  Perhaps I might 
>> be able to assist ...
>> 
>> Kind regards,
>> Jaco
>> 
>> On 2023/12/04 14:00, Joshua C. Colp wrote:
>> 
>>> Greetings all,
>>> 
>>> Over the past few years, the use of the Asterisk mailing lists has 
>>> diminished, with far more conversation happening on the Asterisk community 
>>> forums[1]. The state of email, to ensure reliable delivery, has also gotten 
>>> more complicated - emails get caught by spam filters, etc.. To continue the 
>>> mailing lists would require a huge time and resource investment, for 
>>> minimal use.
>>> 
>>> To that end, we’ve decided to discontinue the mailing lists effective 
>>> February 1st, 2024.
>>> 
>>> This means the following:
>>> 
>>> 1. Sending and receiving mailing list emails will no longer be possible.
>>> 2. The list archives, however, will remain available.
>>> 
>>> We need to decide the future of the asterisk-dev mailing list; 
>>> specifically, where to hold discussions in the future. There are a few 
>>> options:
>>> 
>>> 1. A “Development” category exists on https://community.asterisk.org/ 
>>> already that can be used.
>>> 2. We can use GitHub discussions, which keeps things with the GitHub 
>>> project.
>>> 3. We can use a hosted mailing list elsewhere.
>>> 
>>> We suggest option #2, since it keeps things with the GitHub project, which 
>>> is where everything development-related happens now regardless. This has 
>>> been set up and enabled already.
>>> 
>>> If you have any input, now is the time to state it.
>>> 
>>> Cheers,
>>> 
>>> -- 
>>> Joshua C. Colp
>>> Asterisk Project Lead
>>> Sangoma Technologies
>>> Check us out at www.sangoma.com  and 
>>> www.asterisk.org 
>>> 
> 
> 
> -- 
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com  and 
> www.asterisk.org 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Deprecating users.conf

[Olle E. Johansson]

> On 30 Jun 2023, at 13:45, aster...@phreaknet.org wrote:
> 
> Hi folks,
> 
>  I've put up a PR to deprecate users.conf[1], following a discussion 
> earlier this year about this, but I think that was on IRC so wanted to 
> discuss here as well.
> 
> Mark introduced users.conf at some point in the early 2000s with the idea of 
> it being a "simple" way to configure certain things, but I think time has 
> shown that to be its primary weakness. New modules haven't supported 
> users.conf in a long time (such as PJSIP), and now that chan_sip is already 
> gone, there is basically no point in keeping users.conf around anymore. The 
> main two modules that still "support" it (if you can call the hack job 
> parsing they do "support") are chan_dahdi and chan_iax2, and the 
> configuration for both of these is almost entirely non-overlapping and really 
> needs to be configured in the appropriate module config file anyways.
It was a bad hack from the start with a poor architecture. Time to remove it.
+100

/O
> 
> Therefore, I am proposing this be deprecated in 21 so that it can be removed 
> in 23, in accordance with the Asterisk deprecation policy:
> 
> * Support for users.conf has dwindled as new modules no longer support
>   it and modules that did support it (e.g. chan_sip) have been largely
>   removed
> * No real functionality has been added to the users.conf mechanism
>   since it was introduced. New features are added to specific modules,
>   but these are not supported in users.conf
> * users.conf was a super simplistic mechanism that in practice did not
>   pan out. It's something that really should never have been added in
>   the first place. Use of it has been widely discouraged since it was
>   introduction, and caused confusion for Asterisk newcomers,
>   particularly with a default install where users see warnings about
>   users.conf. Users should not be using it and the fact that the
>   sample config still exists continues to create confusion
> * Removing users.conf will help eliminate technical debt, allowing for
>   simplification of the codebase and easier maintenance going forward
> 
> This is somewhat different as users.conf is not any single module, and 
> there's no real process for deprecating a config file, but a warning message 
> is added when the PBX loads here so that users will see a notice about it, 
> just like with deprecated modules. It's also in the upgrade notes. This is a 
> master only change, so it won't be removed until late 2025 at the earliest.
> 
> Any objections or other thoughts on this matter?
> 
> [1] https://github.com/asterisk/asterisk/pull/184
> 
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>  http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] chan_sip deprecation

[Olle E. Johansson]

> On 22 Nov 2022, at 09:13, Jon Bonilla (Manwe)  wrote:
> 
> El Tue, 22 Nov 2022 08:00:48 +
> Henning Westerholt  escribió:
> 
>> Hello,
>> 
>> I am really wondering why people are trying to keep chan_sip alive. No
>> offence to the past developers, but pjsip is a much better SIP stack
>> regarding standard compliance and stability compared to the old one. Also,
>> regarding performance chan_pjsip is better. From an outside view, the
>> asterisk project gave plenty of time to migrate.
>> 
> 
> Not defending here keeping chan_sip, it will be removed and chan_pjsip will
> need to be adopted. But just from my point of view as asterisk based solution
> developer:
> 
> We know chan_sip. We know what works and what fails. And we know the
> workarounds for what fails. Having hundreds of asterisk servers working 24/7
> during  the last 7 years I had 0 crashes using chan_sip (don't saying here 
> that
> chan_pjsip would have been different).
Same here. But I see no reason to continue working with the code in chan_sip.
I know all the issues it has, the horrors in the code and how hard it became to 
fix anything.
The single-thread socket listener is causing real bad issues when you hit it 
with heavy traffic.

It’s time to move on and leave chan_sip. 

For me, the question is if it’s time to move to chan_pjsip
or somewhere else entirely. I don’t know yet, but chan_pjsip can’t really
solve the problem with the ISDN-like Asterisk core where all my SIP/RTP calls 
have to 
go through. At this time, the multiprotocol architecture that was the reason
for using Asterisk, and why Asterisk was in the spotlight,
is causing more and more issues that I have to handle
in Kamailio.

/O
> 
> No need of new features here as I use kamailio for some stuff like path,
> paralel forking, websocket handling and all kind of stuff. Just want chan_* to
> send/receive calls fast. 
> 
> chan_pjsip probably hasn't routed yet 1% of the calls chan_sip routed in all
> history. 
> 
> So, In my case it's more confortable to keep chan_sip as I don't need anything
> else and I have 0 issues with it. Maybe others are in the same position.
> 
> 
> But IMHO chan_sip must be removed. I understand what the development is and
> it's a PITA to keep old code and even keeping it unmantained is a pain. When
> the time comes I'll move to chan_pjsip and I won't complain. Grateful to the
> asterisk devs that provide such a great solution.
> 
> cheers,
> 
> Jon
> 
> 
> 
> -- 
> PekePBX, the multitenant PBX solution
> https://pekepbx.com
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] SIP subscription with expires=0

[Olle E. Johansson]

A subscription with expire:0 should get at least ONE notify, right? I’ve just 
that to check the status without setting up a dialog.

It is not invalid. Report this as a bug.

/O

> 25 okt. 2021 kl. 09:22 skrev Nikša Baldun :
> 
> Hello,
> 
> I see the following in res_pjsip_pubsub.c:
> 
> if (expires_header->ivalue == 0) {
> ast_debug(1, "Subscription request from endpoint %s rejected. 
> Expiration of 0 is invalid\n",
> ast_sorcery_object_get_id(endpoint));
> pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), 
> rdata, 400, NULL, NULL, NULL);
> return PJ_TRUE;
> }
> 
> However, according to RFC 2365, value 0 is perfectly valid, and should have 
> the effect of ending the subscription.
> 
> 
>>A natural consequence of this scheme is that a SUBSCRIBE with an
>>"Expires" of 0 constitutes a request to unsubscribe from an event.
> 
> Or is my understanding wrong? Is there some other way to unsubscribe?
> 
> Best regards,
> 
> Nik
> 
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev



signature.asc
Description: Message signed with OpenPGP
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Packet Loss Concealment in confbridge

[Olle E. Johansson]

> On 19 Oct 2021, at 21:56, Matt Fredrickson  wrote:
> 
> On Thu, Oct 14, 2021 at 2:37 PM Pascal Cadotte  wrote:
>> 
>> Hello everyone,
>> 
>> We've been trying to improve the quality of our video conferences using 
>> confbridge. We've been able to figure out how to get the video usable for 
>> all participants even for users using bad internet connections using the 
>> REMB configuration options.
>> 
>> However, we are still having problems getting decent audio when there's 
>> packet loss. We think this is because PLC is not used for channels in 
>> confbridge. We found that information in this page 
>> https://wiki.asterisk.org/wiki/display/AST/PLC+Restrictions+and+Caveats "In 
>> addition, MeetMe and ConfBridge calls will not use PLC."
>> 
>> We are looking into ways to improve this situation and would like to gather 
>> some information about this restriction before working on it.
>> 
>> 1. Does anyone know why PLC has not been implemented for meetme and 
>> confbridge?
>> 2. Is there a known workaround to allow a channel to have PLC enabled while 
>> being in confbridge?
>> 3. Is it a problem many people have? I've only seen this question that seems 
>> to be related 
>> https://community.asterisk.org/t/jitterbuffer-plc-fec-etc-how-do-i-know-they-are-working/85146
>> 4. Is there something in progress that we could contribute to?
>> 
>> The tests have been made using the opus codec, PJSIP on a WSS transport on 
>> Asterisk 18.6.0.
>> 
>> Given two users Alice and Bob
>> Given a 10% paquet loss on Alice
>> When Alice and Bob are talking through confbridge Bob hears a lot of cracking
>> When Alice and Bob are talking to each other using the Dial application to 
>> call Bob's phone, the call quality is almost flawless
> 
> I'll take a quick stab at an answer here.  I went looking at
> translate.c, plc.c, and channel.c, and here are some notes that I
> wrote as I was trying to remember how this works:
> 
> The generic plc code in Asterisk was written a long time ago and can
> be only used for 8 KHz SLINEAR, not for other sample rates.  I'd
> presume that this means a codec such as OPUS needs to output to 8KHz
> SLINEAR somehow to even start using the generic PLC code.
> 
> It appears that generic plc is actually calling the concealment
> functions when making a write to an ast_channel (so after a frame is
> produced from a mixing bridge presumably and goes out to a channel
> driver) - not on the reception side, reading a frame from a channel.
> (channel.c)  Unless someone else wants to go look at and correct me, I
> would assume that that means concealment comes after a bridge mixes
> frames together and presumably all input information about packet loss
> is wiped clean (meaning no generic PLC is happening with a mixing
> bridge).
> 
> Looking at the codecs that support native PLC (such iLBC, speex, etc)
> it looks like they implement this on the conversion to SLINEAR (and
> correspondingly on an ast_read on the channel in quesiton), which
> should work for a case where you have a confbridge or meetme involved.
> 
> For Sangoma's codec_opus, we have support for its native PLC and FEC
> functionality also, so I'd make sure that you have fec=yes enabled for
> its entry in codecs.conf.
> 
> I'd also make sure you have jitterbuffer enabled on any
> channels/conferences in question for good measure.
> 
> So, to sum it up:
> If you're using OPUS, use the opus native fec option (I think PLC
> should be happening also automatically as well) and make sure that the
> jitterbuffer is enabled on the channels/conferences in question.
> 
> If you'd like to use a codec with non-native PLC, you're going to need
> to figure out how to get the generic PLC code working on the
> ast_read() instead of the ast_write() to the channel in question.
> (hoping my assumptions about some of this is correct too :-) )
> 
> Hope that helps,
> Matthew Fredrickson

I had this problem with pure RTP channels using ALAW. To fix it, since G.711 is 
a simple codec, I wrote “Poor mans PLC” where the RTP channel just copied the 
previoius packet up to a maximum number of packets. This fixed our problem, but 
it was very specific and very crude.
There was settings in rtp.conf and possibly sip.conf to enable this.

The code was published in one of my branches but never integrated into asterisk 
as far as I remember.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Gerrit ssh host key changed again :(

[Olle E. Johansson]

> On 26 Aug 2021, at 16:32, George Joseph  wrote:
> 
> During the upgrade of Gerrit today, it decided to regenerate its ssh host key 
> again,  The good news is that Jira issues will now list the active reviews 
> associated with an issue again.  The bad news is that 'gerrit review' and 
> other ssh git actions will complain about the key changing again.  Sorry 
> about that.   Just delete the old key from ~/.ssh/known_hosts and let ssh 
> re-add the new one.
> 
And how should we trust the new one? George, please make sure that the key 
fingerprint is available
on the wiki or somewhere where it can be validated properly. Encouraging blind 
trust is not a good thing.

Cheers
/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Feature request: Allow the use of pjsip client only transports in Asterisk pjsip

[Olle E. Johansson]

> 13 juni 2021 kl. 16:32 skrev Michael Maier :
> 
> 
> Hello!
> 
> pjsip provides the ability to create (TCP / TLS) transports without opening 
> any listener. This is handy if you don't need any listening transport at all 
> for a sip device.
> 
> One of the typical use cases is for dial up environments where you just have 
> to register to the VoIP provider on base of TCP or TLS. To register to an ISP 
> using TCP or TLS, no listener is necessary at all. Having no listener greatly 
> increases security, because you don't have any port which could be reached 
> from arbitrary scanners in the Internet at all and which therefore doesn't 
> need to be secured by other means (portfilter, fail2ban). It's just the 
> correct way to do it like this from a security based view.
> 
> This allows, too, for easily separating internal networks and external 
> networks by using two different networks on the Asterisk device, the internal 
> providing the listener for the internal devices and the external net 
> providing access to the VoIP ISP w/o any listener.
> 
> pjsip provides two CFLAGS which enables this feature to create client 
> transports only by using PJSIP_TCP_TRANSPORT_DONT_CREATE_LISTENER and 
> PJSIP_TLS_TRANSPORT_DONT_CREATE_LISTENER [1].
> 
> I know that it is working perfectly, because I already have a working patch 
> for Asterisk which I will post here if you like.
> 

The second problem is that one needs to update the RFCs to make this 
standard-compliant. Unless you are using the SIP Outbound RFC, which I haven’t 
seen implemented in Asterisk, the server (asterisk) is not allowed to reuse the 
incoming connection for outbound dialogs, like an incoming call.

Many SIP servers simply ignore this and happily reuse the connection, since 
it’s the only way to reach the device behind NAT  and/or a firewall.

/O


signature.asc
Description: Message signed with OpenPGP
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Olle E. Johansson]

I think you misunderstand me. I am not against deprecation and deletion. I just 
want us to find a way to
try to get through to a larger group of users when we do this. For the SIP 
channel case, I don’t think anyone has
missed it - it’s been far too long with two channels, which is confusing.

There are propably a list of modules I would remove quickly if I was under 
Josh’s hat.
/O
> On 2 Oct 2020, at 12:18, Dan Jenkins  wrote:
> 
> Ultimately whats stopping package maintainers from releasing "asterisk-full" 
> which still has all the deprecated modules enabled and "asterisk" which 
> follows the defaults? Nothing Other packages get released in such a way 
> so why not asterisk? I'm 100% not qualified to talk about it because I don't 
> use them or make them. I just think 4 years of something hanging around after 
> its been decided to be deprecated is foolish - deprecation = "this isnt 
> needed any more", as was stated earlier - its not a case of pjsip coming to 
> town and chan_sip getting thrown out immediately the decision to 
> deprecate it took years (and years, and years, and years) - no need to wait a 
> further 4 years.
> 
> 
> 
> On Fri, Oct 2, 2020 at 8:48 AM Olle E. Johansson  <mailto:o...@edvina.net>> wrote:
> Hi!
> I like adding product management and actually removing stuff that the company 
> can’t keep maintaining - and don’t wan’t to.
> 
> Compared with years ago a lot of users never bother building asterisk any 
> more and don’t interface with the project,
> they just run “apt-get install asterisk” and they are done. We are much more 
> in the hands of package managers and really,
> really need to interface with them to get information out. Asterisk is a 
> plumbing tool, much like nginx or apache. I don’t
> follow those projects, haven’t built apache httpd from source for over ten 
> years and get my information from packaging.
> 
> I think this has to be considered as well. 
> 
> Thanks Josh for pushing this process.
> 
> /O
> 
> > On 2 Oct 2020, at 00:45, Seán C McCord  > <mailto:ule...@gmail.com>> wrote:
> > 
> > On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote:
> >> I think I personally hesitate to be so aggressive because long ago the
> >> project was that way. We would push to remove things faster and such,
> >> and the result was upset people and complaints. Years later I still had
> >> people coming up to me at AstriCon talking about that stuff and how it 
> >> screwed
> >> them over.
> > 
> > I think this is a key point which we, as developers and integrators can 
> > easily overlook.  We're being pulled in two direction:  one, we must always 
> > keep up-to-date in our implementations, and two, we must be able to work 
> > with what the customers are willing to use.  Once things are deprecated, it 
> > is far easier to push the customer to do the right thing.  Removal makes 
> > this easier.  Thus, faster deprecation and removal is better for the 
> > integrator/developer/consultant.
> > 
> > But we do not represent more than the barest fraction of the Asterisk user 
> > base.  The greater portion is running production workloads with very low 
> > tolerance for either change or down-time, and are resultingly very 
> > conservative with their upgrades and loathe to spend great effort into 
> > managing those upgrades.
> > 
> > If we accelerate deprecation, we may end up making the problem _worse_ (as 
> > it used to be), where users would simply not upgrade at all, because it was 
> > too difficult to do so.
> > 
> > I agree that 4 years feels like an eternity to _me_, but to an operator 
> > working with very slim margins, it is not nearly so glacial.
> > 
> > ---
> > 
> > Seán C McCord
> > ule...@gmail.com <mailto:ule...@gmail.com>
> > PGP/GPG: https://cycoresys.com/scm.asc <https://cycoresys.com/scm.asc>
> > 
> > -- 
> > _
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com 
> > <http://www.api-digital.com/> --
> > 
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev 
> > <http://lists.digium.com/mailman/listinfo/asterisk-dev>
> 
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
> <http://www.api-digital.com/> --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:

Re: [asterisk-dev] Module Deprecation, Default Not Building, and Removal

[Olle E. Johansson]

Hi!
I like adding product management and actually removing stuff that the company 
can’t keep maintaining - and don’t wan’t to.

Compared with years ago a lot of users never bother building asterisk any more 
and don’t interface with the project,
they just run “apt-get install asterisk” and they are done. We are much more in 
the hands of package managers and really,
really need to interface with them to get information out. Asterisk is a 
plumbing tool, much like nginx or apache. I don’t
follow those projects, haven’t built apache httpd from source for over ten 
years and get my information from packaging.

I think this has to be considered as well. 

Thanks Josh for pushing this process.

/O

> On 2 Oct 2020, at 00:45, Seán C McCord  wrote:
> 
> On Thu Oct 1, 2020 at 3:07 PM EDT, Joshua C. Colp wrote:
>> I think I personally hesitate to be so aggressive because long ago the
>> project was that way. We would push to remove things faster and such,
>> and the result was upset people and complaints. Years later I still had
>> people coming up to me at AstriCon talking about that stuff and how it 
>> screwed
>> them over.
> 
> I think this is a key point which we, as developers and integrators can 
> easily overlook.  We're being pulled in two direction:  one, we must always 
> keep up-to-date in our implementations, and two, we must be able to work with 
> what the customers are willing to use.  Once things are deprecated, it is far 
> easier to push the customer to do the right thing.  Removal makes this 
> easier.  Thus, faster deprecation and removal is better for the 
> integrator/developer/consultant.
> 
> But we do not represent more than the barest fraction of the Asterisk user 
> base.  The greater portion is running production workloads with very low 
> tolerance for either change or down-time, and are resultingly very 
> conservative with their upgrades and loathe to spend great effort into 
> managing those upgrades.
> 
> If we accelerate deprecation, we may end up making the problem _worse_ (as it 
> used to be), where users would simply not upgrade at all, because it was too 
> difficult to do so.
> 
> I agree that 4 years feels like an eternity to _me_, but to an operator 
> working with very slim margins, it is not nearly so glacial.
> 
> ---
> 
> Seán C McCord
> ule...@gmail.com
> PGP/GPG: https://cycoresys.com/scm.asc
> 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Support for amr codec?

[Olle E. Johansson]

> On 18 Aug 2020, at 10:49, Carsten Bock  wrote:
> 
> Hi,
> 
> one of the big issues with AMR/AMR-WB and Asterisk is that usually devices 
> speaking AMR/AMR-WB do use quite a lot of comfort noise, which is not 
> supported by Asterisk as far as I know.
Not in the regular Asterisk - I made a patch years ago in order to get through 
Lync certification…
It propably needs updating to support multiple noice declarations in the sdp.
/O
> Even if you use the patch from the above link, you might end up with some 
> distorted noise.
> 
> Thanks,
> Carsten
> --
> Carsten Bock I CTO & Founder
> 
> ng-voice GmbH
> Trostbrücke 1 I 20457 Hamburg I Germany
> T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com 
> 
> Registry Office at Local Court Hamburg, HRB 120189
> Managing Directors: Dr. David Bachmann, Carsten Bock
> 
> 
> Am Mo., 17. Aug. 2020 um 20:46 Uhr schrieb Joshua C. Colp  >:
> On Mon, Aug 17, 2020 at 3:40 PM Michael Maier  > wrote:
> Hello all!
> 
> Is there any official support for the amr codec in Asterisk? I couldn't find 
> any in asterisk 16.
> 
> There is a patch for Asterisk 13:
> https://github.com/traud/asterisk-amr 
> 
> There is no official support for it. 
> 
> -- 
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com  and 
> www.asterisk.org 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
>  --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev 
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

[Olle E. Johansson]

> On 19 Nov 2017, at 18:06, Nir Simionovich <nir.simionov...@gmail.com> wrote:
> 
> Hi Olle,
> 
>   Well, as I'm maintaining these packages mainly for our own deployments, I 
> don't mind making them
> available for the community - actually, we'll be happy to.
> 
>   Currently, the packages I have are for 4.4.6, and I'll see if I can create 
> the same for kamailio 5.1.X.
> 
>   From a naming convention point of view, would you believe building two 
> packages named kamailio4 and 
> kamailio5 be beneficial?
> 
Join the Kamailio dev mailing list and you’ll get the proper answers!

Cheers,
/O
> 
> 
> On Sun, Nov 19, 2017 at 12:56 PM Olle E. Johansson <o...@edvina.net 
> <mailto:o...@edvina.net>> wrote:
> 
>> On 16 Nov 2017, at 22:18, Nir Simionovich <nir.simionov...@gmail.com 
>> <mailto:nir.simionov...@gmail.com>> wrote:
>> 
>> and that the RPM repo for Kamailio is - how shall we put it, not providing 
>> all the possible modules. 
> 
> You are very welcome to contribute updates directly to the Kamailio project. 
> We’ve been looking
> for maintainers of the RPM specs for a long time - I am happy to see that you 
> are interested.
> 
> We have active maintainers of the Debian specs, so working in tandem should 
> not be hard.
> 
> Cheers,
> /O
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
> <http://www.api-digital.com/> --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev 
> <http://lists.digium.com/mailman/listinfo/asterisk-dev>
> -- 
> Kind Regards,
>   Nir Simionovich
>   GreenfieldTech
>   (schedule) http://nirsimionovich.appointy.com/ 
> <http://nirsimionovich.appointy.com/>
>   (w) http://www.greenfieldtech.net <http://www.greenfieldtech.net/> 
>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net 
> <mailto:n...@greenfieldtech.net>
>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com 
> <mailto:nir.simionov...@gmail.com>
>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
> 
> --
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud 
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
> -- 
> 
> Disclaimer:
> This e-mail is intended solely for the person to whom it is addressed and may 
> contain confidential or legally privileged information. Access to this e-mail 
> by anyone else is unauthorized. If an addressing or transmission error has 
> misdirected this e-mail, please notify the author by replying to this e-mail 
> and destroy this e-mail and any attachments. 
> E-mail may be susceptible to data corruption, interception, unauthorized 
> amendment, viruses and delays or the consequences thereof. If you are not the 
> intended recipient, be advised that you have received this email in error and 
> that any use, dissemination, forwarding, printing or copying of this email is 
> strictly prohibited.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

[Olle E. Johansson]

> On 16 Nov 2017, at 22:18, Nir Simionovich  wrote:
> 
> and that the RPM repo for Kamailio is - how shall we put it, not providing 
> all the possible modules. 
You are very welcome to contribute updates directly to the Kamailio project. 
We’ve been looking
for maintainers of the RPM specs for a long time - I am happy to see that you 
are interested.

We have active maintainers of the Debian specs, so working in tandem should not 
be hard.

Cheers,
/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AstDB mySQL implementation

[Olle E. Johansson]

> On 26 Oct 2017, at 15:25, Nir Simionovich <nir.simionov...@gmail.com> wrote:
> 
> I suspect the original code didn't change the overall mechanism dramatically, 
> it's mainly a new implementation.
> This thing is this - replacing the implementation seems straight forward 
> enough, making it configurable, seems
> like a pain in the butt.
Look for the “appleraisin” branch if you want to see code :-)

/O
> 
> 
> 
> On Thu, Oct 26, 2017 at 4:23 PM Olle E. Johansson <o...@edvina.net 
> <mailto:o...@edvina.net>> wrote:
>> On 26 Oct 2017, at 15:20, Nir Simionovich <nir.simionov...@gmail.com 
>> <mailto:nir.simionov...@gmail.com>> wrote:
>> 
>> Just looked into the code, this is not a simple task to put a new backend 
>> for astdb. The code isn't even designed
>> for something like that. Judging from what I can tell, and tell me if I'm 
>> wrong - turning this into a configurable thing
>> would be more or less an open-heart surgery.
> 
> My patch wasn’t that bad, but it was before sqlite.
> 
> /O
> 
>> 
>> 
>> 
>> On Thu, Oct 26, 2017 at 4:16 PM Olle E. Johansson <o...@edvina.net 
>> <mailto:o...@edvina.net>> wrote:
>> Somewhere in Asterisk space, there’s an old patch where I added ASTDB over 
>> realtime, meaning you can use 
>> any realtime storage. If I remember correctly there was a bit of 
>> chicken-and-egg problem with some astdb
>> calls happening before realtime got launched, but otherwise it worked just 
>> fine in production for a long time.
>> 
>> /O
>> 
>>> On 26 Oct 2017, at 15:13, Nir Simionovich <nir.simionov...@gmail.com 
>>> <mailto:nir.simionov...@gmail.com>> wrote:
>>> 
>>> I'd like to +1 on that idea.
>>> 
>>> While I'm somewhat reluctant to using mySQL as the base of such a change, 
>>> as mySQL is an overkill for AstDB,
>>> having a proper AstDB configurable backend is an interesting thing. 
>>> Personally speaking, I would actually prefer
>>> something like Memcache or preferably Redis. Both are similar in function 
>>> and usability to AstDB, both are fairly
>>> scalable (Redis specifically) and both are fairly simplistic in nature. 
>>> 
>>> I do admit that this got me intrigued... 
>>> 
>>> 
>>> 
>>> On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson <cres...@digium.com 
>>> <mailto:cres...@digium.com>> wrote:
>>> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner <rswago...@gmail.com 
>>> <mailto:rswago...@gmail.com>> wrote:
>>> I've been scaling out FreePBX horizontally with Kamailio and custom FreePBX 
>>> modules mainly to handle call center outbound dialing (around 20k calls per 
>>> day). One of the issues I ran into was FreePBX uses the AstDB extensively 
>>> and will write changes to it from the dialplan or the FreePBX user control 
>>> panel.
>>> 
>>> To overcome this I either needed to scrap FreePBX and build a new GUI using 
>>> Asterisk realtime, heavily modify FreePBX (not an option), or rewrite AstDB 
>>> to use a database like mySQL. I choose the last option and have had the 
>>> code in production for just over a month. I'm backing it with a two node 
>>> MariaDB Galera cluster with HAProxy providing failover for the client DB 
>>> connections.
>>> 
>>> I realize that SQLite was chosen for AstDB for performance reasons. However 
>>> mySQL seems to perform just fine in the above scenario. Right now I have a 
>>> db.c file that just has the mySQL code. Does anybody else have any interest 
>>> in using mySQL for the AstDB backend? I'm debating if it would make sense 
>>> to have the option to select your AstDB backend.
>>> 
>>> Hey Ryan,
>>> 
>>> First off, thanks for letting us know about the fun project you embarked 
>>> upon.  I think Josh already answered some of your questions, but with 
>>> regards to the work you did - I believe that in the past there have been 
>>> others who have wanted an ODBC AstDB driver as well.  If your code can be 
>>> made configurable, it may be a good contribution.
>>> 
>>> Anyways, hope you are doing well, and perhaps we'll see your code up on 
>>> gerrit at some time in the future. :-)
>>> 
>>> -- 
>>> Matthew Fredrickson
>>> Digium, Inc. | Engineering Manager
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> --
>>> _

Re: [asterisk-dev] AstDB mySQL implementation

[Olle E. Johansson]

> On 26 Oct 2017, at 15:20, Nir Simionovich <nir.simionov...@gmail.com> wrote:
> 
> Just looked into the code, this is not a simple task to put a new backend for 
> astdb. The code isn't even designed
> for something like that. Judging from what I can tell, and tell me if I'm 
> wrong - turning this into a configurable thing
> would be more or less an open-heart surgery.
My patch wasn’t that bad, but it was before sqlite.

/O
> 
> 
> 
> On Thu, Oct 26, 2017 at 4:16 PM Olle E. Johansson <o...@edvina.net 
> <mailto:o...@edvina.net>> wrote:
> Somewhere in Asterisk space, there’s an old patch where I added ASTDB over 
> realtime, meaning you can use 
> any realtime storage. If I remember correctly there was a bit of 
> chicken-and-egg problem with some astdb
> calls happening before realtime got launched, but otherwise it worked just 
> fine in production for a long time.
> 
> /O
> 
>> On 26 Oct 2017, at 15:13, Nir Simionovich <nir.simionov...@gmail.com 
>> <mailto:nir.simionov...@gmail.com>> wrote:
>> 
>> I'd like to +1 on that idea.
>> 
>> While I'm somewhat reluctant to using mySQL as the base of such a change, as 
>> mySQL is an overkill for AstDB,
>> having a proper AstDB configurable backend is an interesting thing. 
>> Personally speaking, I would actually prefer
>> something like Memcache or preferably Redis. Both are similar in function 
>> and usability to AstDB, both are fairly
>> scalable (Redis specifically) and both are fairly simplistic in nature. 
>> 
>> I do admit that this got me intrigued... 
>> 
>> 
>> 
>> On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson <cres...@digium.com 
>> <mailto:cres...@digium.com>> wrote:
>> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner <rswago...@gmail.com 
>> <mailto:rswago...@gmail.com>> wrote:
>> I've been scaling out FreePBX horizontally with Kamailio and custom FreePBX 
>> modules mainly to handle call center outbound dialing (around 20k calls per 
>> day). One of the issues I ran into was FreePBX uses the AstDB extensively 
>> and will write changes to it from the dialplan or the FreePBX user control 
>> panel.
>> 
>> To overcome this I either needed to scrap FreePBX and build a new GUI using 
>> Asterisk realtime, heavily modify FreePBX (not an option), or rewrite AstDB 
>> to use a database like mySQL. I choose the last option and have had the code 
>> in production for just over a month. I'm backing it with a two node MariaDB 
>> Galera cluster with HAProxy providing failover for the client DB connections.
>> 
>> I realize that SQLite was chosen for AstDB for performance reasons. However 
>> mySQL seems to perform just fine in the above scenario. Right now I have a 
>> db.c file that just has the mySQL code. Does anybody else have any interest 
>> in using mySQL for the AstDB backend? I'm debating if it would make sense to 
>> have the option to select your AstDB backend.
>> 
>> Hey Ryan,
>> 
>> First off, thanks for letting us know about the fun project you embarked 
>> upon.  I think Josh already answered some of your questions, but with 
>> regards to the work you did - I believe that in the past there have been 
>> others who have wanted an ODBC AstDB driver as well.  If your code can be 
>> made configurable, it may be a good contribution.
>> 
>> Anyways, hope you are doing well, and perhaps we'll see your code up on 
>> gerrit at some time in the future. :-)
>> 
>> -- 
>> Matthew Fredrickson
>> Digium, Inc. | Engineering Manager
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
>> <http://www.api-digital.com/> --
>> 
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev 
>> <http://lists.digium.com/mailman/listinfo/asterisk-dev>
>> -- 
>> Kind Regards,
>>   Nir Simionovich
>>   GreenfieldTech
>>   (schedule) http://nirsimionovich.appointy.com/ 
>> <http://nirsimionovich.appointy.com/>
>>   (w) http://www.greenfieldtech.net <http://www.greenfieldtech.net/> 
>>   (p) +972-73-2557799 (MSN): 
>> n...@greenfieldtech.net <mailto:n...@greenfieldtech.net>
>>   (m) +972-54-6982826   (GTALK): 
>> nir.simionov...@gmail.com <mailto:nir.simionov...@gmail.com>
>>   (f) +972-73-2557202   (SKYPE): greenfieldtech.n

Re: [asterisk-dev] AstDB mySQL implementation

[Olle E. Johansson]

Somewhere in Asterisk space, there’s an old patch where I added ASTDB over 
realtime, meaning you can use 
any realtime storage. If I remember correctly there was a bit of 
chicken-and-egg problem with some astdb
calls happening before realtime got launched, but otherwise it worked just fine 
in production for a long time.

/O

> On 26 Oct 2017, at 15:13, Nir Simionovich  wrote:
> 
> I'd like to +1 on that idea.
> 
> While I'm somewhat reluctant to using mySQL as the base of such a change, as 
> mySQL is an overkill for AstDB,
> having a proper AstDB configurable backend is an interesting thing. 
> Personally speaking, I would actually prefer
> something like Memcache or preferably Redis. Both are similar in function and 
> usability to AstDB, both are fairly
> scalable (Redis specifically) and both are fairly simplistic in nature. 
> 
> I do admit that this got me intrigued... 
> 
> 
> 
> On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson  > wrote:
> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner  > wrote:
> I've been scaling out FreePBX horizontally with Kamailio and custom FreePBX 
> modules mainly to handle call center outbound dialing (around 20k calls per 
> day). One of the issues I ran into was FreePBX uses the AstDB extensively and 
> will write changes to it from the dialplan or the FreePBX user control panel.
> 
> To overcome this I either needed to scrap FreePBX and build a new GUI using 
> Asterisk realtime, heavily modify FreePBX (not an option), or rewrite AstDB 
> to use a database like mySQL. I choose the last option and have had the code 
> in production for just over a month. I'm backing it with a two node MariaDB 
> Galera cluster with HAProxy providing failover for the client DB connections.
> 
> I realize that SQLite was chosen for AstDB for performance reasons. However 
> mySQL seems to perform just fine in the above scenario. Right now I have a 
> db.c file that just has the mySQL code. Does anybody else have any interest 
> in using mySQL for the AstDB backend? I'm debating if it would make sense to 
> have the option to select your AstDB backend.
> 
> Hey Ryan,
> 
> First off, thanks for letting us know about the fun project you embarked 
> upon.  I think Josh already answered some of your questions, but with regards 
> to the work you did - I believe that in the past there have been others who 
> have wanted an ODBC AstDB driver as well.  If your code can be made 
> configurable, it may be a good contribution.
> 
> Anyways, hope you are doing well, and perhaps we'll see your code up on 
> gerrit at some time in the future. :-)
> 
> -- 
> Matthew Fredrickson
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com 
>  --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev 
> 
> -- 
> Kind Regards,
>   Nir Simionovich
>   GreenfieldTech
>   (schedule) http://nirsimionovich.appointy.com/ 
> 
>   (w) http://www.greenfieldtech.net  
>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net 
> 
>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com 
> 
>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
> 
> --
>Zero Your Inbox  | Cloud 
> Servers 
> -- 
> 
> Disclaimer:
> This e-mail is intended solely for the person to whom it is addressed and may 
> contain confidential or legally privileged information. Access to this e-mail 
> by anyone else is unauthorized. If an addressing or transmission error has 
> misdirected this e-mail, please notify the author by replying to this e-mail 
> and destroy this e-mail and any attachments. 
> E-mail may be susceptible to data corruption, interception, unauthorized 
> amendment, viruses and delays or the consequences thereof. If you are not the 
> intended recipient, be advised that you have received this email in error and 
> that any use, dissemination, forwarding, printing or copying of this email is 
> strictly prohibited.
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 

Re: [asterisk-dev] Team branches in the asterisk repository

[Olle E. Johansson]

> On 25 Feb 2017, at 19:35, George Joseph  wrote:
> 
> No hurry but since the git migration and the availability of GitHub, do we 
> really need to keep the team branches at all?

An important aspect for me with all my subversion branches was that all the 
code was contributed under 
the license agreement for Digium to use. I also got a lot of help maintaining 
them with the automatic 
tools that was implemented in subversion, where, as an example, I got email 
when things broke and did not
merge automatically. This made it possible to maintain a large amount of 
branches.

With those tools gone I don’t benefit as much from using the central repository 
and no one else
seems to bother about the licensing part either, which I felt was important.

I haven’t found a new home for all my patches, so please keep them somewhere. 
Most of them
are in daily use with many large service providers over the world. I get 
feedback on their use
all the time. To me it feels like they’re an important part of code for the 
community, regardless
if they are integrated into the core distribution or not.

Thank you.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Registration state for SIP over TCP or TLS

[Olle E. Johansson]

> On 09 Jan 2017, at 19:52, Joshua Colp  wrote:
> 
> On Mon, Jan 9, 2017, at 02:10 PM, Steve Davies wrote:
>> Hi,
>> 
>> I believe that the current state of affairs with Asterisk's SIP over TCP
>> or
>> TLS registration is that if a connection is dropped or closed, then the
>> registration is allowed to persist.
>> 
>> Given that a re-connect will almost certainly not be from the same
>> IP/port
>> pair, should a TCP or TLS disconnect result in an under-the-hood
>> de-register?
>> 
>> I believe the issue does currently exist because I have seen dropped TCP
>> or
>> TLS connections result in an "xmit_error" when the next OPTIONS ping is
>> attempted.
>> 
>> Thoughts? Am I missing something, or would this be useful for me to look
>> into patching?
> 
> It... depends.
> 
> In a world with connection reuse you can assume that when the connection
> is dropped that you can't reach the other side anymore. However, if you
> are expected to establish an outgoing connection to the remote side then
> the logic that the connection has dropped and you can't reach them is
> not true. The Contact in that case should be valid.

THere are basically two situations to consider:

1. NAT: If there’s a connection from behind a NAT, asterisk can’t reconnect
and deleting the registration is propably for the best. Asterisk can only
reuse the inbound TLS connection is the client is using SIP Outbound.

2. Public IP: The TLS connection can ONLY be reused if the client use SIP 
outbound.
   Asterisk needs to set up a separate connection to the client as soon as we 
have a 
   request going in that direction, unless there’s a TLS client cert used and 
verified
   to match the contact URI.

I am trying to get some traction in the IETF for developing a solution for case 
#1
when there’s a TLS connection - a solution that doesn’t require that there is a
client cert or any use of SIP outbound. Right now, such a solution does not 
exist,
so Asterisk formally can’t reuse the inbound TLS connection for outbound 
requests.
Please support this work :-)

For more info, please visit
- http://www.slideshare.net/oej/sip-half-outbound-random-notes
- http://www.slideshare.net/oej/sip-tls-security-in-a-peer-to-peer-world

Kamailio actually reuse the inbound connection for outbound
requests, which is a working solution - but this requires a disregard of the 
Contact
URI provided by the client and a blind eye when reading the RFCs.

Removing registrations for clients behind NAT when 
a TCP or TCP/TLS or WSS connection dies saves a lot of resources.

/O




-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subscription behavior when an incoming registration goes away?

[Olle E. Johansson]

> On 22 Dec 2016, at 18:13, George Joseph <gjos...@digium.com> wrote:
> 
> 
> 
> On Thu, Dec 22, 2016 at 9:22 AM, Olle E. Johansson <o...@edvina.net 
> <mailto:o...@edvina.net>> wrote:
> 
>> On 22 Dec 2016, at 17:14, Matthew Jordan <mjor...@digium.com 
>> <mailto:mjor...@digium.com>> wrote:
>> 
>> 
>> 
>> On Thu, Dec 22, 2016 at 9:32 AM, George Joseph <gjos...@digium.com 
>> <mailto:gjos...@digium.com>> wrote:
>> When an incoming registration goes away, either because it expires or it was 
>> explicitly expired, what should we do with subscriptions the contact may 
>> have?  Right now we do nothing which means that activity for those 
>> subscriptions will trigger NOTIFYs which will time out and retry until 
>> timer_b expires.  Only then will they be deleted.
>> 
>> Should we:
>> Leave the behavior as is?
>> Automatically remove the subscriptions for a contact that has been deleted?
>> Create a global option to control auto deletion?
>> Create an aor option to control auto deletion?
>> Opinions?
>> 
>> 
>> If an AoR only has dynamic contacts, and those dynamic contacts are no 
>> longer valid (or the AoR no longer has any contacts), then at the very least 
>> I would think we wouldn't want to send the NOTIFY requests until the AoR has 
>> valid contacts. There's certainly no reason to use memory/CPU cycles on 
>> something that will never succeed.
>> 
>> You may or may not want to actually remove the underlying subscription. I 
>> could see a scenario in which a phone's REGISTER request goes "missing", and 
>> so the registration drops - maybe for just a short period of time. When the 
>> new REGISTER request does succeed, the phone may or may not send a new 
>> SUBSCRIBE request (which may have a very different timer). If we 
>> auto-deleted the underlying subscription, we could have a situation where 
>> the phone is re-registered but no longer receives state updates.
>> 
>> I'll grant the above scenario is pretty unlikely, but it is plausible.
> 
> Without knowing the details of the PJSIP channel this conversation seems all 
> upside down to me.
> Subscriptions provide their own contact for the NOTIFY and have no 
> relationship to the REGISTER message.
> 
> There's no protocol level relationship but there is a functional 
> relationship.  If a phone with 15 BLF subscriptions goes missing and we can 
> correlate the expired registration contact with the subscription contact, 
> should we bother sending NOTIFYs that we know will timeout and need to be 
> retried?
>  
It all depends on how you determine that a device “goes missing” but the cool 
thing with subscriptions is that a server can
terminate the subscription early by sending a notify. If the phone considers 
itself alive and kicking, it will send a re-subscribe
to fight your decision. I would say that the correlation should be 
“sip-instance”, the UUID of the device, to be good enough
to do this.

I think this happens in chan_sip if an extension disappears at dialplan reload 
and we have active subscriptions for it
- we terminate the subscription from the server side. Kevin and I worked on 
that part a long time ago.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subscription behavior when an incoming registration goes away?

[Olle E. Johansson]

> On 22 Dec 2016, at 17:14, Matthew Jordan  wrote:
> 
> 
> 
> On Thu, Dec 22, 2016 at 9:32 AM, George Joseph  > wrote:
> When an incoming registration goes away, either because it expires or it was 
> explicitly expired, what should we do with subscriptions the contact may 
> have?  Right now we do nothing which means that activity for those 
> subscriptions will trigger NOTIFYs which will time out and retry until 
> timer_b expires.  Only then will they be deleted.
> 
> Should we:
> Leave the behavior as is?
> Automatically remove the subscriptions for a contact that has been deleted?
> Create a global option to control auto deletion?
> Create an aor option to control auto deletion?
> Opinions?
> 
> 
> If an AoR only has dynamic contacts, and those dynamic contacts are no longer 
> valid (or the AoR no longer has any contacts), then at the very least I would 
> think we wouldn't want to send the NOTIFY requests until the AoR has valid 
> contacts. There's certainly no reason to use memory/CPU cycles on something 
> that will never succeed.
> 
> You may or may not want to actually remove the underlying subscription. I 
> could see a scenario in which a phone's REGISTER request goes "missing", and 
> so the registration drops - maybe for just a short period of time. When the 
> new REGISTER request does succeed, the phone may or may not send a new 
> SUBSCRIBE request (which may have a very different timer). If we auto-deleted 
> the underlying subscription, we could have a situation where the phone is 
> re-registered but no longer receives state updates.
> 
> I'll grant the above scenario is pretty unlikely, but it is plausible.

Without knowing the details of the PJSIP channel this conversation seems all 
upside down to me.
Subscriptions provide their own contact for the NOTIFY and have no relationship 
to the REGISTER message.


Unless you are discussing a Subscription for registration status - but even so 
your discussion is not parseable in my eyes ;-)

Sorry for the intrusion

/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Strategies for handling RTCP feedback in codec modules

[Olle E. Johansson]

Let’s extend this “how to communicate with a codec” discussion and add the need 
for feedback
on silence. I think there’s an old mail from Matt Jordan touching this earlier. 
My code for silence suppression
and comfort noise adds un-needed transcoding and needed a way for a codec to 
communicate stuff
back to the RTP channel.

(Not 100% sure that it belongs in the same discussion, but I wanted to give it 
a try :-)   )
/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace

[Olle E. Johansson]

Hi!

From my perspective I know that maintaining a SIP stack requires *A LOT* of 
effort, so I understand that a project can’t maintain two of them.

I suggest that a working group is created for the transition and that the first 
task is to compare the functionality. 
Last time I checked the functionality *I need* (but maybe not everyone else) 
was non-existing in PJSIP so I could not use it.
It may have changed since then.

I think the goal has to be to gradually phase out the ugly code in chan_sip and 
celebrate the day it’s gone, but
make sure we don’t leave functionality (and users) behind and have good 
guidelines for the transition.

I still think we should totally rewrite how chan_pjsip is configured. That 
concept is very far away from other SIP implementations.
But that’s my personal opinion from a small cold corner of the world, using 
Asterisk in non-PBX ways as large scale media 
and feature servers.

Executive summary: Create a working group that maintains the feature gap, makes 
sure it’s going away and also makes sure
that we have enough material that explains the gold that hides in chan_pjsip!

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] strictrtp seems to be not so strict

[Olle E. Johansson]

> On 26 Aug 2016, at 14:29, Joshua Colp  wrote:
> 
> Torrey Searle wrote:
>> I wouldn't dare change the default :-)
>> 
>> But the way I understand the code is that it would end up being a
>> switching, as getting a packet from the current source doesn't seem to
>> re-set the counter.
>> 
>> I'll do the following,
>> change the conf validation to allow probation = 0  (default will remain 4)
>> 
>> if learning_min_sequential is 0, the else in
>> 
>> if (rtp->strict_rtp_state == STRICT_RTP_CLOSED) {
>> if (!ast_sockaddr_cmp(>strict_rtp_address, )) {
>> 
>> will be disabled
> 
> If an attacker were aggressive with the sending of the RTP and were able to 
> get enough packets in before a legit one, yes. As it is the reception of a 
> legit packet resets the counter each time (the call to rtp_learning_seq_init) 
> so under normal usage a rogue stream can't cause it to switch.

Also note that if there’s ICE support this function needs to be disabled. We 
lock on the one sending us the right credentials in ICE

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Development of asterisk 1.4.23 Can we please get some development?

[Olle E. Johansson]

> On 15 Jul 2016, at 16:51, Matthew Jordan  wrote:
> 
> The modules you are referring to were removed quite awhile ago due to not 
> having an active maintainer contributing to the project [1]. Since no one 
> active in the project used the modules, or could verify their functionality, 
> and those who were using them had forked Asterisk completely, we opted to 
> remove them rather than ship broken or vulnerable code.
> 
> I do not think that anyone in Digium is interested in maintaining these 
> modules, nor is anyone here interested in doing the port of the old 1.4 
> modules to the existing code base. I think all of us would be happy to answer 
> questions, but someone else in the greater Asterisk community would have to 
> do the work and commit to being the maintainer of those modules.
> 
> Asterisk is an open source project. As an open source project, anyone - 
> absolutely *anyone* - can step up, modify the existing 
> app_rpt/chan_usbradio/core of Asterisk, and submit the patches back to the 
> project. We have a lot of resources to help with that:


+1
We did try to communicate with the contacts we had back then but failed to get 
any response, so we gave up. It wasn’t Digium as a company, it was us all 
working with the project. We 
did not understand the code and could not maintain it.

I would be very happy to see the repeater code coming back to the tree and 
staying up to date in the tree , but that will, as Matt points out, require 
active maintainers.

Regards,
/Olle

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Menuselect missing from 1.8 branches

[Olle E. Johansson]

> On 31 May 2016, at 18:23, George Joseph <gjos...@digium.com> wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 9:11 AM, Olle E. Johansson <o...@edvina.net 
> <mailto:o...@edvina.net>> wrote:
> Hi!
> 
> I think Menuselect used to be an include from another svn repo and now it’s 
> missing from my git repos.
> I need to resurrect some of them for some certification tests.
> 
> Can anyone help this old man on how to get menuselect back? Is there a 
> specfic commit I can cherrypick
> or should I just copy the whole thing from the 1.8 branch and add a git 
> ignore on it?
> 
> Yeah, you can just do "git checkout 11 -- menuselect" then add it to 
> .gitignore.
>  
Great but git says “fatal: invalid reference: 11”

Maybe it’s because I checkout out just a single branch, not the full repo.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Menuselect missing from 1.8 branches

[Olle E. Johansson]

Hi!

I think Menuselect used to be an include from another svn repo and now it’s 
missing from my git repos.
I need to resurrect some of them for some certification tests.

Can anyone help this old man on how to get menuselect back? Is there a specfic 
commit I can cherrypick
or should I just copy the whole thing from the 1.8 branch and add a git ignore 
on it?

Thanks,
/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Configuring Request URI with outbound proxyu

[Olle E. Johansson]

> On 13 Apr 2016, at 22:05, Nitesh Bansal  wrote:
> 
> Hello,
> 
> I want to use Asterisk to use Kamailio as an outbound proxy for routing calls 
> to remote SIP end points, one option could be to use a default peer, but in 
> my case, my outbound proxy can change 
> based on the remote end point, so this option doesn't work.
> And another problem is that I don't know how to configure Asterisk to prepare 
> the Request-URI
> based on the remote end point and not based on the outbound proxy address?
> 
> What is the best way to do it?

First, you are asking the wrong mailing list. This is not second-level support 
- this is for development and code questions.

If you are using chan_sip, there is a setting of outbound proxy per peer. There 
are settings
for domain - both in r-uri (host) and from URI domain. 

If you set host=example.com  and outbound proxy to 
example.net  the SIP request will
have example.com  in the R-uri and send the request to 
example.net 

Good luck working with Kamailio!

/Olle


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Certified asterisk patches not in trunk?

[Olle E. Johansson]

From the web page:

"Certified Asterisk releases have undergone additional testing and are made 
less frequently - typically two to four times a year. Certified Asterisk 
releases are generally identical to the Long Term Support release they are 
based on, save for additional bug fixes that were applied during testing.”

http://www.asterisk.org/downloads/asterisk/all-asterisk-versions

I hope that this is wrong - that Certified Asterisk has patches for bug fixes 
not included in the LTS release. 

/O

smime.p7s
Description: S/MIME cryptographic signature
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Certified asterisk patches not in trunk?

[Olle E. Johansson]

> On 11 Feb 2016, at 13:06, Joshua Colp <jc...@digium.com> wrote:
> 
> Olle E. Johansson wrote:
>> From the web page:
>> 
>> "Certified Asterisk releases have undergone additional testing and
>> are made less frequently - typically two to four times a year.
>> Certified Asterisk releases are generally identical to the Long Term
>> Support release they are based on, save for additional bug fixes that
>> were applied during testing.”
>> 
>> http://www.asterisk.org/downloads/asterisk/all-asterisk-versions
>> 
>> I hope that this is wrong - that Certified Asterisk has patches for
>> bug fixes not included in the LTS release.
> 
> The statement is correct from the perspective of Certified. Since Certified 
> releases are based off one LTS release (Certified 13.1 is based off Asterisk 
> 13.1) they don't have any bug fixes that came later. Therefore when an issue 
> is found during testing either a fix is backported from the normal 13 branch 
> or if a new fix is created it is applied to all applicable branches just like 
> a normal fix. The statement above is trying to convey that Certified is the 
> LTS release + additional things not present in the original (Certified 13.1 
> != Asterisk 13.1 in the end). There are no fixes in Certified that are not 
> present in the normal branches.

THat last sentence does not agree with the quote. Please update the web page to 
assure 
everyone that the LTS has these patches.

Yes, I gotten confused users contact me about this. “We need certified because 
there are bug fixes in there that is not included in other releases”. We need 
to be very, very clear :-)

/O

smime.p7s
Description: S/MIME cryptographic signature
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Certified asterisk patches not in trunk?

[Olle E. Johansson]

> On 11 Feb 2016, at 16:29, Rusty Newton <rnew...@digium.com> wrote:
> 
> On Thu, Feb 11, 2016 at 6:43 AM, Olle E. Johansson <o...@edvina.net> wrote:
> 
> 
> 
>> THat last sentence does not agree with the quote. Please update the web page 
>> to assure
>> everyone that the LTS has these patches.
> 
> The page has been updated. Thanks!

Thank you for a quick response. I don’t see it yet, but I guess it will be 
pushed out on the network soon :-)

/O

smime.p7s
Description: S/MIME cryptographic signature
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Bug marshals back !

[Olle E. Johansson]

Yay!

I notice in a bug report that the response talks about  a Bug Marshal. I am 
very happy that we have bug marshals back in the process. Is there a document 
somewhere outlining the process of becoming one and what they do nowadays?

Cheers,
/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Team branches and gerrit

[Olle E. Johansson]

On 24 Apr 2015, at 15:42, Russell Bryant russ...@russellbryant.net wrote:

 On Fri, Apr 24, 2015 at 8:31 AM, Joshua Colp jc...@digium.com wrote:
 Olle E. Johansson wrote:
 Playing around following Matt's wiki page on gerrit usage, I created
 a team branch and did two commits. When pushing it with git review
 {branch} only the last commit shows up.
 
 Is that the way it's supposed to be? I thought the whole branch was
 the review subject, not just a single commit.
 
 Gerrit works on a single commit (what it refers to as a patch set) that you 
 want included into a specific branch. As a result you need to squash all 
 commits into a single one, and if review feedback warrants further changes 
 they also need to be squashed back into a single commit with the original 
 changes. The single commit you post for review is what is reviewed and merged 
 into the branch.
 
 Gerrit can also work on a patch series, and tracks dependencies between those 
 patches.

Define patch series - how do you commit a series of patches for review?

/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Team branches and gerrit

[Olle E. Johansson]

On 27 Apr 2015, at 14:55, Russell Bryant russ...@russellbryant.net wrote:

 On Mon, Apr 27, 2015 at 8:20 AM, Olle E. Johansson o...@edvina.net wrote:
 
 On 24 Apr 2015, at 15:42, Russell Bryant russ...@russellbryant.net wrote:
 
 On Fri, Apr 24, 2015 at 8:31 AM, Joshua Colp jc...@digium.com wrote:
 Olle E. Johansson wrote:
 Playing around following Matt's wiki page on gerrit usage, I created
 a team branch and did two commits. When pushing it with git review
 {branch} only the last commit shows up.
 
 Is that the way it's supposed to be? I thought the whole branch was
 the review subject, not just a single commit.
 
 Gerrit works on a single commit (what it refers to as a patch set) that you 
 want included into a specific branch. As a result you need to squash all 
 commits into a single one, and if review feedback warrants further changes 
 they also need to be squashed back into a single commit with the original 
 changes. The single commit you post for review is what is reviewed and 
 merged into the branch.
 
 Gerrit can also work on a patch series, and tracks dependencies between 
 those patches.
 
 Define patch series - how do you commit a series of patches for review?
 
 In some cases, it makes sense for a feature or fix to be proposed as multiple 
 changes in a series.  I feel that it makes things easier to review and 
 understand.
 
 As a completely realistic example, let's assume we want to add support for 
 toaster control to chan_pjsip.  That could be submitted as a series of 3 
 commits:
 
 1 - ast_toaster: Add core modular API for toaster control.
 2 - toastip - Add ast_toaster backend for the toastip protocol.
 3 - pjsip_toast - Add chan_pjsip integration with the ast_toaster API. 
 
 Those *could* all be one commit, but it's really the development of a feature 
 in 3 logical chunks, so breaking it up like this is an alternative.
 
 When it comes to what that actually looks like it git.
 
 Create a local branch for a feature:
 
   $ cd asterisk-git
   $ git checkout -b example-patch-series origin/master
 
 Commit 1:
 
   $ echo some text  foo
   $ git add foo
   $ git commit -m Add foo
 
 Commit 2:
 
   $ echo some more text  foo
   $ git commit -a -m Add more text to foo
 
 We now have 2 commits on top of the master branch:
 
   $ git log --oneline origin/master..HEAD
   5a53b4f Add more text to foo.
   4bf86fa Add foo.
 
 Post series of 2 commits for review:
 
   $ git review
   You are about to submit multiple commits. This is expected if you are
   submitting a commit that is dependent on one or more in-review
   commits. Otherwise you should consider squashing your changes into one
   commit before submitting.
 
   The outstanding commits are:
 
   5a53b4f (HEAD, example-patch-series) Add more text to foo.
   4bf86fa Add foo.
 
   Do you really want to submit the above commits?
   Type 'yes' to confirm, other to cancel: 
 
 (You would type 'yes' here because you're submitting 2 changes for review 
 intentionally.)
 
 Here's a wiki page that I think does a nice job laying out some reasoning 
 behind best practices for breaking up changes into a series of commits if 
 anyone is interested:
 
   https://wiki.openstack.org/wiki/GitCommitMessages
 
THat makes sense.

/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Team branches and gerrit

[Olle E. Johansson]

Playing around following Matt's wiki page on gerrit usage, I created a team 
branch and did two commits. When pushing it with git review {branch} only the 
last commit shows up.

Is that the way it's supposed to be? I thought the whole branch was the review 
subject, not just a single commit.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] s?rtp via SIP/TLS/TCP

[Olle E. Johansson]

On 21 Apr 2015, at 17:55, James Cloos cl...@jhcloos.com wrote:

 OEJ == Olle E Johansson o...@edvina.net writes:
 
 OEJ It's a bug in chan_sip that I fixed a while ago in one of my branches.
 OEJ SNOM sends an SDES key but RTP/AVP in the offer and chan_sip
 OEJ chokes. It's a one or two line fix - or turn off SRTP in the SNOM.
 
 I presume this one?:
 
 sdes-rtp-avp.diff:
 Index: channels/chan_sip.c
 ===
 --- channels/chan_sip.c   (revision 417744)
 +++ channels/chan_sip.c   (working copy)
 @@ -9603,7 +9603,7 @@
   if (audio) {
   if (process_sdp_a_sendonly(value, 
 sendonly)) {
   processed = TRUE;
 - } else if (!processed_crypto  
 process_crypto(p, p-rtp, p-srtp, value)) {
 + } else if (secure_audio  
 !processed_crypto  process_crypto(p, p-rtp, p-srtp, value)) {
   processed_crypto = TRUE;
   processed = TRUE;
   } else if (process_sdp_a_audio(value, 
 p, newaudiortp, last_rtpmap_codec)) {
 
 But, as I wrote, it still failed w/o rtp crypto and forcing avpf works.

Would be interesting to see the INVITE.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] s?rtp via SIP/TLS/TCP

[Olle E. Johansson]

On 20 Apr 2015, at 17:41, James Cloos cl...@jhcloos.com wrote:

 I'm not sure whether this is a bug, so I'm starting here.
 
 My remote asterisk (debian's compile of 13, currently 13.1.0) and my
 snom had been unable to rtp for some time.  I still use chan_sip.
 
 It took a few hours of testing, but I determined that when the phone
 registers and/or invites over tls, asterisk refuses to do either un-
 encrypted rtp or srtp unless force_avp=yes.
 
 The symptom was a hangup w/ unknown cause as soon as it was time to
 start rtp.  Ie, right after the OK.  Even with verbose and debug set
 to 9 no explanation was logged.  When I tried adding force_avp=yes
 everything started working again.
 
 I don't know when it stopped working (I don't get enough calls and
 send outgoing via a different asterisk); I presume that it stopped
 working when force_avp was added, but cannot confirm that.
 
 Is force_avp supposed to be required for non-dtls rtp when sip is
 secure?

It's a bug in chan_sip that I fixed a while ago in one of my branches.
SNOM sends an SDES key but RTP/AVP in the offer and chan_sip
chokes. It's a one or two line fix - or turn off SRTP in the SNOM.

As Matt says, SNOM offers both RTP/AVP and SAVP in the
same SDP - but there's no reason for Asterisk to refuse the SDP
just because it finds SDES keys in what it parses as RTP/AVP.
A simple bug.

I am currently a bit lost in the conversion from SVN to GIT and haven't
got the source codes on this laptop, so I can't point to where the patch
is. Somewhere in the patches directory in the teapot branch is a good
guess.

Cheers,
/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Branches

[Olle E. Johansson]

How do I push changes to my branches? If I try a git push my gerrit 
username/password doesn't work.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Review Request: DNS NAPTR/SRV Test plan for PJSIP

[Olle E. Johansson]

First quick observation: please don't use .internal. There are domains for 
example use, like example.com or internal use - and that's .local

There are a lot of tests in the SIPit site you can play with to get more 
inspiration.

/O

On 13 Apr 2015, at 20:11, Mark Michelson mmichel...@digium.com wrote:

 I have created a wiki page [1] with a test plan for DNS NAPTR/SRV for PJSIP. 
 Please take a moment to have a look at the page and provide any feedback (on 
 this list, not on the page please) about the test plan. Are there any test 
 cases that I left out that should be covered? Are there any test cases that 
 need further explanation?
 
 Any sections on the page that are notes (meaning they are yellow with an 
 exclamation point in the top-left corner) means that I have asserted some 
 interpretation of the relevant RFCs but that my assertion may be up for 
 debate. Please feel free to give counterarguments if you interpret passages 
 differently from me or if you know of real-world scenarios where my 
 interpretation will run into problems.
 
 Thank you very much!
 
 [1] https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=32375195
 
 -- 
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Subjects for e-mails

[Olle E. Johansson]

Can we possibly have different Subject: lines in e-mails for a commit and for a 
review. Seems like 
everything is a change in asterisk now. I would like to be able to prioritize 
reading the
commits.

THanks,
/O

Begin forwarded message:

 From: Matt Jordan (Code Review) asteriskt...@digium.com
 Subject: [asterisk-dev] Change in asterisk[1.8]: build_tools/make_version: 
 Update version parsing for Git mig...
 Date: 13 Apr 2015 19:03:10 GMT+2
 Reply-To: mjor...@digium.com, Asterisk Developers Mailing List 
 asterisk-dev@lists.digium.com
 
 Matt Jordan has submitted this change and it was merged.
 
 Change subject: build_tools/make_version: Update version parsing for Git 
 migration
 ..
 
 
 build_tools/make_version: Update version parsing for Git migration
 
 External systems - such as the Asterisk Test Suite - require knowledge of the
 upstream branch. Unfortunately, after moving to Git, the Asterisk version
 currently consists of only a 'GIT prefix followed by an object blob,
 e.g., GIT-as08d7. This makes it difficult for such systems to know what
 features are available in a particular check out of Asterisk.
 
 This patch fixes this by hardcoding the branch in a variable in the
 make_version script. Since the mainline branches are not changed often -
 typically only once a year - this is a reasonable approach to solving
 the problem, and is more reliable than parsing the output of 'git branch
 -vv'. Branches that track off of an upstream primary branch will then get the
 benefit of knowing which mainline branch they are currently based off
 of.
 
 ASTERISK-24954 #close
 
 Change-Id: I8090d5d548b6d19e917157ed530b914b7eaf9799
 ---
 M build_tools/make_version
 1 file changed, 5 insertions(+), 3 deletions(-)
 
 Approvals:
  Matt Jordan: Looks good to me, approved; Verified
  George Joseph: Looks good to me, but someone else must approve
 
 
 
 diff --git a/build_tools/make_version b/build_tools/make_version
 index de0b97e..556021c 100755
 --- a/build_tools/make_version
 +++ b/build_tools/make_version
 @@ -1,5 +1,7 @@
 #!/bin/sh
 
 +MAINLINE_BRANCH=1.8
 +
 if [ -f ${1}/.version ]; then
 cat ${1}/.version
 elif [ -d ${1}/.svn ]; then
 @@ -94,16 +96,16 @@
 MODIFIED=
 SVN_REV=`${GIT} log --pretty=full -1 | grep -F git-svn-id: | sed -e 
 s/.*\@\([^\s]*\)\s.*/\1/g`
 if [ -z $SVN_REV ]; then
 -VERSION=GIT-`${GIT} describe --long --always --tags --dirty=M 2 
 /dev/null`
 +VERSION=`${GIT} describe --long --always --tags --dirty=M 2 
 /dev/null`
 if [ $? -ne 0 ]; then
 if [ `${GIT} ls-files -m | wc -l` != 0 ]; then
 MODIFIED=M
 fi
 # Some older versions of git do not support all the above
 # options.
 -VERSION=GIT-`${GIT} rev-parse --short --verify HEAD`${MODIFIED}
 +VERSION=`${GIT} rev-parse --short --verify HEAD`${MODIFIED}
 fi
 -echo ${VERSION}
 +echo GIT-${MAINLINE_BRANCH}-${VERSION}
 else
 PARTS=`LANG=C ${GIT} log --pretty=full | grep -F git-svn-id: | head 
 -1 | awk '{print $2;}' | sed -e s:^.*/svn/$2/:: | sed -e 's:/: :g' | sed -e 
 's/@.*$//g'`
 BRANCH=0
 
 -- 
 To view, visit https://gerrit.asterisk.org/76
 To unsubscribe, visit https://gerrit.asterisk.org/settings
 
 Gerrit-MessageType: merged
 Gerrit-Change-Id: I8090d5d548b6d19e917157ed530b914b7eaf9799
 Gerrit-PatchSet: 1
 Gerrit-Project: asterisk
 Gerrit-Branch: 1.8
 Gerrit-Owner: Matt Jordan mjor...@digium.com
 Gerrit-Reviewer: George Joseph george.jos...@fairview5.com
 Gerrit-Reviewer: Matt Jordan mjor...@digium.com
 
 -- 
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subjects for e-mails

[Olle E. Johansson]

On 14 Apr 2015, at 17:06, Russell Bryant russ...@russellbryant.net wrote:

 On Tue, Apr 14, 2015 at 10:55 AM, Matthew Jordan mjor...@digium.com wrote:
 On Tue, Apr 14, 2015 at 9:43 AM, Dan Jenkins dan.jenkin...@gmail.com wrote:
 
  On Tue, Apr 14, 2015 at 3:18 PM, Russell Bryant russ...@russellbryant.net
  wrote:
 
  On Tue, Apr 14, 2015 at 8:47 AM, Matthew Jordan mjor...@digium.com
  wrote:
 
  On Tue, Apr 14, 2015 at 2:15 AM, Olle E. Johansson o...@edvina.net
  wrote:
   Can we possibly have different Subject: lines in e-mails for a commit
   and for a review. Seems like
   everything is a change in asterisk now. I would like to be able to
   prioritize reading the
   commits.
  
 
  I took a look at the Gerrit settings, and it doesn't appear to support
  that:
 
  https://gerrit-review.googlesource.com/Documentation/user-notify.html
 
  and:
 
 
  https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sendemail
 
  It does support having commits go to a separate list than reviews;
  that should already be set up for the asterisk-commits list (although
  the last tweaks on it just went in yesterday).
 
 
  With gerrit it's actually pretty easy to subscribe to the messages you
  want.  You can get notified for new reviews, when patches are updated, when
  patches merge, or when people make comments (all optionally on a per
  repository basis).  So, another option would be to drop sending to the list
  completely and let people configure their own notifications that suit their
  needs and interests.
 
  --
  Russell Bryant
 
  --
  _
  -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
  asterisk-dev mailing list
  To UNSUBSCRIBE or update options visit:
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 
 
  I like this idea Russell
 
 Given that the e-mails are now only going to the asterisk-commits and
 asterisk-code-review lists - and not the asterisk-dev list - I think a
 combination of both options is probably okay.
 
 * If you want to see the spam, subscribe to the lists
 * If you want personalized e-mail notifications, set it up through Gerrit
 
 Yep, makes sense.  I missed the update about notifications only going to the 
 new list before posting the above.
Agree.
If someone could hack the Subject: lines in Gerrit I would be very happy... :-)
/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4597: res_pjsip: add CLI commands for global and system configuration

[Olle E Johansson]

 On April 7, 2015, 9:55 p.m., Olle E Johansson wrote:
  global is used for global variabels. Other CLI commands have show 
  settings - can't we reuse the same with some extra options for system?
 
 rmudgett wrote:
 Where are you getting global variables from the command?
 
 pjsip show global gives the settings for the pjsip.conf [global] 
 section.
 
 The command seems aptly named.
 
 Olle E Johansson wrote:
 core show global has for a long time been used to show global 
 variables. For settings we've used show settings both in core and in SIP - 
 maybe other modules. 
 
 If we are going to use global for something else, then it will be 
 confusing. We only have a global section previously in the dialplan - in 
 other modules it's mostly called general.
 
 But if you already broke this, I rest my case. Just wanted to point out 
 that I feel it's strange.
 
 Kevin Harwell wrote:
 I tend to agree with both opinions, but since consistency is a good thing 
 and doing a quick survey of some other commands most seem to use the show 
 settings. Also it allowed me to combine the two commands into one: pjsip 
 show settings.

Thank you Kevin. Consistency helps keeping the learning curve down.


- Olle E


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4597/#review15109
---


On April 8, 2015, 12:35 a.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4597/
 ---
 
 (Updated April 8, 2015, 12:35 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24918
 https://issues.asterisk.org/jira/browse/ASTERISK-24918
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Added two new CLI commands for res_pjsip global and system configuration 
 settings:
 
 pjsip show global
 pjsip show system
 
 
 Diffs
 -
 
   branches/13/res/res_pjsip/include/res_pjsip_private.h 434150 
   branches/13/res/res_pjsip/config_system.c 434150 
   branches/13/res/res_pjsip/config_global.c 434150 
   branches/13/res/res_pjsip.c 434150 
   branches/13/CHANGES 434150 
 
 Diff: https://reviewboard.asterisk.org/r/4597/diff/
 
 
 Testing
 ---
 
 Ran the commands and checked output. Changed some options and reloaded and 
 made sure global settings changed, but system ones did not. Changed some 
 settings again and restarted and made sure both global and system changes too 
 effect. Also removed the sections completely from the pjsip.conf file and 
 made sure the defaults were shown.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4597: res_pjsip: add CLI commands for global and system configuration

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4597/#review15109
---


global is used for global variabels. Other CLI commands have show settings 
- can't we reuse the same with some extra options for system?

- Olle E Johansson


On April 7, 2015, 6:05 p.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4597/
 ---
 
 (Updated April 7, 2015, 6:05 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24918
 https://issues.asterisk.org/jira/browse/ASTERISK-24918
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Added two new CLI commands for res_pjsip global and system configuration 
 settings:
 
 pjsip show global
 pjsip show system
 
 
 Diffs
 -
 
   branches/13/res/res_pjsip/config_system.c 434150 
   branches/13/res/res_pjsip/config_global.c 434150 
   branches/13/CHANGES 434150 
 
 Diff: https://reviewboard.asterisk.org/r/4597/diff/
 
 
 Testing
 ---
 
 Ran the commands and checked output. Changed some options and reloaded and 
 made sure global settings changed, but system ones did not. Changed some 
 settings again and restarted and made sure both global and system changes too 
 effect. Also removed the sections completely from the pjsip.conf file and 
 made sure the defaults were shown.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4563: chan_sip: handle IPv4 mapped clients when NAT and IPv6 socket is enabled

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4563/#review15110
---


Did this really apply to all operating systems and all versions of Linux? We 
had a discussion about it when the IPv6 support was added, but I don't remember 
all the details - but something with the mapping was O/S and sysctl dependent.

- Olle E Johansson


On March 30, 2015, 4:23 p.m., Valentin Vidić wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4563/
 ---
 
 (Updated March 30, 2015, 4:23 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-18032
 https://issues.asterisk.org/jira/browse/ASTERISK-18032
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 When udpbindaddr=:: is set Asterisk accepts IPv4 and IPv6 clients both stored 
 in a struct sockaddr_in6 with AF_INET6 family type. Current NAT code for IPv4 
 checks if the socket type is AF_INET6 and thus fails to handle IPv4 mapped 
 addresses properly. The patch adds an additional check for this case allowing 
 IPv4 clients to be handled by NAT even when IPv6 is enabled.
 
 
 Diffs
 -
 
   /branches/11/channels/chan_sip.c 433794 
 
 Diff: https://reviewboard.asterisk.org/r/4563/diff/
 
 
 Testing
 ---
 
 Patch solves the problem of failing incoming calls on a local NATed 
 installation with IPv6 sockets enabled.
 
 
 Thanks,
 
 Valentin Vidić
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4597: res_pjsip: add CLI commands for global and system configuration

[Olle E Johansson]

 On April 7, 2015, 9:55 p.m., Olle E Johansson wrote:
  global is used for global variabels. Other CLI commands have show 
  settings - can't we reuse the same with some extra options for system?
 
 rmudgett wrote:
 Where are you getting global variables from the command?
 
 pjsip show global gives the settings for the pjsip.conf [global] 
 section.
 
 The command seems aptly named.

core show global has for a long time been used to show global variables. For 
settings we've used show settings both in core and in SIP - maybe other 
modules. 

If we are going to use global for something else, then it will be confusing. 
We only have a global section previously in the dialplan - in other modules 
it's mostly called general.

But if you already broke this, I rest my case. Just wanted to point out that I 
feel it's strange.


- Olle E


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4597/#review15109
---


On April 7, 2015, 6:05 p.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4597/
 ---
 
 (Updated April 7, 2015, 6:05 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24918
 https://issues.asterisk.org/jira/browse/ASTERISK-24918
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Added two new CLI commands for res_pjsip global and system configuration 
 settings:
 
 pjsip show global
 pjsip show system
 
 
 Diffs
 -
 
   branches/13/res/res_pjsip/config_system.c 434150 
   branches/13/res/res_pjsip/config_global.c 434150 
   branches/13/CHANGES 434150 
 
 Diff: https://reviewboard.asterisk.org/r/4597/diff/
 
 
 Testing
 ---
 
 Ran the commands and checked output. Changed some options and reloaded and 
 made sure global settings changed, but system ones did not. Changed some 
 settings again and restarted and made sure both global and system changes too 
 effect. Also removed the sections completely from the pjsip.conf file and 
 made sure the defaults were shown.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] DNS work :: IDNA domäner ;-)

[Olle E. Johansson]

An additional decision to be made:

Do we need to support IDNA in asterisk or not?

If I want to set up a sip trunk do blåbärsmjölk.ästerisk.org - do I add that in 
the config file?

For those that create web interfaces to asterisk - should they do the 
conversion or will Asterisk?

There are now IDNA TLD's, so this is not a theoretical question, it will 
quickly become very real.

We can either say that we should have the punyencoded string in all 
configuration files and databases or
do the conversion in our code.

We also need to check this for TLS certificates - we need to use the 
punyencoded strings for cert verification
for servers.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4573: trunk: Can't touch this

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4573/#review15030
---


So typical US-centric. The rest of the world has moved to Unicode-art. ◼️⚫️◼️

 Please add this to the agenda of the Asterisk-internationalization meeting in 
Stockholm next month. We also need to discuss the babel-fish module.

- Olle E Johansson


On April 1, 2015, 9:59 p.m., Matt Jordan wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4573/
 ---
 
 (Updated April 1, 2015, 9:59 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This adds a much needed feature: glorious ASCII art of MC Hammer doing his 
 thing in full 1990's apparel.
 
 As a bonus, this will start a 'hammer time' on the channels in Asterisk.
 
 
 Diffs
 -
 
   /trunk/res/res_clihammertime.c PRE-CREATION 
 
 Diff: https://reviewboard.asterisk.org/r/4573/diff/
 
 
 Testing
 ---
 
 https://www.youtube.com/watch?v=otCpCn0l4Wo
 
 
 Thanks,
 
 Matt Jordan
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4441: Enable TLS Dual-Certificates (ECC+RSA)

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4441/#review14966
---


Thank you for working on the TLS code, we surely need more attention to that. I 
am not sure about adding DSA, but adding ECC is a good thing. I would suggest 
going for more config parameters instead of guessing file names. We are not 
doing that anywhere else (that I know of) and I don't think it's a good thing. 

- Olle E Johansson


On March 30, 2015, 10:34 a.m., Alexander Traud wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4441/
 ---
 
 (Updated March 30, 2015, 10:34 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24815
 https://issues.asterisk.org/jira/browse/ASTERISK-24815
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Already works for Asterisk as the client. Enables dual- (or triple-) 
 certificates for Asterisk as the TLS server. When a client connects via 
 SSL/TLS, the server uses a RSA key-pair usually. However, more such 
 algorithms exist like DSA and ECDSA. If you go for one of those, you would 
 loose compatibility to RSA-only clients. This patch allows you to provide 
 up-to one RSA, ECDSA and DSA key each (= one key or two keys or three keys). 
 Copied over from the Apache HTTP server project, added in version 2.4.8.
 
 Usage:
 tlscertfile=/etc/asterisk/example_rsa.pem
 Then, the code of this patch picks that path, filename, and searches for 
 files called example_ecc.pem and example_dsa.pem automatically.
 
 
 Diffs
 -
 
   trunk/main/tcptls.c 431938 
   trunk/configs/samples/sip.conf.sample 428526 
 
 Diff: https://reviewboard.asterisk.org/r/4441/diff/
 
 
 Testing
 ---
 
 by developer, manually
 
 This patch was tested in Ubuntu 14.04 LTS with a certificate from Comodo 
 (ECC; chains-up to AddTrust and UTN) and RapidSSL (RSA; chains-up to GeoTrust 
 and Equifax). TLS clients were CounterPath Bria (BlackBerry) and CSipSimple 
 (Android). The test was done with OpenSSL 1.0.1 and OpenSSL 1.0.2. Both 
 versions work as expected. However, if you use well-known (commercial) 
 certificates, you might use different certificate chains. For this, you need 
 at least OpenSSL 1.0.2. If you use your own certificate authority without a 
 certificate chain, OpenSSL 1.0.1 is sufficient.
 
 Because no new symbol of OpenSSL was used, I do not see a reason why this 
 patch should not be compatible with older OpenSSL releases. Therefore, no 
 if/def/version is introduced in this patch.
 
 
 Thanks,
 
 Alexander Traud
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] RFC: Refactor qualify and res_pjsip/endpt_send_request

[Olle E. Johansson]

On 30 Mar 2015, at 16:54, Mark Michelson mmichel...@digium.com wrote:

 On 03/28/2015 08:06 PM, Joshua Colp wrote:
 George Joseph wrote:
 The fact that it goes to unavailable would be a bug. Why does it do so?
 
 Mark should probably chime in here but I think it's because the
 earliest you could get a response from pjsip when a contact isn't
 reachable is the unconfigurable 32 seconds.   As I said that's a long
 time to leave a contact available when it really isn't. Without
 implementing our own timer setting the contact to unavailable was
 probably the lesser of 2 evils.
 
 No matter what there's going to be a period where you are potentially wrong. 
 I don't think making it unavailable was done on purpose.
 
 Actually, I believe the timer may be configurable. In the type=system 
 settings, there are timer_t1 and timer_b settings. timer_t1 is the base used 
 for determining the retransmission interval, and timer_b is the maximum time 
 we will wait before giving up sending the request. The defaults for these 
 values are 500 ms and 32000 ms respectively. If you were to change timer_b to 
 be a smaller value, then presumably you would have a shorter time before the 
 transaction times out.
 
 A couple of caveats about these settings
 1) Since they're in the type=system settings, any change you make requires 
 an Asterisk restart in order to take effect.
Are you serious? That's a very strange design. Without knowing anything about 
PJSIP, I think that is something that
needs to be fixed. There are several SIP phones based on PJSIP where I can set 
timers without restarting. Wonder
how they did it. 

 2) PJSIP applies these timers globally. They will affect ALL SIP 
 transactions, not just the OPTIONS transactions from the qualify checks.
That seems very strange, but I have to trust you here. It makes the channel 
driver rather unusable in gateway situations where
it's a requirement that I have one set of timers for my internal systems and 
one for external clients.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4532: PJSIP: Create transactions for out-of-dialog responses

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4532/#review14888
---


Just adding a note to the comment.


/branches/13/include/asterisk/res_pjsip.h
https://reviewboard.asterisk.org/r/4532/#comment25514

...and send the SAME answer to every retransmission...



/branches/13/res/res_pjsip.c
https://reviewboard.asterisk.org/r/4532/#comment25515




- Olle E Johansson


On March 26, 2015, 11:54 p.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4532/
 ---
 
 (Updated March 26, 2015, 11:54 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24920
 https://issues.asterisk.org/jira/browse/ASTERISK-24920
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 A problem was found where a device was sending a MESSAGE request to a heavily 
 loaded Asterisk system. Since Asterisk wasn't able to respond to the message 
 within 500 ms, the device retransmitted the MESSAGE. Asterisk got around to 
 handling the first MESSAGE, sent a 202 response and then sent the incoming 
 MESSAGE into the dialplan to be handled. Asterisk then took the 
 retransmission, sent a 202 response to it, and sent it into the dialplan to 
 be handled as well.
 
 This patch aims to fix the problem where retransmissions are being treated as 
 new requests. This adds an API call to respond to an out of dialog request by 
 creating a transaction and sending the response on that transaction. This 
 way, when a retransmission arrives, the PJSIP transaction layer matches it to 
 the transaction we created, re-sends the response, and Asterisk does not ever 
 see the retransmission.
 
 
 Diffs
 -
 
   /branches/13/res/res_pjsip_registrar.c 433494 
   /branches/13/res/res_pjsip_messaging.c 433494 
   /branches/13/res/res_pjsip/pjsip_options.c 433494 
   /branches/13/res/res_pjsip.c 433494 
   /branches/13/main/threadpool.c 433494 
   /branches/13/include/asterisk/res_pjsip.h 433494 
 
 Diff: https://reviewboard.asterisk.org/r/4532/diff/
 
 
 Testing
 ---
 
 The test scenario where Asterisk was mishandling the retransmitted MESSAGE 
 request has been confirmed to work correctly now. I also have started 
 Asterisk and ensured that Asterisk has no errors responding to incoming 
 REGISTER or OPTIONS requests, which are altered by this patch.
 
 There is a testsuite review up at https://gerrit.asterisk.org/#/c/14/
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Asterisk 11 - where's the code documentation?

[Olle E. Johansson]

Friends,
Going through some Asterisk 11 code for my RTCPFB work. There are a lot of new 
code in the RTP module - almost zero comments. Those that are there
are generally not doxygen formatted.

Can we please try to add more comments as you add new code? Please. Names 
doesn't explain your logic and you will soon grow old and will not
remember how stuff worked or why you added that super function?

Thanks,
/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Apologies for messy commit of the uacreg counters

[Olle E. Johansson]

Apologies for the messy merge of my branch. One learns all the time.

I tried merging the branch locally instead of using the pull request web 
interface. One has to be careful with every commit - even to a local branch - 
or just copy files between the branches and commit without a proper merge...

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Olle E. Johansson]

 
 So far most of authorization between Kamailio and Asterisk relies on IP
 addresses, but those need to be provisioned one by one in both sides. The
 new module is practically adding a custom header with a hash over parts of
 the message or other environment attributes (eg., IP address) and a shared
 secret. The www-digest with username and password has the overhead of an
 extra round of signaling messages, but also the constraint on CSeq increment
 after the challenge. Also, the MD5 is rather week hashing these days.
 

Why can't this be done in the dialplan?. This is exactly why I implemented the 
MD5
dialplan stuff in Asterisk years ago. We need something else than MD5 today,
but still - both Asterisk and Kamailio can handle it without modules or extra 
coding...

The IETF is working on OAUTH authentication for SIP - which is the solution
we really want to look into - not copy weak auth from the API world... :-)

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ARI - Add Support for custom SIP Headers with Originate

[Olle E. Johansson]

On 09 Mar 2015, at 08:54, Nir Simionovich nir.simionov...@gmail.com wrote:

 Cool, too bad it isn't documented. I'll add it into PHPARI as well.
 


I believe that this was one of the reasons we created the support for _VARIABLE 
and __VARIABLE
in Asterisk. The ability to reach over to the new channel from the old channel 
was required
for a number of things we wanted to do.

The code is very old and at the time it was seem as a bad hack to use the 
channel
variables for this.  The decision was not to expose this part while trying to 
figure out a better
way to do it. It's still around, about ten years later. :-)

I have mentioned this a number of times on various mailing lists, so it should 
be known,
even though it is not documented.

Make sure that if you add variables not using the dialplan function,  you must 
use high numbers and 
decrement so the risk of a collision is lower.

/O


 On Mar 8, 2015 6:18 PM, Matthew Jordan mjor...@digium.com wrote:
 
 On Sun, Mar 8, 2015 at 10:51 AM, Nir Simionovich nir.simionov...@gmail.com 
 wrote:
 Ok, I'll have a look into that one.
 
 On Sun, Mar 8, 2015 at 1:03 PM, Olle E. Johansson o...@edvina.net wrote:
 
 On 08 Mar 2015, at 09:52, Nir Simionovich nir.simionov...@gmail.com wrote:
 
  Hi All,
 
So, I've been banging my head against an issue with ARI. While Channel 
  Originate enables
  you to originate channels, you can't really do a SIPAddHeader type 
  functionality in there.
 
Originally, I was under impression that endpoints/message should be able 
  to give me the functionality I wanted, but it didn't.
 
So, I realized that the functionality I'm looking for doesn't really 
  exist.
 
Question, are we missing a feature here? or is there an alternative 
  method of achieving the
  same functionality?
 If you can add channel variables, you can add SIP headers.
 Look at a dump of the channel after you executed SIPaddheader to figure out 
 how it works.
 Add two headers, and run dumpchan().
 
 You should be able to do it with just the channel variable SIPADDHEADER, 
 that is:
 
 SIPADDHEADER=X-CustomHeader-1: foo
 SIPADDHEADER=X-CustomHeader-2: bar
 
 These can be specified in the /channels operation's JSON body.
 
 WIth chan_pjsip, headers are manipulated using a dialplan function, so there 
 shouldn't be any issue there.
 
 -- 
 Matthew Jordan
 Digium, Inc. | Director of Technology
 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
 Check us out at: http://digium.com  http://asterisk.org
 
 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
 -- 
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ARI - Add Support for custom SIP Headers with Originate

[Olle E. Johansson]

On 08 Mar 2015, at 17:17, Matthew Jordan mjor...@digium.com wrote:

 You should be able to do it with just the channel variable SIPADDHEADER, 
 that is:
 
 SIPADDHEADER=X-CustomHeader-1: foo
 SIPADDHEADER=X-CustomHeader-2: bar
 
 
I think there's a serial number in the name of the variable.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ARI - Add Support for custom SIP Headers with Originate

[Olle E. Johansson]

On 08 Mar 2015, at 09:52, Nir Simionovich nir.simionov...@gmail.com wrote:

 Hi All, 
 
   So, I've been banging my head against an issue with ARI. While Channel 
 Originate enables
 you to originate channels, you can't really do a SIPAddHeader type 
 functionality in there.
 
   Originally, I was under impression that endpoints/message should be able to 
 give me the functionality I wanted, but it didn't.
 
   So, I realized that the functionality I'm looking for doesn't really exist. 
 
   Question, are we missing a feature here? or is there an alternative method 
 of achieving the 
 same functionality?
If you can add channel variables, you can add SIP headers.
Look at a dump of the channel after you executed SIPaddheader to figure out how 
it works.
Add two headers, and run dumpchan().

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4437: dns: Define a core DNS API with examples.

[Olle E. Johansson]

On 03 Mar 2015, at 22:30, Joshua Colp jc...@digium.com wrote:

 Olle E. Johansson wrote:
 
 On 03 Mar 2015, at 21:10, Mark Michelson reviewbo...@asterisk.org
 mailto:reviewbo...@asterisk.org wrote:
 
 for (i = 0; i  ast_query_set_num_queries(query_set); ++i) {
 struct ast_dns_query *query = ast_dns_query_set_get(query_set, i);
 ...do stuff...
 }
 
 Why not use DNS terminology?
 
 Can you elaborate on what you mean? Are you referring to query set as a 
 concept (I'm unaware if there's a specific term for a group of queries in 
 DNS) or to other stuff in the DNS API itself?
 
queries are what you send. This seems to handle a result set.

I may have misunderstood.

You have queries and result sets that contain records.

In some cases you use that to create a SRV list of servers - handling the 
weights for load balancing and priorities. This is a sorted list that is not 
the same as the result set of an SRV query. One SRV record can lead to multiple 
IP addresses of different families - so you have four entries in your list for 
one single hostname.

I would recommend trying to align the names with the DNS terminology so we 
don't invent new stuff or misunderstandings. 

Like in the usage of AOR in the PJSIP config file... But I don't want to open 
that discussion again. ;-)

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4437: dns: Define a core DNS API with examples.

[Olle E. Johansson]

On 03 Mar 2015, at 21:10, Mark Michelson reviewbo...@asterisk.org wrote:

 for (i = 0; i  ast_query_set_num_queries(query_set); ++i) {
 struct ast_dns_query *query = ast_dns_query_set_get(query_set, i);
 ...do stuff...
 }
 
Why not use DNS terminology?

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements

[Olle E. Johansson]

On 02 Mar 2015, at 16:54, Matt Jordan reviewbo...@asterisk.org wrote:

 {quote}
 Buffering/reordering
 
 RTP may be received in bursts, out of order, or in other less-than-ideal 
 ways. Asterisk will implement reception buffers to place incoming RTP traffic 
 into, potentially reordering packets as necessary if they arrive out of order.
 {quote}
 
By default, asterisk should forward RTP packets without any buffer, without 
reordering or doing anything. Today Asterisk renumbers packets - thus hiding 
packet loss and reordering. This is bad.

Forwarding with packet loss and reordering is quite ok as default. The endpoint 
in the call will sort it up with a jitter buffer.

In some cases Asterisk is the endpoint of the RTP stream (IVR, protocol 
conversion). In that case we can apply a buffer like any endpoint. But not by 
default.

I guess cases with transcoding involved also requires a jitter buffer.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements -session

[Olle E. Johansson]

Mark,
One thing I think we have to look into is grouping of media sessions. You do 
not mention that, but you point to the bundle RFC. There are a few cases, like 
video conferences with left/right video and different options for audio - from 
high bandwidth to low bandwidth, lossy compression. Alternatives in the group 
and stuff that belongs together.

Sorry for making your hair turn grey, but I think it's time. And this will of 
course go beyond RTP.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Olle E. Johansson]

On 23 Feb 2015, at 16:19, Matthew Jordan mjor...@digium.com wrote:

 
 
 On Wed, Feb 11, 2015 at 11:12 AM, Olle E. Johansson o...@edvina.net wrote:
 
 On 11 Feb 2015, at 17:50, Matthew Jordan mjor...@digium.com wrote:
 
 
 
 On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla mico...@gmail.com 
 wrote:
 
 
 I was thinking some more about this, and I realized that I'm not really sure 
 how I would pick a specific Asterisk server in a pool of servers.
 
 This is probably going to demonstrate some of my ignorance when it comes to 
 Kamailio, but I'm going to go ahead anyway :-)
 
 Say, for example, we have n Asterisk servers, all of which can serve any 
 need that an inbound SIP request requires. They are generic media 
 application servers, and Kamailio just needs to pick one and send the 
 request to it, most likely indicating the purpose in a SIP header. Then, we 
 may receive a request from Alice to go into a conference room:
 
 INVITE sip:confere...@my-service-provider.com SIP/2.0
 From: Alice al...@super-awesome-company.com
 ...
 
 And we want to proxy that request to one of our media application servers, 
 turning it into something like this:
 
 INVITE sip:confere...@asterisk-node-five.mydomain.com SIP/2.0
 From: Alice al...@super-awesome-company.com
 To: ...
 X-Exec-App: Conference
 X-Exec-App-Data: 1000
 No need to retarget unless your asterisk is really requiring that domain.
 
 True. The same questions exist even if we are sending the INVITE request to 
 sip:confere...@asterisk-node-five.myservice-provider.com however.
  
 
 
 Any Asterisk server can then receive the request, extract the application to 
 execute, and start the correct application, letting an ARI application do 
 the heavy lifting of actually implementing the requested application.
 
 exten = s,1,NoOp()
  same = n,Set(app=${PJSIP_HEADER(read,X-Exec-App)})
  same = n,Set(args=${PJSIP_HEADER(read,X-Exec-App-Data)})
  same = n,Stasis(${app}, ${args})
  same = n,Hangup()
 
 All of that is fine and good - but how did Kamailio choose 
 asterisk-node-five as the Asterisk server to send the request to?
 There are many ways, our dispatcher module has as many ways to dispatch 
 traffic as Asterisk has
 queue algorithms.
 
 
 I think that's a very apt comparison :-)
 
 The Queue application's ring strategies can be problematic. In relatively 
 simple scenarios they apply fairly well; with sufficient complexity, you 
 either have to use other mechanics to achieve the functionality you want 
 (say, for example, Local channel members) or you find that your ring strategy 
 simply isn't achievable. Sometimes, Asterisk _can_ provide you the levers to 
 toggle the behaviour you want; however, in many complex scenarios, it can't 
 give you all the functionality you desire. Ideally, you want the developer 
 building a system on top of Asterisk to control the business application 
 logic - hence, the advent of ARI. In fact, the Queue application's ring 
 strategy limitations were a major contributing factor in the development of 
 ARI.
 
 The same could be said here. Sure, I can use one of the many levers that 
 exist in the dispatcher module, and there's a reasonable chance that it will 
 accommodate the complexity of a particular scenario. Playing around with it 
 over the past few days, ds_select_dst is clearly very powerful. On the other 
 hand, I'm still limited to the algorithms implemented in Kamailio. While I 
 could write my own algorithm in C and contribute it upstream, not everyone is 
 a C programmer!
 
Which is why we have python, lua, java, perl support...

 It may be given the tight timing constraints that Kamailio exists under 
 (which is somewhat tighter than Asterisk determining who to ring in a Call 
 Queue) that hardcoding the algorithms in Kamailio is the best way to do it - 
 but I'm curious if there are ways outside of that.
Of course there are.

  
 What's more, if those servers are truly dynamic, where we are using 
 something like OpenStack to spin up and spin down Asterisk servers on an 
 as-needed basis, than the mere act of knowing the pool of available Asterisk 
 server is going to be tricky. Granted, the Asterisk servers could register 
 themselves to Kamailio, so it will know at any one time who all is available 
 for a resource, but it feels like the Kamailio routing could get tricky, 
 with a lot of business logic sprinkled into it.
 We could add the new DMQ message buss to Asterisk which would make Kamailio 
 aware of it.
 There are many ways. Kamailio monitors the cluster with OPTIONs so if you 
 spin up one that was 
 down, it won't take long before we send traffic.
 
 
 Or we could have Kamailio integrate with Asterisk using Corosync :-)
 
 The DMQ message bus module looks to be rather generic. Is there any 
 documentation on the actual messages published over the message bus?
DMQ sip messages :-)

 
  
 
 Expanding on the snippet above, if I send another request from Bob 
 b...@super-awesome-company.com

Re: [asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Olle E. Johansson]

On 23 Feb 2015, at 16:27, Matthew Jordan mjor...@digium.com wrote:

 
 
 On Fri, Feb 13, 2015 at 5:42 AM, Ben Langfeld b...@langfeld.me wrote:
 On 11 February 2015 at 15:12, Olle E. Johansson o...@edvina.net wrote:
 
 On 11 Feb 2015, at 17:50, Matthew Jordan mjor...@digium.com wrote:
 
 
 
 On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla mico...@gmail.com 
 wrote:
 Thanks Matt for all the valuable details -- even quite some time since your 
 answer, I still have to digest parts of it, given that I had some tough cold 
 to deal with and then a bit of traveling. But that gave time to think more 
 about and I have an idea that I will present in a near future to make the 
 trust relationship between Kamailio and Asterisk instance a bit more dynamic.
 
 For now, I want to comment on your suggestion, pasted next:
 
 
 From Kamailio's perspective, you could:
 
 * Receive an inbound request
 * Pick some Asterisk resource in your pool of available servers
 * (Assuming this is done using a REST API) PUT the configuration of the 
 endpoint on the specific destination server
 * Route the call to that server
 * Later, DELETE the configuration off the server
 
 
 I would prefer to avoid any extra network communication between Kamailio and 
 Asterisk, we have to send a sip package anyhow. It can add delays and also 
 complexity in dealing with transmission errors of the PUT operation.
 
 Given you suggestion, maybe we can loop that internally in Asterisk somehow. 
 Have kind of SIP message pre-processing callback where to do the PUT 
 operation for configuration of the endpoint, then do the normal diaplan 
 routing. I am quite sure should be possible somehow with the new ARI, I just 
 need time to dig into it.
 
 I was thinking some more about this, and I realized that I'm not really sure 
 how I would pick a specific Asterisk server in a pool of servers.
 
 This is probably going to demonstrate some of my ignorance when it comes to 
 Kamailio, but I'm going to go ahead anyway :-)
 
 Say, for example, we have n Asterisk servers, all of which can serve any 
 need that an inbound SIP request requires. They are generic media 
 application servers, and Kamailio just needs to pick one and send the 
 request to it, most likely indicating the purpose in a SIP header. Then, we 
 may receive a request from Alice to go into a conference room:
 
 INVITE sip:confere...@my-service-provider.com SIP/2.0
 From: Alice al...@super-awesome-company.com
 ...
 
 And we want to proxy that request to one of our media application servers, 
 turning it into something like this:
 
 INVITE sip:confere...@asterisk-node-five.mydomain.com SIP/2.0
 From: Alice al...@super-awesome-company.com
 To: ...
 X-Exec-App: Conference
 X-Exec-App-Data: 1000
 
 Why do you have Kamailio determining the app and its arguments?
 
 You don't; it is slightly a bad example.
 
 What I'm trying to reason out is: given a set of routing constraints - which 
 includes not only load balancing but also application level routing 
 decisions - what's the appropriate place for that information to live? 
 Particularly when you want your entire system - not just Asterisk - to be 
 scalable?
 
 
 Is it not the case that DNS is intended to specifically solve the problem of 
 discovering the location of a service, and that we should lean on SRV records 
 for this info?
 
 You could use Consul (https://www.consul.io/) to expose the set of available 
 Asterisk nodes for a particular service via DNS and leave it out of Kamailio 
 entirely. I should write a blog post covering this at some point.
 
 Consul looks interesting. I hadn't heard of that before. Parts of it look 
 similar to Corosync.
 
 DNS lookups certainly could cover the case of discovery, depending on how the 
 lookup is performed.
 
It's a fine tradition to overcomplicate matters. Use SIP for discovery, make it 
simple, keep it simple.

If we make Asterisk registrations more flexible, asterisk could register as 
part of a service group and unregister
when it for some reason wants to leave the group.

/O :-)

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Olle E. Johansson]

On 23 Feb 2015, at 20:10, Matthew Jordan mjor...@digium.com wrote:

 
 
 On Mon, Feb 23, 2015 at 11:16 AM, James Cloos cl...@jhcloos.com wrote:
  MJ == Matthew Jordan mjor...@digium.com writes:
 
 MJ What I'm trying to reason out is: given a set of routing constraints -
 MJ which includes not only load balancing but also application level 
 routing
 MJ decisions - what's the appropriate place for that information to live?
 MJ Particularly when you want your entire system - not just Asterisk - to be
 MJ scalable?
 
 You need to use something to keep track of whether each box is reachable
 and what each is doing.  There a lots of ways of doing that, including
 custom network applications, shared networkable databases, shared nfs,
 et alia.
 
 Then each node needs a bit of logic to use that data to determine what
 to do with any given event.
 
 As one example, if a sip server gets an invite which directs on to an
 existing conference, it needs to know which asterisk is handling that
 conference, so that it can send the invite there.
 
 A shared database is required, but whether it is a custom application, a
 networkable db or a local db stored on a networked file systems is
 something anyone writing the code needs to choose.
 
 Completely agree.
 
 What I'm driving towards - albeit in something of a roundabout fashion - are 
 two notions:
 (1) Hard coding logic in application configuration does not lend itself well 
 to scalability. Kamailio lessens the pain in certain ways - you're typically 
 going to have fewer proxies than application servers (although, I suppose 
 that depends on what you are doing). Also, as Olle pointed out, you can 
 replicate information out using an htable. Or use a database. To some extent 
 though, this is not much different than using func_odbc with Asterisk (a 
 concept many people miss often.) At the same time, requiring direct access to 
 a database from my routing engine/media application server does not lend 
 itself well to expressive logic. While I've managed to push the data out of 
 the application, I haven't necessarily done the same with the business rules.
 
 If you approach the problem purely from a how horizontally scalable can I 
 make this, then ideally most of your business logic would lie outside of the 
 routing engine (Kamailio) or the media application server (Asterisk). That 
 may mean a web microservice architecture that exposes REST APIs for the 
 real-time component to consume. That may mean something else. As Daniel 
 noted, the more REST APIs you hit using a cURL module (or what have you), the 
 slower things get in Kamailio. The same is true for Asterisk. What I'm trying 
 to fish for is where that dividing line should occur - that is, what properly 
 belongs to Kamailio (routing decisions) and what properly belongs to 
 something else.
 
 (2) Domain specific languages require domain specific knowledge. This is not 
 necessarily a bad thing. At the same time, it's far easier to parallelize the 
 problem of application development if you can split tasks into well defined 
 domains that make use of tools that have a wider base of knowledge. If, for 
 example, the logic of who is in a conference on which server can be 
 answered by a REST API written in Python, or JavaScript, or something else - 
 and does not even live on the Kamailio server - then not only does the job of 
 the Kamailio integrator become easier, it is also becomes easier to find 
 multiple people to help write the services that it integrates with.

Kamailio really doesn't need to know as long as Asterisk knows... You are 
trying to solve something that is not really a problem, Matt. I have tried this 
path before with conferences and ended up with something too complex. Went back 
to
forking, if a server responded with 200 OK I added a temporary state in an 
autoexpire hashtable so I remembered for next call which did not need to fork. 
Simple. Fast. No distributed states.

The real key to scalability is keeping it simple and keeping states local. As 
soon as you start trying to synch or distribute states it gets very complex and 
you loose a lot of scalability. Asterisk is filled with all kinds of states, 
keep it there as much as possible and be smart with your signalling. You want 
to be able to restart Kamailio anytime without loosing states and without 
disrupting any single call. As soon as you start adding call states, server 
states and conference server states you loose a lot of that and end up with 
replication in databases and other complex schemes.

Forking doesn't cost much, really. Using SIP makes life simple. The network 
flow is already established.

If you are looking for restful interfaces, Kamailio has an embedded HTTP server 
you can use for quite a lot compared with the Asterisk one. The HTTP requests 
are as configurable and routable as the SIP requests... Quite cool.

There are a few applications that require more states, like trying to build a 
PBX in Kamailio. 

Re: [asterisk-dev] [Code Review] 4419: SDES-SRTP: Handle SRTP keys negotiated with key lifetime/MKI (oej branch lingon-srtp-key-lifetime-1.8) - Asterisk 11

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4419/#review14461
---


Thank you for doing this, Matt! This code has been heavily tested in my 1.8 
version. I will compare your code with mine before I press ship it if there's 
been any late changes, but I don't think so. 
A note: All the examples I have in my code could be added as a doxygen comment 
- I think they are useful for reference. This is not an easy topic and having 
examples in the source helps anyone wanting to modify bugs we miss in the 
future.

Hopefully I can backport part of your forward port to my branch :-)

- Olle E Johansson


On Feb. 14, 2015, 4:26 a.m., Matt Jordan wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4419/
 ---
 
 (Updated Feb. 14, 2015, 4:26 a.m.)
 
 
 Review request for Asterisk Developers and Olle E Johansson.
 
 
 Bugs: ASTERISK-17721, ASTERISK-17899 and ASTERISK-22748
 https://issues.asterisk.org/jira/browse/ASTERISK-17721
 https://issues.asterisk.org/jira/browse/ASTERISK-17899
 https://issues.asterisk.org/jira/browse/ASTERISK-22748
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Note that this patch is a forward port of oej's lingon-srtp-key-lifetime-1.8 
 branch, with a few small modifications to reduce block indentation and a few 
 improvements made to surrounding existing code.
 
 To quote Olle from ASTERISK-17721:
 
 {quote}
 The Lingon branch now handle lifetime and MKI parameters.
 
 We only accept lifetimes up to max for the crypto and higher than 10 hours 
 for packetization of 20 ms (50 pps).
 
 We only handle MKI with index 1.
 
 We do not really bother with counting packets and reinviting at end of 
 lifetime, so the min of 10 hours kind of takes care of most calls. If there 
 are longer ones, we rely on the other side for re-invites.
 
 It's still not perfect, but I personally think this is an improvement. A 
 configuration option for minimum lifetime accepted could be added.
 {quote}
 
 I personally don't think the minimum lifetime option is needed, as in 
 practice, every instance of an SDP offer for SDES-SRTP with lifetime I've 
 seen offers a lifetime of 2^32 - but it could be added in the future if 
 necessary.
 
 Note that since the sdp_crypto code was moved to the core in 12+, a separate 
 review (r4418) has been made for the Asterisk 13 variant. It is essentially 
 identical to this review.
 
 
 Diffs
 -
 
   /branches/11/channels/sip/sdp_crypto.c 431750 
 
 Diff: https://reviewboard.asterisk.org/r/4419/diff/
 
 
 Testing
 ---
 
 Tests were added for chan_sip and updated for chan_pjsip - see 
 https://reviewboard.asterisk.org/r/4420 . This includes both nominal and 
 off-nominal offers negotiating SDES-SRTP.
 
 
 Thanks,
 
 Matt Jordan
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Advanced feature query

[Olle E. Johansson]

On 12 Feb 2015, at 09:55, David Radcliffe david.radcli...@clockworkit.co.uk 
wrote:

 Hi,
  
 Does anyone know if Asterix has the ability to send a network message (TCP/IP 
 packet) indicating that a call is in progress through the PBX?
This is not really a question about asterisk development - so you are on the 
wrong mailing list. This mailing list is for developers of the asterisk source 
code.
  
 I need a message to say “pbx has at least one call in progress”,
 and another to say “pbx has no calls in progress” when it is idle.
Please check the asterisk management interface where you get events like this.

Regards
/Olle
  
 If it can do this, can someone please let me know how to configure Asterix to 
 do this.
  
 Thanks
  
 David W. Radcliffe
 Senior Developer
 image001.jpg
 Clockwork IT Ltd
 tel: 08448 040950
 mob: 07764 155251
 image002.jpg 
  WWW.SUPPORTDESKPRO.CO.UK
 image003.png  image004.pngimage005.jpg
 image006.gif
 Clockwork IT Ltd, Saturn Business Centre, 101 Lockhurst Lane, Coventry, CV6 
 5SF
 NOTICE-This message contains information intended only for the use of the 
 addressee named above. It may also be confidential and/or privileged. If you 
 are not the addressee, you should not disclose, copy, distribute, take any 
 action or rely on this E-mail and should notify us immediately by return 
 E-mail to i...@clockworkit.co.uk The views expressed in this communication 
 may not necessarily be the views held by Clockwork IT
  
 -- 
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] DNS Support in Asterisk

[Olle E. Johansson]

There is one version of c-ares in resiprocate as well.

C-ares has been in use for a long time and is in use every single day for you 
as part of 
most curl installs. I am not sure there is much to do there.

Libunbound adds a lot if that is what we want.

Why is a cache a good thing? You surely have a caching resolver running
on your system, right?

DNSsec is a huge deal - and the foundation for a lot of security things coming 
up.
Someone wrote an IETF draft about that and SIP.

https://tools.ietf.org/html/draft-johansson-sipcore-dane-sip-00

I got a patch sent to me that implements that in Asterisk with unbound,
but haven't gotten time to go through it and test it.

/O

On 12 Feb 2015, at 16:25, Brad Watkins marqui...@gmail.com wrote:

 Looking at this, I'm inclined to say that libunbound is the better of
 the two options in spite of it being somewhat more difficult to
 consume DNS records than it would be with c-ares.  In my estimation a
 (seemingly?) more-active community and the inclusion of a cache are
 more important.  DNSSEC isn't a huge deal, at least not for me at this
 time, but is a nice bonus as well.
 
 - Brad
 
 On Thu, Feb 12, 2015 at 10:01 AM, Joshua Colp jc...@digium.com wrote:
 Greetings all,
 
 I've extended the sections of my wiki page for c-ares[1] and libunbound[2]
 to include further information about documentation, general usage
 experience, and other aspects. Personally I lean towards libunbound because
 it was straight forward to experiment with, supports DNSSEC, and has a
 cache.
 
 Cheers,
 
 [1]
 https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-c-ares
 [2]
 https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-libunbound
 
 
 --
 Joshua Colp
 Digium, Inc. | Senior Software Developer
 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
 Check us out at: www.digium.com  www.asterisk.org
 
 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev
 
 -- 
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 
 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Olle E. Johansson]

On 11 Feb 2015, at 17:50, Matthew Jordan mjor...@digium.com wrote:

 
 
 On Tue, Feb 3, 2015 at 6:11 AM, Daniel-Constantin Mierla mico...@gmail.com 
 wrote:
 Thanks Matt for all the valuable details -- even quite some time since your 
 answer, I still have to digest parts of it, given that I had some tough cold 
 to deal with and then a bit of traveling. But that gave time to think more 
 about and I have an idea that I will present in a near future to make the 
 trust relationship between Kamailio and Asterisk instance a bit more dynamic.
 
 For now, I want to comment on your suggestion, pasted next:
 
 
 From Kamailio's perspective, you could:
 
 * Receive an inbound request
 * Pick some Asterisk resource in your pool of available servers
 * (Assuming this is done using a REST API) PUT the configuration of the 
 endpoint on the specific destination server
 * Route the call to that server
 * Later, DELETE the configuration off the server
 
 
 I would prefer to avoid any extra network communication between Kamailio and 
 Asterisk, we have to send a sip package anyhow. It can add delays and also 
 complexity in dealing with transmission errors of the PUT operation.
 
 Given you suggestion, maybe we can loop that internally in Asterisk somehow. 
 Have kind of SIP message pre-processing callback where to do the PUT 
 operation for configuration of the endpoint, then do the normal diaplan 
 routing. I am quite sure should be possible somehow with the new ARI, I just 
 need time to dig into it.
 
 I was thinking some more about this, and I realized that I'm not really sure 
 how I would pick a specific Asterisk server in a pool of servers.
 
 This is probably going to demonstrate some of my ignorance when it comes to 
 Kamailio, but I'm going to go ahead anyway :-)
 
 Say, for example, we have n Asterisk servers, all of which can serve any need 
 that an inbound SIP request requires. They are generic media application 
 servers, and Kamailio just needs to pick one and send the request to it, most 
 likely indicating the purpose in a SIP header. Then, we may receive a request 
 from Alice to go into a conference room:
 
 INVITE sip:confere...@my-service-provider.com SIP/2.0
 From: Alice al...@super-awesome-company.com
 ...
 
 And we want to proxy that request to one of our media application servers, 
 turning it into something like this:
 
 INVITE sip:confere...@asterisk-node-five.mydomain.com SIP/2.0
 From: Alice al...@super-awesome-company.com
 To: ...
 X-Exec-App: Conference
 X-Exec-App-Data: 1000
No need to retarget unless your asterisk is really requiring that domain.

 
 Any Asterisk server can then receive the request, extract the application to 
 execute, and start the correct application, letting an ARI application do the 
 heavy lifting of actually implementing the requested application.
 
 exten = s,1,NoOp()
  same = n,Set(app=${PJSIP_HEADER(read,X-Exec-App)})
  same = n,Set(args=${PJSIP_HEADER(read,X-Exec-App-Data)})
  same = n,Stasis(${app}, ${args})
  same = n,Hangup()
 
 All of that is fine and good - but how did Kamailio choose 
 asterisk-node-five as the Asterisk server to send the request to? 
There are many ways, our dispatcher module has as many ways to dispatch traffic 
as Asterisk has
queue algorithms.

 What's more, if those servers are truly dynamic, where we are using something 
 like OpenStack to spin up and spin down Asterisk servers on an as-needed 
 basis, than the mere act of knowing the pool of available Asterisk server is 
 going to be tricky. Granted, the Asterisk servers could register themselves 
 to Kamailio, so it will know at any one time who all is available for a 
 resource, but it feels like the Kamailio routing could get tricky, with a lot 
 of business logic sprinkled into it.
We could add the new DMQ message buss to Asterisk which would make Kamailio 
aware of it.
There are many ways. Kamailio monitors the cluster with OPTIONs so if you spin 
up one that was 
down, it won't take long before we send traffic.

 
 Expanding on the snippet above, if I send another request from Bob 
 b...@super-awesome-company.com, and Bob is attempting to get into the same 
 conference room by sending a request to confere...@my-service-provider.com, I 
 need to have the logic someplace that we would preferably send Bob to the 
 same Asterisk server. Granted, two Asterisk servers can form a single 
 conference room by connecting themselves together, but that's less efficient 
 than having both SIP requests land on the same Asterisk server.
That is one area that needs some logic. I have used a realtime database for 
this with kamailio asking
for routing. Or in another setup I just fork to all asterisk servers and the 
one that has the conference
answers. If no one answer, I retarget the request to another uri which means 
OPEN the damn conference
and target that to one specific server.

 
 There may be elegant ways to handle this in Kamailio already; I'm just not 
 sure what they would be 

Re: [asterisk-dev] OT: Opus Asterisk 13

[Olle E. Johansson]

On 26 Jan 2015, at 14:03, Sean Bright sean.bri...@gmail.com wrote:

 Hi,
 
 I've just finished updating codec_opus for Asterisk 13. Unfortunately it 
 still requires a small patch to the core of Asterisk, but the size of that 
 patch is getting smaller with each new major version of Asterisk.  You can 
 download the codec implementation and patch file here:
 
https://github.com/seanbright/asterisk-opus
 
 If you have any problems with it, please open an issue on Github, do not use 
 asterisk-dev@lists.digium.com.
 
Thank you Sean!

Does this patch use variable bitrates in Opus - adapting based on RTCP 
feedback? Or is it fixed?

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4345: Use SIPS Contact headers as prescribed by RFC 3261 (res_pjsip)

[Olle E. Johansson]

On 15 Jan 2015, at 21:07, Mark Michelson reviewbo...@asterisk.org wrote:

 it feels like a bug that I can send a request to a SIPS URI over UDP and that 
 Asterisk will accept the request.
+1

I can't remember any SIPS-using clients, can't say I've looked hard though. 
Anyone that can help testing Mark's patch?

/O :-)-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4328: res_pjsip: Document transport selection process

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4328/#review14193
---


Surely there must be some NAPTR support in there.

We do need to rethink this a bit to allow for opportunistic security, also 
review how we handle dual stack situations.

For OS, we do need to try TLS in parallell on all SIP uri's. 

For dual stack support, we need to open two TCP or TLS connections at the same 
time.

RFC 3263 actually allows for some local policy, especially in cases where NAPTR 
doesn't exist.

- Olle E Johansson


On Jan. 12, 2015, 2:33 p.m., Joshua Colp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4328/
 ---
 
 (Updated Jan. 12, 2015, 2:33 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 The transport selection process of PJSIP (and by extension some of our own 
 logic) can be a dark dark thing. To help illuminate what happens I have 
 created a wiki page[1] which goes through (based on the message type) the 
 process by which a transport is chosen and how it can potentially change.
 
 Stuff to look at:
 1. Is this detailed enough?
 2. Can you follow it? If not, how could it be made clearer?
 3. Are there additional common issues that should be covered?
 
 [1] https://wiki.asterisk.org/wiki/display/~jcolp/Transport+Selection
 
 
 Diffs
 -
 
 
 Diff: https://reviewboard.asterisk.org/r/4328/diff/
 
 
 Testing
 ---
 
 I opened the wiki page. It opened.
 
 
 Thanks,
 
 Joshua Colp
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4328: res_pjsip: Document transport selection process

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4328/#review14194
---


You write that SRV is done if the URI is not IP. Check that SRV is not done if 
there's any port in the URI. If there's a port in the URI, the hostname is to 
be used for A/ lookups. If there's no port, go for NAPTR, then SRV.

As a side note, SRV may change your port address.

- Olle E Johansson


On Jan. 12, 2015, 2:33 p.m., Joshua Colp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4328/
 ---
 
 (Updated Jan. 12, 2015, 2:33 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 The transport selection process of PJSIP (and by extension some of our own 
 logic) can be a dark dark thing. To help illuminate what happens I have 
 created a wiki page[1] which goes through (based on the message type) the 
 process by which a transport is chosen and how it can potentially change.
 
 Stuff to look at:
 1. Is this detailed enough?
 2. Can you follow it? If not, how could it be made clearer?
 3. Are there additional common issues that should be covered?
 
 [1] https://wiki.asterisk.org/wiki/display/~jcolp/Transport+Selection
 
 
 Diffs
 -
 
 
 Diff: https://reviewboard.asterisk.org/r/4328/diff/
 
 
 Testing
 ---
 
 I opened the wiki page. It opened.
 
 
 Thanks,
 
 Joshua Colp
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4328: res_pjsip: Document transport selection process

[Olle E Johansson]

 On Jan. 15, 2015, 9:43 a.m., Olle E Johansson wrote:
  You write that SRV is done if the URI is not IP. Check that SRV is not done 
  if there's any port in the URI. If there's a port in the URI, the hostname 
  is to be used for A/ lookups. If there's no port, go for NAPTR, then 
  SRV.
  
  As a side note, SRV may change your port address.
 
 Joshua Colp wrote:
 I've tweaked the page slightly to include this condition but have not 
 gone further. Specifically because this page is for how a local transport is 
 selected based on the existing code and not the process of target resolution 
 itself. I mentioned target resolution slightly because of the requirement of 
 a transport parameter. If DNS work occurs I fully expect another wiki page 
 to be created describing how it works within PJSIP right now, its 
 shortcomings, and ways to overcome them.

Ok, but what about NAPTR.


- Olle E


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4328/#review14194
---


On Jan. 12, 2015, 2:33 p.m., Joshua Colp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4328/
 ---
 
 (Updated Jan. 12, 2015, 2:33 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 The transport selection process of PJSIP (and by extension some of our own 
 logic) can be a dark dark thing. To help illuminate what happens I have 
 created a wiki page[1] which goes through (based on the message type) the 
 process by which a transport is chosen and how it can potentially change.
 
 Stuff to look at:
 1. Is this detailed enough?
 2. Can you follow it? If not, how could it be made clearer?
 3. Are there additional common issues that should be covered?
 
 [1] https://wiki.asterisk.org/wiki/display/~jcolp/Transport+Selection
 
 
 Diffs
 -
 
 
 Diff: https://reviewboard.asterisk.org/r/4328/diff/
 
 
 Testing
 ---
 
 I opened the wiki page. It opened.
 
 
 Thanks,
 
 Joshua Colp
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4318: res_pjsip_pubsub: Fix persistent subscriptions not surviving graceful shutdown

[Olle E. Johansson]

On 07 Jan 2015, at 16:24, George Joseph reviewbo...@asterisk.org wrote:

 This patch suppresses the sending of 'NOTIFY/terminated' on shutdown for 
 persistent connections.  To do this, I've had to add a new 
 AST_OPT_FLAG_SHUTTING DOWN to options so we know that a shut down is in 
 progress.
Just make sure that NOTIFY/terminated still works in the case of dialplan 
reload in situations where the HINT is removed from the dialplan.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4318: res_pjsip_pubsub: Fix persistent subscriptions not surviving graceful shutdown

[Olle E. Johansson]

On 07 Jan 2015, at 17:05, George Joseph reviewbo...@asterisk.org wrote:

 I'm open to other suggestions but you absolutely can't send a 
 NOTIFY/terminated to a subscriber and expect to pick up where you left off.  
 They'll respond with a 481.  Also, testing for restart vs shutdown isn't 
 viable as you may perform an asterisk shutdown to reboot or solve an issue.  
 I think it's up to the subscribers to handle the cases of a permanent 
 shutdown.  Presumably they're going to have to be reconfigured anyway to pick 
 up a new server.
DNS SRV to the rescue!

/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] git migration update

[Olle E. Johansson]

On 23 Dec 2014, at 21:53, Paul Belanger paul.belan...@polybeacon.com wrote:

 On Tue, Dec 23, 2014 at 7:20 AM, Leif Madsen lmad...@thinkingphones.com 
 wrote:
 On 22 December 2014 at 18:34, Russell Bryant russ...@russellbryant.net
 wrote:
 
 On Mon, Dec 22, 2014 at 3:08 PM, George Joseph
 george.jos...@fairview5.com wrote:
 
 On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau
 sgalarn...@digium.com wrote:
 
 2 - we have a few options as far as team branches go. We could configure
 user branches using refs/heads/team/${username}/* permissions in Gerrit to
 allow users to create branches. This would prohibit other users from 
 pushing
 to a user branch, but they would still be visible. This would most likely
 involve reproducing some sort of automerge/autorebase process. The other
 option is to use github as another remote for team branches, with a remote
 pointing to Gerrit for code reviews. Is there a preference between these 
 two
 approaches, or perhaps a better setup we could follow?
 
 
 I don't think there's any need for you to host users' repos any more.
 It may have made sense for SVN but I don't think it does for GIT.  Let 
 users
 make their own arrangements be it GitHub or in my case, my own GIT
 infrastructure.
 
 
 +1.  I don't think it makes sense with git.  github or whatever should
 work just fine for that purpose.
 
 
 
 Another +1 here. The beautiful thing about git is that you're not going to
 need to do that. Anyone can use whatever git method they want (local,
 github, stash, etc) and just rebase against the origin branch with a remote.
 If people want to work together, then there are various ways of doing that,
 one of which github makes incredibly straight forward.
 
 I agree with everything everybody has said about team branches.  They
 are no longer needed server side for collaboration.
 
You are missing one thing. When committing to the current team branches,
the code is contributed under the license agreement.

The code in my branches is available for Digium to use at any point in 
time. If I had to have it in my own GIT or github it would be very different.

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4286: rtp_engine: avoid payload types above 127

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4286/#review14021
---


You may want to consider fixing RFC 5761 restrictions while you are in there... 
This prepares for RTP/RTCP muxing in WebRTC

Given these constraints, it is RECOMMENDED to follow the guidelines
   in the RTP/AVP profile [7] for the choice of RTP payload type values,
   with the additional restriction that payload type values in the range
   64-95 MUST NOT be used.  Specifically, dynamic RTP payload types
   SHOULD be chosen in the range 96-127 where possible.  Values below 64
   MAY be used if that is insufficient, in which case it is RECOMMENDED
   that payload type numbers that are not statically assigned by [7] be
   used first.


- Olle E Johansson


On Dec. 19, 2014, 9:24 p.m., Scott Griepentrog wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4286/
 ---
 
 (Updated Dec. 19, 2014, 9:24 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24367
 https://issues.asterisk.org/jira/browse/ASTERISK-24367
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Valid payload type codes are between 0 and 127 to allow for being stored in 7 
 bits.  During call setup, pjsip validates the SDP and will assert if it 
 encounters an invalid payload type code (see pjmedia_sdp_validate() in 
 pjmedia/src/pjmedia/sdp.c).  This assert will be hit if a call is placed to a 
 pjsip endpoint with allow=all set.
 
 To avoid this, the previous use 128 for the slin192 format has been changed 
 to 95.
 
 
 Diffs
 -
 
   /trunk/main/rtp_engine.c 429845 
 
 Diff: https://reviewboard.asterisk.org/r/4286/diff/
 
 
 Testing
 ---
 
 Tested with pjsip calls to allow=all configured extensions.
 
 
 Thanks,
 
 Scott Griepentrog
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Adding the support for NACK in asterisk

[Olle E. Johansson]

On 18 Dec 2014, at 10:42, Nitesh Bansal nitesh.ban...@gmail.com wrote:

 Hello folks,
 
 I am contemplating adding the support for NACK in asterisk hoping for better 
 video quality with Asterisk WebRTC calls.
 Can somebody please give me an estimate of the challenges involved, how 
 complicated it is going to be?

Please tell me more. What is NACK?

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip vs ca path

[Olle E. Johansson]

On 01 Dec 2014, at 16:21, Mark Michelson mmichel...@digium.com wrote:

 On 11/25/2014 02:46 PM, James Cloos wrote:
 Now that 13 has hit sid, I've started converting to pjsip.
 
 Chan_sip supports one's preference of a ca path or ca file, but
 res_pjsip does not.  At least not on the 13 branch.
 
 Is that intentional, or an oversight?
 
 If not intentional, will a patch to fix be accepted for 13,
 only for trunk?
 
 -JimC
 
 For res_pjsip, we're using the mechanisms that PJSIP exposes in its TLS 
 transport. Since a CA path option is not exposed, the option to provide one 
 in pjsip.conf does not exist. If you want to provide a patch, that's totally 
 fine, but the patch would need to be made against PJProject instead of 
 Asterisk.
 
 Doing a quick search, it looks like the change to make would be in 
 pjlib/src/pj/ssl_sock_ossl.c. The pj_ssl_cert_t would need to be modified to 
 have a CA path. The functions used to get and set pj_ssl_cert_t would need to 
 be modified to take a CA path into account. And finally, the create_ssl() 
 function would need to pass the configured CA path into 
 SSL_CTX_load_verify_locations().

If you have no CA path - how does the CHAN_PJSIP verify TLS certificates?

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] The state of Asterisk (new topic)

[Olle E. Johansson]

On 28 Oct 2014, at 17:44, Russell Bryant russ...@russellbryant.net wrote:

 
 I said this in my talk last week and will reiterate it here.  I think the 
 Asterisk dev community has been doing an amazing job over the last few years. 
  Internal refactorings have been achieved that we used to dream of.  A new 
 SIP channel driver finally exists.  The new API work just totally rocks.  
 It's an absolutely critical piece of what is needed from Asterisk to fit in 
 to the way future telephony applications should be architected in my view. 
 
 Well done, dev community.  Keep kicking ass.
 
I do agree with Russell here. We're making enormous progress and see changes 
we've been discussing for years actually happening.
It's fantastic.

I wish to add a Thank You to Digium for financing most of this work. I do hope 
we can come up with a cooperative
way of producing code in the future to make it easier to work together and get 
new code in.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 2478: Support multiple Require: and Supported: headers in the same request

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2478/
---

(Updated Oct. 29, 2014, 8:39 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 426594


Bugs: ASTERISK-21721
https://issues.asterisk.org/jira/browse/ASTERISK-21721


Repository: Asterisk


Description
---

We have servers sending multiple Supported: and Require: options in separate 
headers in the same message. This patch fixes that support so that we parse 
more than the first header found.


Diffs
-

  /trunk/channels/sip/reqresp_parser.c 414046 
  /trunk/channels/chan_sip.c 414046 

Diff: https://reviewboard.asterisk.org/r/2478/diff/


Testing
---

Tested with the server that caused the issue. Problem solved and we did reach 
interoperability!


Thanks,

Olle E Johansson

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3437: chan_sip: Add support for a few more 4xx error responses

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3437/
---

(Updated Oct. 29, 2014, 8:57 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 426599


Repository: Asterisk


Description
---

Adding improved support for 400, 414 and 493 response codes.

I would like to add this as a bug fix to 1.8 and up.


Diffs
-

  /trunk/channels/chan_sip.c 414046 

Diff: https://reviewboard.asterisk.org/r/3437/diff/


Testing
---

A lot during interoperability tests.


Thanks,

Olle E Johansson

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [asterisk-users] AstriDevCon 2014: Agenda itemDeprecate AMI/AGI(Ben Klang)

[Olle E Johansson]

It is critical that a group of developers ask themself questions along 
these lines - what if???


- What if we removed AGi and AMI?
- What if we made a pluggable PBX?
- What if we restarted working on a SIP channel?
- What if we made a whole new bridge architecture?
- What if we skip the idea of making a PBX?

Good development quite frequently starts with these kind of ideas and 
questions that may see crazy but results in really good changes.


Brainstorms needs to be open and not restricted, that is what the 
astridevcons are for. We need to go wild and see what comes out of it.


A lot of the great changes we see in Asterisk 13 comes from many years 
of wild discussions. Pinemango anyone?


/O

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] open appliance platform

[Olle E Johansson]

Glenn,
You are misusing this list - this is not for commercial information, 
it's for discussions about asterisk development. By doing this you

are hurting your company as well as your own reputation.

IN the future, please be a bit more careful before sending out to 
mailing lists

and posting in open forums. Check the rules, verify what's allowed,
especially when doing sales.

For this kind of information, we have the asterisk-biz mailing list,
where you are more than welcome to post.

Thank you,
/Olle

Glen Flowers skrev 2014-10-21 17:36:
--deleted--

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [svn-commits] gtjoseph: branch 12 r425964 - /branches/12/

[Olle E. Johansson]

On 19 Oct 2014, at 19:04, SVN commits to the Digium repositories 
svn-comm...@lists.digium.com wrote:

 If compiling for ARM (native or cross-compile) be sure to run ./bootstrap.sh
 and ./configure to regenerate the build files.  You shouldn't have to do this
 for Intel or SPARC.

Good information. Should not be buried in SVN commit messages - but should go 
into one of the text files in the root
directory, like README!

THank you

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4050: Add ability for Channel Drivers to provide Presence State information

[Olle E. Johansson]

On 14 Oct 2014, at 15:51, Matt Jordan reviewbo...@asterisk.org wrote:

 exten = hint,SIP/aliceCustomPresence:alice
 
 Will *always* use the presence provided by SIP/alice, instead of the custom 
 presence provider. That feels like a loss of functionality.
 
 Prior to this patch, we would only use the presence information provided by a 
 single custom presence provider, since presence information could only come 
 from custom presence providers. If the channel drivers provide that as well, 
 there probably needs to be some mechanism to aggregate that together.
 
THis looks insane to me, but I must surely have missed something. Have we 
discussed the definition of presence ?
In the old days we had extension states and device states - for me that's not 
presence, but can be input to personal presence.
What is this stuff?

Curious. But maybe too late to jump into the discussion :-)

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 2783: Fix SIP/TLS reading - random connection drop

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2783/#review13494
---


What's the status of this patch? Should it be closed?

- Olle E Johansson


On Aug. 21, 2013, 10:24 p.m., Tzafrir Cohen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/2783/
 ---
 
 (Updated Aug. 21, 2013, 10:24 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-18345
 https://issues.asterisk.org/jira/browse/ASTERISK-18345
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Symptom: Asterisk drops a SIP/TLS connection: debugging reports that it has 
 failed to read it.
 
 I can reproduce this on my system when the TLS client is Asterisk 11.5 
 (installed from the Debian package) set with 'allow=all' to get a long list 
 of codecs.
 
 Calling ast_wait_for_input before every fgets is not sufficient.
 Function fgets internally calls read (= SSL_read) until either \n or
 eof is found. And because the socket is polled only before the first
 SSL_read call, consequent calls can fail and return =0 even though the
 data are on the way.
 
 This is fixed by adding a read() loop inside the ssl_read() hook.
 
 I came accross this patch today and it looks like it fixes my problem (see my 
 comment at the end). The patch I used is by Filip Jenicek. See the bug report 
 for the full log.
 
 
 Diffs
 -
 
   /trunk/main/tcptls.c 397346 
 
 Diff: https://reviewboard.asterisk.org/r/2783/diff/
 
 
 Testing
 ---
 
 Work on trunk.
 
 
 Thanks,
 
 Tzafrir Cohen
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] License issue

[Olle E. Johansson]

Hi!

A customer showed interest in supporting the SIP GIN standard - registering for 
multiple contacts according to RFC 6140, part of the SIPconnect work.

I remembered an old patch on reviewboard that has an issue in the bug tracker - 
#18705

The patch was never uploaded to the bug tracker, only to reviewboard. 
https://reviewboard.asterisk.org/r/1515

Does that mean that the code is licensed to Digium or not? It's clearly 
licensed under GPL 2, but if I take on this work I need to know whether to 
start from scratch or if I can use this code and still submit it at some 
point...

Trying to get hold of the original author, but no reply so far.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] License issue

[Olle E. Johansson]

On 13 Oct 2014, at 15:46, Russell Bryant russ...@russellbryant.net wrote:

 On Mon, Oct 13, 2014 at 9:28 AM, Olle E. Johansson o...@edvina.net wrote:
 Hi!
 
 A customer showed interest in supporting the SIP GIN standard - registering 
 for multiple contacts according to RFC 6140, part of the SIPconnect work.
 
 I remembered an old patch on reviewboard that has an issue in the bug tracker 
 - #18705
 
 The patch was never uploaded to the bug tracker, only to reviewboard.
 https://reviewboard.asterisk.org/r/1515
 
 Does that mean that the code is licensed to Digium or not? It's clearly 
 licensed under GPL 2, but if I take on this work I need to know whether to 
 start from scratch or if I can use this code and still submit it at some 
 point...
 
 Trying to get hold of the original author, but no reply so far.
 
 It should be fine.  Users have never been able to use reviewboard without an 
 active contributor license agreement.  (AFAIK)

Ok. Thank you for the response, Russell!

/O

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4073: res_pjsip: Add 'user_eq_phone' option for placing 'user=phone' parameter in request URI if user is number.

[Olle E Johansson]

 On Oct. 13, 2014, 7:33 p.m., Matt Jordan wrote:
  /trunk/res/res_pjsip/pjsip_configuration.c, line 1735
  https://reviewboard.asterisk.org/r/4073/diff/1/?file=68003#file68003line1735
 
  Alembic!
  
  Thinking about it, we also need to update Alembic with your optimistic 
  encryption patch.
  
  Also: UPGRADE notes.
 
 Joshua Colp wrote:
 Wouldn't this belong in CHANGES? This isn't something that must be done 
 when upgrading.

user=phone applies to the caller ID as well, the URI in the From: header. I 
made a patch for chan_sip to fix that not a long time ago. Maybe simple to fix 
if it's not already supported.


- Olle E


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4073/#review13498
---


On Oct. 13, 2014, 6:54 p.m., Joshua Colp wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4073/
 ---
 
 (Updated Oct. 13, 2014, 6:54 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This change adds a 'user_eq_phone' option to endpoints which, if set, will 
 add a 'user=phone' parameter to the request URI if the user is determined to 
 be a number.
 
 
 Diffs
 -
 
   /trunk/res/res_pjsip/pjsip_configuration.c 425395 
   /trunk/res/res_pjsip.c 425395 
   /trunk/include/asterisk/res_pjsip.h 425395 
 
 Diff: https://reviewboard.asterisk.org/r/4073/diff/
 
 
 Testing
 ---
 
 Sent outgoing calls with various users (numbers, number+letters, letters) and 
 confirmed that user=phone was set when it should be.
 
 
 Thanks,
 
 Joshua Colp
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [svn-commits] mjordan: branch 12 r424624 - /branches/12/res/res_pjsip/pjsip_options.c

[Olle E. Johansson]

On 06 Oct 2014, at 02:59, SVN commits to the Digium repositories 
svn-comm...@lists.digium.com wrote:

 
 An OPTIONS request that is sent to Asterisk but not to a specific endpoint is
 currently sent a 404 in response. This is because, not surprisingly, an empty
 extension is never going to be found in the dialplan.
 
 This patch makes it so that we only attempt to look up the endpoint in the
 dialplan if it is specified in the OPTIONS request URI.

An empty extension in Asteirsk is the s extension, right?
In chan_sip we answer with 200 OK if an s extension can be found, otherwise 
an error is generated.

If that's a good or bad solution is a differernt thing - but we do handle empty 
extensions,
especially in the dahdi channel.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [svn-commits] mjordan: branch 12 r424624 - /branches/12/res/res_pjsip/pjsip_options.c

[Olle E. Johansson]

On 06 Oct 2014, at 16:21, Matthew Jordan mjor...@digium.com wrote:

 On Mon, Oct 6, 2014 at 1:25 AM, Olle E. Johansson o...@edvina.net wrote:
 
 On 06 Oct 2014, at 02:59, SVN commits to the Digium repositories 
 svn-comm...@lists.digium.com wrote:
 
 
 An OPTIONS request that is sent to Asterisk but not to a specific endpoint 
 is
 currently sent a 404 in response. This is because, not surprisingly, an 
 empty
 extension is never going to be found in the dialplan.
 
 This patch makes it so that we only attempt to look up the endpoint in the
 dialplan if it is specified in the OPTIONS request URI.
 
 An empty extension in Asteirsk is the s extension, right?
 In chan_sip we answer with 200 OK if an s extension can be found, 
 otherwise an error is generated.
 
 If that's a good or bad solution is a differernt thing - but we do handle 
 empty extensions,
 especially in the dahdi channel.
 
 
 Yup - chan_sip, prior to calling ast_exists_extension, will often
 insert an s if the request URI does not contain a user portion as
 well. We aren't currently doing that in the part of chan_pjsip that
 handles OPTIONS requests. My commit message probably could have been a
 bit clearer - the ast_exists_extension does not handle 'blank'
 extensions by itself, but other places prevent a blank extension from
 being passed to that function by providing the s extension if
 nothing else was specified.
When a channel is created it uses s@default by default...

 
 For OPTIONS requests in particular, I'm not sure that really is super
 useful. Clearly, an inbound call is a different matter. But for
 OPTIONS requests, having to provide the s extension to prevent a 404
 when the request URI did not specify a username feels odd.
 
 We could do that if people liked, however :-)

I don't like that behaviour.

A bigger issue is if we should at any point try to implement real options 
answers. After
authentication we could add an SDP...

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Timeline ZRTP Implementation

[Olle E. Johansson]

On 11 Sep 2014, at 19:51, Matthew Jordan mjor...@digium.com wrote:

 
 
 On Thu, Sep 11, 2014 at 1:26 PM, Jonathan Brown jbr...@fmcllc.com wrote:
 Are there any plans to add ZRTP functionality anytime soon to this product? 
 ZRTP is the only way for end users to ensure their conversations are private 
 without having to blindly trust the server. ZRTP encryption would greatly 
 increase adoption of your product and sadly is an almost necessity when 
 reviewing the news of today’s security posture. Most competitor products 
 offer ZRTP which is confusing why Asterisk has not adopted it.
 
  
 
 
 
 To my knowledge, no one has provided a patch for ZRTP for Asterisk in some 
 time.
 
 If Asterisk does not do something you would like it to do, a patch would be 
 the appropriate place to start.
 
 https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process

There was a patch written/founded by Phil Zimmerman a while ago.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [svn-commits] mjordan: branch 11 r422294 - in /branches/11: ./ LICENSE

[Olle E. Johansson]

On 28 Aug 2014, at 23:53, SVN commits to the Digium repositories 
svn-comm...@lists.digium.com wrote:

 This patch updates the LICENSE text to allow users to link Asterisk with
 UniMRCP and distribute the resulting binaries.

Thank you! Good decision.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3952: Add 'rtpbindaddr' setting for chan_sip

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3952/#review13197
---

Ship it!


I think this is a great addition. 
A side note for the archives: I always wanted to do this with an array of IP 
addresses to get some sort of load sharing. In my John Todd Dragster tests a 
few years ago the limiting factor was the gigabit ethernet interface. What if 
we could split the load between multiple interfaces? 

- Olle E Johansson


On Aug. 27, 2014, 9:44 p.m., Paul Belanger wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3952/
 ---
 
 (Updated Aug. 27, 2014, 9:44 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Users now have the ability to bind the rtpengine instance to a specific IP 
 address.  For example, you want chan_sip (call control) on eth0 but rtp 
 (media) on eth1.
 
 
 Diffs
 -
 
   trunk/configs/samples/sip.conf.sample 422198 
   trunk/channels/chan_sip.c 422198 
   trunk/CHANGES 422198 
 
 Diff: https://reviewboard.asterisk.org/r/3952/diff/
 
 
 Testing
 ---
 
 kamailio proxy with rtpengine.  Multihomed asterisk system.
 
 
 Thanks,
 
 Paul Belanger
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3780: res_pjsip_outbound_publish / res_pjsip_publish_asterisk: Add outbound PUBLISH support with 'asterisk' event type.

[Olle E. Johansson]

On 31 Jul 2014, at 17:28, Joshua Colp reviewbo...@asterisk.org wrote:

 This adds two PJSIP modules which add outbound PUBLISH support and an 
 'asterisk' event type.
 
I don't think it's a good idea to mix different events in one event tag. Will 
make it hard to handle in proxys and stuff. We will have to
parse the json to find out what it is and what to do with it. It's not a good 
solution.

Use asterisk-mwi and asterisk-devstate instead.

/O-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3709: configure.ac: Check OpenSSL for support of Elliptic Curve cryptography

[Olle E. Johansson]

On 04 Jul 2014, at 14:41, wdoekes reviewbo...@asterisk.org wrote:

 And generally there is a period of rest between submitting the review and 
 committing the code, so you would normally have been in time for review.
 
I would kindly like to remind everyone about this. Especially if it affects 
release versions. 

Have a great weekend!

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [svn-commits] mjordan: trunk r418019 - in /trunk: ./ addons/ apps/ channels/ channels/h323/...

[Olle E. Johansson]

Matt!
I thank you oh our leader great
For this message following the farewell
of a lot of old crap, old mate,
which no one longer could sell.

But please don't change the commit rules!

/O ;-)

On 04 Jul 2014, at 15:26, SVN commits to the Digium repositories 
svn-comm...@lists.digium.com wrote:

 Author: mjordan
 Date: Fri Jul  4 08:26:37 2014
 New Revision: 418019
 
 URL: http://svnview.digium.com/svn/asterisk?view=revrev=418019
 Log:
 Remove many deprecated modules
 
 Billing records are fair,
 To get paid is quite bright,
 You should really use ODBC;
 Good-bye cdr_sqlite.
 
 Microsoft did once push H.323,
 Hell, we all remember NetMeeting.
 But try to compile chan_h323 now
 And you will take quite a beating.
 
 The XMPP and SIP war was fierce,
 And in the distant fray
 Was birthed res_jabber/chan_jingle;
 But neither to stay.
 
 For everyone did care and chase what Google professed.
 Free Internet Calling was what devotees cried,
 But Google did change the specs so often
 That the developers were happy the day chan_gtalk died.
 
 And then there was that odd application
 Dedicated to the Polish tongue.
 app_saycountpl was subsumed by Say;
 One could say its bell was rung.
 
 To read and parse a file from the dialplan
 You could (I guess) use an application.
 app_readfile did fill that purpose, but I think
 A function is perhaps better in its creation.
 
 Barging is rude, I'm not sure why we do it.
 Inwardly, the caller will probably sigh.
 But if you really must do it,
 Don't use app_dahdibarge, use ChanSpy.
 
 We all despise the sound of tinny robots
 It makes our queues so cold.
 To control such an abomination
 It's better to not use Wait/SetMusicOnHold.
 
 It's often nice to know properties of a channel
 It makes our calls right
 We have a nice function called CHANNEL
 And so SIPCHANINFO is sent off into the night.
 
 And now things get odd;
 Apparently one could delimit with a colon
 Properties from the SIPPEER function!
 Commas are in; all others are done.
 
 Finally, a word on pipes and commas.
 We're sorry. We can't say it enough.
 But those compatibility options in asterisk.conf;
 To maintain them forever was just too tough.
 
 This patch removes:
 
 * cdr_sqlite
 * chan_gtalk
 * chan_jingle
 * chan_h323
 * res_jabber
 * app_saycountpl
 * app_readfile
 * app_dahdibarge
 
 It removes the following applications/functions:
 
 * WaitMusicOnHold
 * SetMusicOnHold
 * SIPCHANINFO
 
 It removes the colon delimiter from the SIPPEER function.
 
 Finally, it also removes all compatibility options that were configurable from
 asterisk.conf, as these all applied to compatibility with Asterisk 1.4 
 systems.
 
 Review: https://reviewboard.asterisk.org/r/3698/
 
 
 Removed:
trunk/addons/app_saycountpl.c
trunk/apps/app_dahdibarge.c
trunk/apps/app_readfile.c
trunk/channels/chan_gtalk.c
trunk/channels/chan_h323.c
trunk/channels/chan_jingle.c
trunk/channels/h323/
trunk/configs/gtalk.conf.sample
trunk/configs/jabber.conf.sample
trunk/configs/jingle.conf.sample
trunk/res/res_jabber.c
 Modified:
trunk/CHANGES
trunk/UPGRADE.txt
trunk/addons/Makefile
trunk/channels/Makefile
trunk/channels/chan_sip.c
trunk/configs/asterisk.conf.sample
trunk/include/asterisk/options.h
trunk/main/asterisk.c
trunk/main/pbx.c
trunk/pbx/pbx_realtime.c
trunk/res/ael/pval.c
trunk/res/res_agi.c
trunk/res/res_musiconhold.c
trunk/utils/ael_main.c
trunk/utils/conf2ael.c
 
 Modified: trunk/CHANGES
 URL: 
 http://svnview.digium.com/svn/asterisk/trunk/CHANGES?view=diffrev=418019r1=418018r2=418019
 ==
 --- trunk/CHANGES (original)
 +++ trunk/CHANGES Fri Jul  4 08:26:37 2014
 @@ -12,6 +12,21 @@
 --- Functionality changes from Asterisk 12 to Asterisk 13 
 --
 
 +app_dahdibarge
 +--
 + * This module was deprecated and has been removed. Users of app_dahdibarge
 +   should use ChanSpy instead.
 +
 +app_readfile
 +--
 + * This module was deprecated and has been removed. Users of app_readfile
 +   should use func_env's FILE function instead.
 +
 +app_saycountpl
 +--
 + * This module was deprecated and has been removed. Users of app_saycountpl
 +   should use the Say family of applications.
 +
 AMI
 --
  * New DeviceStateChanged and PresenceStateChanged AMI events have been added.
 @@ -30,6 +45,11 @@
  * New AMI actions PRIDebugSet, PRIDebugFileSet, and PRIDebugFileUnset
enable manager control over PRI debugging levels and file output.
 
 +cdr_sqlite
 +-
 + * This module was deprecated and has been removed. Users of cdr_sqlite
 +   should use cdr_sqlite3_custom.
 +
 CEL
 --
  * The bridge_technology extra field key has been added to BRIDGE_ENTER
 @@ -46,6 +66,30 @@
 
  * Added several SS7 

Re: [asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

On 02 Jul 2014, at 13:00, Olle E. Johansson o...@edvina.net wrote:

 
 On 02 Jul 2014, at 11:58, Olle E. Johansson o...@edvina.net wrote:
 
 Related issue:
 
 https://issues.asterisk.org/jira/browse/ASTERISK-23142
 
 
 In the big jitterbuffer patch in 2006 ther was code that sets a flag on a 
 AST_FRAME
 that it contains time stamp information. This is set on all incoming RTP 
 audio frames.
 
 When sending RTP we reset the timestamp to the one in the frame if this flag 
 is set.
 
 Now, if we have a call on hold this is dangerous.
 
 Alice calls Bob and he answers.
 - we take the incoming TS and send out to Bob in the RTP stream
 
 Alice puts Bob on hold
 - we activate MOH and raise the TS with 160 for every RTP packet
 
 Alice puts Bob off hold
 - We get RTP from Alice with a new time stamp and reset ours
 
 This can lead to a big jump in time stamps and in our case lead to loss of 
 audio.
 
 I don't see any reason to change the TS like this in the outbound stream. 
 It's an
 unrelated stream and we set the TS on different grounds.
 
 We could shange the SSRC when this happens, but I already have systems 
 complaining over the way Asterisk change SSRC every time we detect a 
 problem, so I don't think it's a good idea (TM).
 
 I can understand why the jitter buffer for an incoming RTP stream needs to 
 know if a 
 stream has timing info, but I don't see a reason for us using the same 
 timing on the
 outbound stream.
 
 Does anyone see any harm in deleting the piece of code that resets the 
 timestamp,
 overriding the calculations for a new time stamp already done in the RTP 
 write code?
 
 Apart from incoming RTP, the translate.c file sets this flag if the 
 translation means
 that the number of samples has changed (if I understand it correctly).  But 
 since we
 normally calculate the TS based on number of samples and the outbound rate 
 that should not be a problem for us.
 
 Or?


We have been running hundreds of different tests and only see improvements. 

Looking forward to your comments.

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

On 03 Jul 2014, at 19:45, Matthew Jordan mjor...@digium.com wrote:

 On Wed, Jul 2, 2014 at 4:58 AM, Olle E. Johansson o...@edvina.net wrote:
 Related issue:
 
 https://issues.asterisk.org/jira/browse/ASTERISK-23142
 
 
 In the big jitterbuffer patch in 2006 ther was code that sets a flag on a 
 AST_FRAME
 that it contains time stamp information. This is set on all incoming RTP 
 audio frames.
 
 When sending RTP we reset the timestamp to the one in the frame if this flag 
 is set.
 
 Now, if we have a call on hold this is dangerous.
 
 Alice calls Bob and he answers.
 - we take the incoming TS and send out to Bob in the RTP stream
 
 Alice puts Bob on hold
 - we activate MOH and raise the TS with 160 for every RTP packet
 
 Alice puts Bob off hold
 - We get RTP from Alice with a new time stamp and reset ours
 
 This can lead to a big jump in time stamps and in our case lead to loss of 
 audio.
 
 If I'm following the scenario, this could be two different problems:
 (1) A jump in the timestamp from Alice causes a jitterbuffer on either
 Alice or Bob (depending on how it was put on a channel) to view the
 audio stream as being skewed. The jitterbuffer should to be reset when
 this occurs (and if it isn't, that's bad)
You should never run an Asterisk jitterbuffer in a bridged call.
But it is of course possible.

 (2) The outbound stream faithfully replicating the timestamp from the
 inbound side causes the jump in timestamps to be reflected across the
 bridge, confusing Bob's UA.
 
 Problem #1 shouldn't happen so long as the inbound channel driver
 raises a HOLD, SRCUPDATE, or SRCCHANGE control frame. This should
 cause the abstract jitterbuffer to resync itself to the new stream
 (with its new timestamps). (There may be some issues with this in 11
 with func_jitterbuffer, but getting a pcap illustrating this has been
 problematic for the issues filed for it so far. I think we fixed it in
 12 when things with the jitterbuffer got consolidated between the
 framehook provided by the function and the jitterbuffer hooks in
 bridging).
 
 Looking at what you highlighted to be the offending code:
 
if (ast_test_flag(frame, AST_FRFLAG_HAS_TIMING_INFO)) {
rtp-lastts = frame-ts * rate;
}
 
 This code is old... as in, it goes back at least to r31159, which
 means the reason for its inclusion is going to be hard to determine.
 It may be that we thought at the time that reproducing the timestamps
 from the inbound stream was a 'good thing' if it was available... I
 don't know.
 
 I don't see any reason to change the TS like this in the outbound stream. 
 It's an
 unrelated stream and we set the TS on different grounds.
 
 I would think we would either (a) pass it through when in a p2p
 bridge, or (b) generate it completely separately when we are in a core
 bridge.
 
 We could shange the SSRC when this happens, but I already have systems 
 complaining over the way Asterisk change SSRC every time we detect a 
 problem, so I don't think it's a good idea (TM).
 
 Agreed.
 
 I can understand why the jitter buffer for an incoming RTP stream needs to 
 know if a
 stream has timing info, but I don't see a reason for us using the same 
 timing on the
 outbound stream.
 
 Depends on the what we mean by outbound stream :-)
 
 In 1.8/11, the jitterbuffer provided by channel drivers and managed by
 the bridging performed in ast_generic_bridge is put on the write side
 of a channel - which could be construed as a part of the outbound
 media stream. That means we don't de-jitter jittered audio coming off
 of a channel, we de-jitter it on the channel that it is writing to in
 a two party bridge (which is odd and strange, but that is what
 happens). So as long as we mean 'outbound stream' to be the frame at
 the point in time it is handed off to the RTP implementation, then
 we're good; at that point, we're out of any jitter buffer. Up until
 the frame is written to the RTP implementation, it needs timing
 information.
This is when writing, after jitter buffers and all I guess. Just before writing 
to the network.
 
 Now, the jitterbuffer put on a channel by func_jitterbuffer is a
 framehook, and is put on the read side of a channel (which makes a lot
 more sense, since the media coming off of a channel is generally where
 think of jitter coming from).
 
 
 Does anyone see any harm in deleting the piece of code that resets the 
 timestamp,
 overriding the calculations for a new time stamp already done in the RTP 
 write code?
 
 
 I don't think so... what happened when you removed it? :-)
 

Everything started working, the gateway that had problems started happily 
relaying auio.
As stated in a separate e-mail, we've run a lot of different tests in our 
testbed and have
no issues. We have *not* tested stuff like reframing from 20 to 30 ms which 
seems to use
the same flag.

/O


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com

Re: [asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

On 03 Jul 2014, at 19:45, Matthew Jordan mjor...@digium.com wrote:

 On Wed, Jul 2, 2014 at 4:58 AM, Olle E. Johansson o...@edvina.net wrote:
 Related issue:
 
 https://issues.asterisk.org/jira/browse/ASTERISK-23142
 
 
 In the big jitterbuffer patch in 2006 ther was code that sets a flag on a 
 AST_FRAME
 that it contains time stamp information. This is set on all incoming RTP 
 audio frames.
 
 When sending RTP we reset the timestamp to the one in the frame if this flag 
 is set.
 
 Now, if we have a call on hold this is dangerous.
 
 Alice calls Bob and he answers.
 - we take the incoming TS and send out to Bob in the RTP stream
 
 Alice puts Bob on hold
 - we activate MOH and raise the TS with 160 for every RTP packet
 
 Alice puts Bob off hold
 - We get RTP from Alice with a new time stamp and reset ours
 
 This can lead to a big jump in time stamps and in our case lead to loss of 
 audio.
 
 
Btw, for the tests: The above scenarios is a simple test. Two UAs placing a 
call,
moh enabled. UA one puts call on hold, asterisk plays moh. UA puts call off 
hold,
sudden jump in time stamps.

I ran this on my laptop and could repeat the issue before patch and see it
gone after patch.

/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

Related issue:

https://issues.asterisk.org/jira/browse/ASTERISK-23142


In the big jitterbuffer patch in 2006 ther was code that sets a flag on a 
AST_FRAME
that it contains time stamp information. This is set on all incoming RTP audio 
frames.

When sending RTP we reset the timestamp to the one in the frame if this flag is 
set.

Now, if we have a call on hold this is dangerous.

Alice calls Bob and he answers.
- we take the incoming TS and send out to Bob in the RTP stream

Alice puts Bob on hold
 - we activate MOH and raise the TS with 160 for every RTP packet

Alice puts Bob off hold
 - We get RTP from Alice with a new time stamp and reset ours

This can lead to a big jump in time stamps and in our case lead to loss of 
audio.

I don't see any reason to change the TS like this in the outbound stream. It's 
an
unrelated stream and we set the TS on different grounds.

We could shange the SSRC when this happens, but I already have systems 
complaining over the way Asterisk change SSRC every time we detect a problem, 
so I don't think it's a good idea (TM).

I can understand why the jitter buffer for an incoming RTP stream needs to know 
if a 
stream has timing info, but I don't see a reason for us using the same timing 
on the
outbound stream.

Does anyone see any harm in deleting the piece of code that resets the 
timestamp,
overriding the calculations for a new time stamp already done in the RTP write 
code?


/O


Index: res/res_rtp_asterisk.c
===
--- res/res_rtp_asterisk.c  (revision 417744)
+++ res/res_rtp_asterisk.c  (working copy)
@@ -1238,9 +1238,14 @@
rtp-lastdigitts = rtp-lastts;
}
 
+#ifdef MAYBE_BROKEN_CODE
+   /* This means that we strictly follow the timestamps of the incoming 
stream, which may
+  be unrelated to our send stream. I think it's a bad idea. /OEJ 
+ */
if (ast_test_flag(frame, AST_FRFLAG_HAS_TIMING_INFO)) {
rtp-lastts = frame-ts * rate;
}
+#endif
 
ast_rtp_instance_get_remote_address(instance, remote_address);
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Timestamps in RTP bridged calls

[Olle E. Johansson]

On 02 Jul 2014, at 11:58, Olle E. Johansson o...@edvina.net wrote:

 Related issue:
 
 https://issues.asterisk.org/jira/browse/ASTERISK-23142
 
 
 In the big jitterbuffer patch in 2006 ther was code that sets a flag on a 
 AST_FRAME
 that it contains time stamp information. This is set on all incoming RTP 
 audio frames.
 
 When sending RTP we reset the timestamp to the one in the frame if this flag 
 is set.
 
 Now, if we have a call on hold this is dangerous.
 
 Alice calls Bob and he answers.
 - we take the incoming TS and send out to Bob in the RTP stream
 
 Alice puts Bob on hold
 - we activate MOH and raise the TS with 160 for every RTP packet
 
 Alice puts Bob off hold
 - We get RTP from Alice with a new time stamp and reset ours
 
 This can lead to a big jump in time stamps and in our case lead to loss of 
 audio.
 
 I don't see any reason to change the TS like this in the outbound stream. 
 It's an
 unrelated stream and we set the TS on different grounds.
 
 We could shange the SSRC when this happens, but I already have systems 
 complaining over the way Asterisk change SSRC every time we detect a problem, 
 so I don't think it's a good idea (TM).
 
 I can understand why the jitter buffer for an incoming RTP stream needs to 
 know if a 
 stream has timing info, but I don't see a reason for us using the same timing 
 on the
 outbound stream.
 
 Does anyone see any harm in deleting the piece of code that resets the 
 timestamp,
 overriding the calculations for a new time stamp already done in the RTP 
 write code?

Apart from incoming RTP, the translate.c file sets this flag if the translation 
means
that the number of samples has changed (if I understand it correctly).  But 
since we
normally calculate the TS based on number of samples and the outbound rate 
that should not be a problem for us.

Or?
/O
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev