Re: [asterisk-dev] Adding support for MKI in res_srtp

[Jean Aunis]

Le 06/10/2022 à 12:35, Joshua C. Colp a écrit :

On Thu, Oct 6, 2022 at 7:27 AM Jean Aunis  wrote:

[snip]


From a general perspective it seems sane, but that's without any 
further knowledge of MKI.
Thanks for the reply Joshua. I'll start this way and will provide the 
patch once it's mature enough.-- 
_
-- 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] Adding support for MKI in res_srtp

[Jean Aunis]

Hello,

I'm working on a patch to add support for MKI in res_srtp.

For those who may not be familiar with the subject, MKI is a re-keying 
mechanism for SRTP which involves appending a Master Key Identifier 
(MKI) inside each SRTP packet in order to change the master key in use.


Master key and MKI negotiation is out of scope of this patch.

Before going forward, I'd like to submit to you the changes I plan in 
res_srtp's API, just to know if I'm going in the right direction or if I 
should design it another way.


First, I would add a method in *ast_srtp_policy_res* to add several 
master keys (together with their MKI) to the SRTP policy. It returns the 
index at which the key was inserted, which can be used later to 
reference the master key:


*struct ast_srtp_policy_res {
        [...]
+   int (*add_master_key)(struct ast_srtp_policy *policy, const 
unsigned char *key, size_t key_len, const unsigned char *salt, size_t 
salt_len, const unsigned char *mki, size_t mki_len);

 };*

Second, I would add two methods in *ast_srtp_res* to enable or disable 
MKI usage for incoming and outgoing SRTP packets. The MKI to use for 
outgoing packets is referenced by its index, as returned by 
*ast_srtp_policy_res.**add_master_key* :


*struct ast_srtp_res {
        [...]
+   int (*use_inbound_mki)(struct ast_srtp *srtp, int enable);**
**+   int (*use_outbound_mki)(struct ast_srtp *srtp, int enable, int 
mki_index);

 };*

Also attached a patch file summarizing these changes.

Any feedback will be appreciated!

Regards,

Jean
diff --git a/include/asterisk/res_srtp.h b/include/asterisk/res_srtp.h
index 741d4f9ac0..f075c6507c 100644
--- a/include/asterisk/res_srtp.h
+++ b/include/asterisk/res_srtp.h
@@ -50,6 +50,27 @@ struct ast_srtp_res {
 	int (*protect)(struct ast_srtp *srtp, void **buf, int *size, int rtcp);
 	/* Obtain a random cryptographic key */
 	int (*get_random)(unsigned char *key, size_t len);
+	/*!
+	 * \brief Configure the SRTP session to use or ignore the MKI field in incoming SRTP packets
+	 *
+	 * \param srtp the SRTP session to configure
+	 * \param enable whether or not enabling incoming MKI usage
+	 *
+	 * \retval 0 success
+	 * \retval -1 failure
+	 */
+	int (*use_inbound_mki)(struct ast_srtp *srtp, int enable);
+	/*!
+	 * \brief Configure the SRTP session to enable or not MKI usage in outgoing SRTP packets
+	 *
+	 * \param srtp the SRTP session to configure
+	 * \param enable whether or not enabling MKI usage
+	 * \param mki_index the index of the MKI to use; ignored if enable = 0
+	 *
+	 * \retval 0 success
+	 * \retval -1 failure
+	 */
+	int (*use_outbound_mki)(struct ast_srtp *srtp, int enable, int mki_index);
 };
 
 /* Crypto suites */
@@ -72,6 +93,13 @@ struct ast_srtp_policy_res {
 	void (*destroy)(struct ast_srtp_policy *policy);
 	int (*set_suite)(struct ast_srtp_policy *policy, enum ast_srtp_suite suite);
 	int (*set_master_key)(struct ast_srtp_policy *policy, const unsigned char *key, size_t key_len, const unsigned char *salt, size_t salt_len);
+	/*!
+	 * \brief Add a master key with its MKI to the SRTP policy
+	 *
+	 * \retval -1 failure
+	 * \retval >= 0 index at which the key was inserted
+	 */
+	int (*add_master_key)(struct ast_srtp_policy *policy, const unsigned char *key, size_t key_len, const unsigned char *salt, size_t salt_len, const unsigned char *mki, size_t mki_len);
 	void (*set_ssrc)(struct ast_srtp_policy *policy, unsigned long ssrc, int inbound);
 };
 
-- 
_
-- 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] Handling blind transfers with ARI

[Jean Aunis]

Le 15/06/2022 à 16:33, Joshua C. Colp a écrit :

[snip]

Based on the test coverage for this[1] you aren't really expected to 
manipulate the bridge yourself. The ";1" side of the Local channel is 
supposed to automatically go into your ARI application and take the 
transferer channel place in the bridge, and then the transferer leaves 
the bridge and ARI application. I don't know why both channels are 
going through the dialplan in your scenario.


[1] 
https://github.com/asterisk/testsuite/tree/master/tests/rest_api/external_interaction/blind_transfer



Hi Joshua,

Thanks for the hint. I'll check why the transferee is also redirected to 
the dialplan.
-- 
_
-- 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] Handling blind transfers with ARI

[Jean Aunis]

Hello,

I had no answer to this question on asterisk-app-dev, so I'm trying here.

I'm trying to figure out how blind transfers are supposed to work with ARI.

When two channels are bridged together through ARI, and one of them 
performs a blind SIP transfer, two things happen :


- a Local channel is instantiated and goes through the dialplan at the 
specified destination


- the transferee channel goes through the same dialplan at the specified 
destination


The latter looks fine. The former is strange. I understand that this 
Local channel is created to avoid losing track of the transferee channel 
in ARI, but:


- how am I supposed to handle it ?

- when the transfer is successful, which channel must be placed in which 
bridge ?


- why do both channels go through the same part of the dialplan ? I 
would have expected only one of them to do that.


Any hints ?

Regards,

Jean



--
_
-- 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] Question regarding native bridge's framehook

[Jean Aunis]

Le 06/10/2021 à 14:35, Joshua C. Colp a écrit :
On Wed, Oct 6, 2021 at 6:54 AM Jean Aunis <mailto:jean.au...@prescom.fr>> wrote:


Hello,

I have a question regarding the use of a framehook in
bridge_native_rtp.

The framehook is used to redirect RTP streams when a hold, unhold
or RTP
update is detected.

But what's the reason for doing this in a framehook ?


[...]


I don't remember specific reasoning. It may or may not work as needed 
there.


[...]

If it's of use for anybody, I think I've got the answer: that's because 
HOLD and UNHOLD frames may be written directly to the destination 
channel instead of going through the bridge. For example when using 
hold/unhold ARI calls.
-- 
_
-- 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] Question regarding native bridge's framehook

[Jean Aunis]

Hello,

I have a question regarding the use of a framehook in bridge_native_rtp.

The framehook is used to redirect RTP streams when a hold, unhold or RTP 
update is detected.


But what's the reason for doing this in a framehook ? Why not doing it 
in the native_rtp_bridge_write callback ? Doing this in the framehook is 
somehow more "complex" since it implies restoring a proper lock order.


I'm asking, because I've got a similar problem to solve in a custom module.

Regards,

Jean



--
_
-- 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 Video

[Jean Aunis]

Le 13/07/2021 à 06:11, John T. Bittner a écrit :


Hello,

Anyone know how to force Asterisk into a video call even if the source 
invite doesn’t show video support. ?. I ask because I am dealing with 
a bunch of automation wall panels that have inbound video features but 
no camera. Inbound video works perfect but when you make a call out to 
say a door station you get audio only. (The panels are very limited 
and have no options to changing its invite.)



Any ideas… Any way to trick it. ? I got it semi working by using 
manager api to call the door station first then the panel but its clunky.


Any help is much appreciated.

Thanks

John Bittner

CTO


Hello,

You could try using ARI's "originate" function with the "formats" 
parameter containing a video codec.


Regards,

Jean

-- 
_
-- 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 messaging : specifying the user portion of the request-URI

[Jean Aunis]

Le 16/06/2021 à 16:32, George Joseph a écrit :


On Wed, Jun 16, 2021 at 6:27 AM George Joseph > wrote:



Changes up in gerrit...

https://gerrit.asterisk.org/c/asterisk/+/16068 



Thanks. I've just tested it, with both the dialplan and AMI, and it's 
working well. The From and To headers take the appropriate values.


That's exactly the behaviour I was looking for, thanks for this great job!

I'm using a very simple PJSIP configuration with a single aor and a 
single contact, so there are probably additional cases which would be 
worth testing.



-- 
_
-- 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 messaging : specifying the user portion of the request-URI

[Jean Aunis]

Le 15/06/2021 à 15:28, George Joseph a écrit :

[2021-06-15 10:42:49.885] WARNING[5163]: res_pjsip_messaging.c:247

insert_user_in_contact_uri: Dest: 'PJSIP/3200@linphone' MSG SEND
FAIL:
There's already a username in endpoint linphone's contact URI
'sip:linphone@127.0.0.1:5063
;line=068b0910396d2ed'.
[2021-06-15 10:42:49.885] ERROR[5163]: res_pjsip_messaging.c:1240



Yeah that's the expected behavior although I guess I can change it.  I 
figured that if there was a user already specified in the contact uri 
that overwriting it with something else was probably not a good idea.  
  Now that I think of it though, I was thinking more from sending 
messages upstream to a provider not downstream to a client.


So what should the behavior be?  To construct the Request URI replace 
any user in the contact URI with the user or number specified in the 
MessageSend call?


I would be in favour of trusting the dialplan. If someone wants to send 
a message to an endpoint with a specific number, that should be 
possible. That looks more flexible to me.


By the way, I'm fine with the modification of MessageSend you describe. 
What about applying the same modification to the MessageSend AMI action 
and to the sendMessage / sendMessageToEndpoint requests in ARI ?


-- 
_
-- 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 messaging : specifying the user portion of the request-URI

[Jean Aunis]

Le 09/06/2021 à 16:18, George Joseph a écrit :

Hi Guys,

The change for allowing a dialstring-like destination in MessageSend 
(pjsip only) is now committed in the 16, 18 and master branches.  You 
can now use MessageSend(pjsip:PJSIP/@) and 
the request URI will be composed of the endpoint's contact uri with 
the number inserted as the user portion of the uri. Please give it a test.


For Asterisk 19 (not an LTS release) what would you guys think of 
changing the MessageSend application to accept discrete parameters for 
destination uri, endpoint, user, etc.?  This would remove about 400 
lines of fuzzy parsing code and give you the most flexibility in 
constructing a destination.


Hi George,

I've just tested this with the latest version on branch 16.

I have a SIP phone "linphone" performing an inbound registration, and I 
try to send a message to it with the following dialplan:


exten = 800,1,Set(MESSAGE(body)=test)
same  = n,MessageSend(pjsip:PJSIP/3200@linphone,8000)

The test fails. The SIP MESSAGE is not sent and the following errors are 
displayed:


*CLI> channel originate Local/800@default application Hangup
*CLI> -- Executing [800@default:1] 
Set("Local/800@default-;2", "MESSAGE(body)=test") in new stack

    -- Called 800@default
    -- Executing [800@default:2] 
MessageSend("Local/800@default-;2", 
"pjsip:PJSIP/3200@linphone,8000") in new stack
[2021-06-15 10:42:49.885] WARNING[5163]: res_pjsip_messaging.c:247 
insert_user_in_contact_uri: Dest: 'PJSIP/3200@linphone' MSG SEND FAIL: 
There's already a username in endpoint linphone's contact URI 
'sip:linphone@127.0.0.1:5063;line=068b0910396d2ed'.
[2021-06-15 10:42:49.885] ERROR[5163]: res_pjsip_messaging.c:1240 
msg_send: PJSIP MESSAGE - Could not find endpoint 'PJSIP/3200@linphone' 
and no default outbound endpoint configured
    -- Auto fallthrough, channel 'Local/800@default-;2' status 
is 'UNKNOWN'


I can provide logs if you need.

Regards,

Jean




--
_
-- 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 messaging : specifying the user portion of the request-URI

[Jean Aunis]

Le 04/05/2021 à 20:30, George Joseph a écrit :




I think the easiest way to solve this is to just allow MessageSend take
the same format as a simple dial string like so

MessageSend(pjsip:PJSIP/8005551212@provider)
"pjsip:" routes the request to the pjsip channel driver.
"PJSIP/" tells the pjsip channel driver that what follows is formatted 
as a

dial string.

Great, that would solve my problem. Thanks for the feedback.
-- 
_
-- 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] PJSIP messaging : specifying the user portion of the request-URI

[Jean Aunis]

Hi,

I'm trying to send a SIP MESSAGE to a PJSIP endpoint, while specifying a 
destination number (that is, the "user" portion of the request URI in 
sip:u...@domain.com).


Currently, this is only possible by specifying the full request URI. For 
example, someone could use:


> MessageSend(pjsip:endpoint/sip:1000@12.0.0.1)

to send a SIP MESSAGE to number 1000.

But to do this, one needs to know the contact associated to the 
endpoint. This is a problem if the endpoint is dynamically registering 
to Asterisk: the contact information may change over time.


When using the dialplan, there is a straightforward solution: using 
PJSIP_DIAL_CONTACTS.


Things become tricky when using ARI or AMI. Retrieving the contact 
information requires sending an AMI request each time a SIP MESSAGE has 
to be sent... this can create a lot of overhead.


chan_sip used to solve this problem this way: when calling 
MessageSend(sip:user@endpoint), "endpoint" was at first searched in the 
endpoints list before being used as a FQDN or an IP address.


I understand this is more complex with PJSIP because there may be 
multiple AOR/ contacts for a single endpoint...


Any ideas ?

Regards,

Jean



--
_
-- 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] Looking to input on a feature I would like to write...in depth Transfer (REFER) failure reasons

[Jean Aunis]

Le 08/01/2021 à 15:40, Dan Cropp a écrit :


Before I submit a feature request and take ownership of it, trying to 
gather some feedback.


I’m looking to write code for an additional feature in asterisk.

Currently, when performing a Transfer (REFER), the channel variable 
TRANSFERSTATUS only reports 3 values: SUCCESS, FAILURE, UNSUPPORTED.


We have some customers asking for a few additional results: 404 Not 
Found, 408 Request Timeout, and 486 Busy Here.


From past experience, these same customers will likely come up with 
some additional results they think should be returned.


Would it be better to add support where the TRANSFERSTATUS had new 
values for each of the additional result codes I make asterisk look for?


Or would it be better to add a new variable, example 
TRANSFERSTATUSCODE and have it return the SIP error code for the 
failure notification?  Personally, I like this approach because it 
means not having to add values for each possible sip error code that 
anyone would ever look for.


Dan



Hello Dan,

I would prefer the second approach of using a new variable, otherwise it 
may break existing dialplan.


Regards

Jean

-- 
_
-- 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] No Bridge Created Event published

[Jean Aunis]

Hi,

When I have to deal with bridges in ARI I explicitly subscribe the 
application to the newly created bridge. If I remember well this is 
because I don't get the BridgeDestroyed event otherwise.


The code (NodeJS) looks like something like this :

bridge.create().then( () => {
    ari.applications.subscribe({
        applicationName: 'myApplication',
        eventSource: 'bridge:' + bridge.id
    });
});

But I don't rely on BridgeCreated events, so maybe it won't work for 
you. I suppose there may be a race condition, depending whether the 
subscribe request comes before or after the BridgeCreated event is emitted.


Regards,

Jean

Le 21/10/2020 à 17:41, Jöran Vinzens a écrit :

Hi,

yes, we do subscribe to an application.
So we e.g. subscribe to app "foo". As soon as there is a new 
channel we start Stasis(foo) and we get events for this channel. From 
our backend we create a bridge and here is the issue. There is no 
"BridgeCreated" Event published to "foo".
There is no way to spawn a bridge within a specific application like 
"foo". There is no parameter in bridge create where you can specify 
the app name.




On Wed, Oct 21, 2020 at 5:20 PM Sylvain Boily > wrote:


Hello,

On 2020-10-21 10:22 AM, Jöran Vinzens wrote:
> Hi all,
>
> yesterday at AstriDevCon we started a discussion about Bridge
Created
> Events on ARI.
> According to the Documentation there is such an event, but I have
> never seen one.
>
> My Stasis App is connected to a specific App and Consumes only
these
> Events. While creating a Bridge, there is no way to configure a ARI
> App name, where these events should be published.

A subscribe to the application is not the good way?


https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Applications+REST+API#Asterisk18ApplicationsRESTAPI-subscribe

I'm not completely sure about your use case, but i can share what
we did
if it can help.


https://github.com/wazo-platform/wazo-calld/blob/master/wazo_calld/plugins/adhoc_conferences/stasis.py#L58

Sylvain


-- 
_

-- 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



--
Jöran Vinzens -vinz...@sipgate.de  
Telefon: +49 211-63 55 56-21
Telefax: +49 211-63 55 55-22

sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391

www.sipgate.de    -www.sipgate.co.uk  


-- 
_
-- 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 Codec Negotiation: Need info and uses cases

[Jean Aunis]

I agree with Michael's principles.

I would just add one question, for which I don't have a proper answer : 
how do we handle codecs with different configuration parameters ?


Example :

Alice's endpoint is configured with the codec AMR-WB, with the parameter 
"octet-align" set to 1. Alice calls Bob with "octet-align" set to 0.


Should we accept Alice's parameters ? If yes, should we use asymmetric 
parameters for incoming and outgoing RTP frames ? If Bob also supports 
AMR-WB, should we forward Alice's parameters or stick to what is 
configured on Bob's endpoint ?


I'm talking about AMR-WB although it is not officially supported, but I 
suppose this applies to other codecs such as Opus.


Regards,

Jean

Le 06/06/2020 à 08:20, Michael Maier a écrit :

On June 03, 2020 at 22:17 George Joseph wrote:

Greetings All,

We've been working hard on new codec negotiation stuff for Asterisk 18 and
we've got some stuff to run by you.  It's a lot so please read carefully.

Thank you very much for your ongoing effort! I really appreciate it!
I additionally read this documentation here [1].
During writing down those lines I got the feeling how complicated could be ... .


Therefore there must be some basic principals on how to handle things. I tried 
to write them down as follows:

0. Asterisk is the only one which decides the codecs to be used on base of the allow 
list on each leg phone <-> Asterisk because I want to be sure about the codecs 
used on each leg
(because of existing network bandwidth restrictions e.g.)
1. The phone must support at least one of the codecs of the allow list. If not: 
drop the call
2. Bringing together the legs: the actually used codec list on each leg only 
contains the codecs supported by the respective device and which are allowed on 
the allow list on the
other hand.
3. At this point Asterisk decides: if there are common codecs on both legs -> 
use these / this. If there are no common codecs between two legs: transcode (Use 
case: don't prevent a
call as long as the codecs on each leg itself are allowed).
4. Each phone on each call leg may define its own codec order. But Asterisk 
finally has to decide, which side to prefer (-> switchable).
5. Basically, a phone mustn't advertise codecs it can't handle - if this can't 
be prevented, the codec has to be removed on the respective allow list of the 
line on Asterisk side.

[...]


Simple use case, Alice to Bob, no direct media.

1.  Under what conditions would we accept a format on an incoming offer
from a UAC (Alice) that *wasn't* in the UAC's endpoint allow= parameter?

The use case of this consideration seems to me: How to handle broken 
configurations.


   Does whether we accept formats not on the endpoint need to be
configurable?   Don't just say "yes". :)

No. From my point of view it never ever is Asterisk's job to handle broken 
configurations. Simple example: Phone sends SDP offer codec a) and b) which are 
both not on the allow list
for this endpoint -> drop the call.


   We need use cases.

Use case: It's not Asterisk's job to repair broken configurations. I must be 
sure that only allowed codecs are used on a defined port because of bandwidth 
restrictions e.g.


   We could
use the offer's list exclusively, use the endpoint's list exclusively,
merge the two together, or use only those in common.

Asterisk finally defines which codec to use. Therefore all codecs of the phones 
offer have to be dropped which are not part of the allow list. Furthermore all 
codecs of the allow
list have to be dropped, which are not contained in the SDP offer of the device.


  What happens if after
applying that operation, there are no formats in common?  Drop the call?

Exactly. Because it's a result of misconfiguration. It's not Asterisk's job to 
repair broken configurations.


Transocde?

Transcoding only if there is an allowed and supported codec on both sides which 
are not common. If there is one common codec on both sides - use this codec and 
do not transcode.


Using what format? It'd have to be one Alice accepts.  We'll
save the process of transcoding for a follow-on discussion.

2.  Under what conditions would we send a codec in an offer to a UAS (Bob)
that *wasn't* in the UAS's endpoint allow= parameter.

Never! I must be sure about the codecs to be used on a line (bandwidth).


   Similarly, under
what conditions would we send a format to Bob that *was* in his endpoint
allow= parameter but *wasn't* in the reconciled list we got from Alice via
the core?  Same possible options and questions as above.

Asterisk just should send the codecs to Bob which are part of the allow list - 
nothing more. The order could be defined by the reconciled list we got from 
Alice. Always the same use
case: Asterisk defines which codec to use just to be sure that bandwidth 
requirements can be enforced (or other requirements)


3.  OK now whatever we've decided to send to Bob, according to RFC3264 para
6.1, Bob MUST send back an answer that 

Re: [asterisk-dev] ARI Text messaging : inconsistencies in the API ?

[Jean Aunis]

Le 25/02/2020 à 19:09, Kevin Harwell a écrit :




I could never get (2). When trying to send variables in the 
TextMessageReceived event I would get a validation error unless they 
are formatted like (3).


(3) is the currently declared documented way to to it. As such any 
other way breaks the API definition. However, when executing a 
sendMessage (1) is the way it is currently working, so I'd be worried 
about breaking current implementations if we altered it to (3) for 
that case.


So what to do?

Option A: Leave sendMessage as is (1), update the documentation for 
it, and fix TextMessageReceived to send variables as defined like (3). 
Least breaking, but inconsistent way of sending and receiving variables.


Option B: Update sendMessage to pass a TextMessageVariable like (3), 
and fix TextMessageReceived to send variables like (3). The current 
API definition doesn't change, but may break implementations.


Option C: Leave sendMessage as is (1), update the TextMessageVariable 
API definition to be similar to (1), e.g { "var name": "var value" }, 
and not { "key": "var name", "value": "var value" }. This of course 
breaks the current API definition, and would break implementations if 
the validation error did not occur.


While "A" is the safest (least breaking?), personally, I prefer and 
choose "C". While it does break the API it seemingly has not worked 
since the start so I don't think this will break any current 
implementations. It will also make sending and receiving variables 
more consistent.


Thoughts?

I agree with option "C".


--
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com  & 
https://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

[asterisk-dev] ARI Text messaging : inconsistencies in the API ?

[Jean Aunis]

Hello,

I recently opened a issue regarding SIP headers handling in inbound 
messages (https://issues.asterisk.org/jira/browse/ASTERISK-28755).


Besides that problem, I think there are inconsistencies in the data 
format provided by ARI for sending or receiving text messages, and also 
in the documentation. Actually there are 3 different data formats for 
message variables:


1- to send a message, additional variables may be provided in a 
"variables" field. Its value must be a JSON object whose keys are the 
variable names, and values are the variable values, i.e:


...
"variables": { "My-Custom-Header": "the_value", "Another-header": 
"another_value" }


2- when a message is received, a TextMessageReceived is emitted, which 
contains a TextMessage which then contains a "variable" field. This 
field is a list of JSON objects, each one containing a single key (the 
variable name) with its value :


...
"variables": [{ "My-Custom-Header": "the_value" }, { "Another-header": 
"another_value" }]


(This is what I saw after quick-fixing the issue stated above)

3- the behaviour described in (2) is not consistent with the ARI 
documentation, which states:


TextMessageVariable: A key/value pair variable in a text message.

    key: string - A unique key identifying the variable.
    value: string - The value of the variable.

So I would expect the variable field to look like the following:

...
"variables": [{ "key": "My-Custom-Header", "value": "the_value" }, { 
"key": "Another-header", "value": "another_value" }]


I personally think formats (1) and (3) both make sense, but I find 
format (2) not very practical to use. Any thoughts on the subject ?


Regards,

--


Jean AUNIS

Ingénieur R
R engineer

Tel : +33 1 30 85 90 22
Standard: +33 1 30 85 55 55


   Rue de Broglie
   22300 LANNION
   FRANCE
www.prescom.fr <http://www.prescom.fr/>

/"Les informations contenues dans ce courrier sont données à titre 
purement informatif et ne peuvent être considérées comme contractuelles 
entre les récipiendaires,
la société PRESCOM." //"The content of this e-mail is purely for 
information and may not be considered as contractual between the 
recipients, PRESCOM company."/


-- 
_
-- 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] Audio to/from Asterisk

[Jean Aunis]

It may not be suitable for your use case, but you could instantiate a 
UnicastRTP channel. It will allocate an RTP port and store it into a 
channel variable.


Jean

Le 22/07/2019 à 10:01, Dan Jenkins a écrit :
Also coming back to this with some real-life case issues I'm currently 
facing and why I can't use audiosocket :(


I need to be able to ask the ARI/AGI/AMI for an IP/port combo and for 
an external app to then connect into asterisk rather than asterisk 
connecting to a URI elsewhere. Lets say I already have a nodejs (or 
any other language) process taking care of controlling that call via 
ARI or even AGI (all the different ways) - I need that same process to 
handle the media I'm sending and receiving to/from asterisk and so if 
I already have that process up and then Asterisk calls out to a 
generic URI then that media will never make it back to the original 
nodejs process.


I think its of upmost importance that I be able to ask asterisk for a 
host:port pair and then be able to connect to that port from my 
external application.


What do people think? I thought we'd talked about this mechanism at 
devcon?


Dan

On Sat, Jul 20, 2019 at 2:39 PM Dan Jenkins > wrote:


Just  going to chime in and say I don't see a one way audio
solution as enough and I'd worry that doing that would lead to "oh
but only so many people need to chuck audio in". This has been
discussed at at least 3 devcons now.

On Thu, Jul 18, 2019 at 2:09 PM Seán C. McCord mailto:ule...@gmail.com>> wrote:

I certainly don't mind if a better-designed system comes along
and obviates my AudioSocket implementation.  I built it
because I needed it. However, bidirectional audio flow is
critical for me (speech synthesis, external interfacing,
real-time processed audio, processed injections, etc).  While
I would actually prefer a system which was a bit beefier than
my own (simple protocol aside, there's a good deal of range
between my protocol and MRCP), my meagre C skills (and
patience) don't allow me to venture forth into those difficult
waters.

I do like the separate connection (unlike Wazo's) and the
support of TLS (unlike mine)... and yours is certainly (even
without looking) more performant. Mine also probably needs a
multi-threaded, dedicated-receiver approach like most of the
other channels which handle socket-received media, rather than
the simple non-blocking I/O with null frame insertion.  No
perfect solution yet.



On Thu, Jul 18, 2019 at 8:01 AM George Joseph
mailto:gjos...@digium.com>> wrote:

Hey Guys,

I was on vacation when this thread happened but I'm also
working on this now.  The implementation uses the existing
ARI channel and bridge recording endpoints ands add the
ability to specify a URI in the form of
(udp|tcp|tls)://hostname:port to stream the media.  This
makes use of the existing chan_bridge_media driver and
only requires a scheme handler similar to Seán's
res_audiosocket.  This implementation is more targeted to
real-time speech recognition/transcription/captioning and
is therefore one way (outbound).  A future enhancement is
planned that would send each channel in a bridge as a
separate audio channel in a multi-channel container.

I'm not suggesting that this should replace Seán's
audiosocket stuff but I did want to let you know what was
in the pipeline.

george

On Fri, Jul 5, 2019 at 7:38 AM Seán C. McCord
mailto:ule...@gmail.com>> wrote:

Solutions such as Jack are non-network oriented and
severely limited in scalability.  There are, of
course, many other options, but the closest are
chan_rtp and chan_nbs.  RTP is a good option except
for the difficulty for non-telephony people to
interact with it.  NBS is deprecated, undocumented,
and unsupported by any locatable resources.

While the original app interface from last year
required dialplan, the channel interface does not.  It
is a plain channel which can be used by ARI directly.


On Fri, Jul 5, 2019, 15:28 Sylvain Boily
mailto:sylv...@wazo.io>> wrote:

Hello Seán,

On 2019-07-05 4:45 a.m., Seán C. McCord wrote:

A brief update:

I have adapted my app_audiosocket from last year
to become chan_audiosocket, a full bidirectional
audio channel interface for Asterisk to any
AudioSocket service (which itself is a
  

[asterisk-dev] Manipulating Connected Line with ARI

[Jean Aunis]

Hello,

I was wondering if there was some work ongoing concerning the 
manipulation of Connected Line and Redirecting information in Stasis 
applications.


At the moment, it is possible to alter this information with the 
appropriate dialplan functions, and the events can also be intercepted 
with dialplan subroutines. But as far as I know, there is no direct way 
to do this in with a Stasis application.


Currently, the only way to do this is to use the dialplan interception 
routines, which call a Stasis application which then calls the 
CONNECTEDLINE or REDIRECTING functions via ARI. Although feasible, this 
is a quite complicated mechanism. I think doing the same thing purely 
with ARI, without the burden of writing dialplan, would be interesting.


Any thoughts on that ?

Regards,

Jean Aunis


--
_
-- 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 events order

[Jean Aunis]

Le 06/09/2018 à 16:18, Matthew Jordan a écrit :



On Wed, Sep 5, 2018 at 5:23 PM Seán C. McCord <mailto:ule...@gmail.com>> wrote:


As to the events should have a deterministic order or not, I
cannot speak, but this is definitely normal behaviour.


On Wed, Sep 5, 2018 at 12:22 PM Jean Aunis mailto:jean.au...@prescom.fr>> wrote:

Hello,

It looks like the ARI events ordering during channel
destruction is not deterministic. I noticed this for
ChannelLeftBridge and ChannelDestroyed events : given a
channel is in a bridge and is hanged up, sometimes
ChannelLeftBridge is raised before ChannelDestroyed, sometimes
it's the contrary. Test conditions are exactly the same in
both cases.

Is this non-deterministic behaviour normal, or should it be
considered as a bug ?

To my mind, ChannelDestroyed should always be the very last
event raised for a given channel. From a developper point of
view, it would give a clear indication that the resources
associated to the channel can be freed.

Regards

The events regarding a Channel entering and leaving a Bridge are 
deterministic with respect to the Bridge's lifetime, but are not 
deterministic with respect to the Channel's lifetime. While it's a bit 
different, this is discussed somewhat on the AMI specification page:



Thanks for the answer, I understand the problem. I'll live with it.

Regards

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

Astricon is coming up October 9-11!  Signup is available at: 
https://www.asterisk.org/community/astricon-user-conference

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

[asterisk-dev] ARI events order

[Jean Aunis]

Hello,

It looks like the ARI events ordering during channel destruction is not 
deterministic. I noticed this for ChannelLeftBridge and ChannelDestroyed 
events : given a channel is in a bridge and is hanged up, sometimes 
ChannelLeftBridge is raised before ChannelDestroyed, sometimes it's the 
contrary. Test conditions are exactly the same in both cases.


Is this non-deterministic behaviour normal, or should it be considered 
as a bug ?


To my mind, ChannelDestroyed should always be the very last event raised 
for a given channel. From a developper point of view, it would give a 
clear indication that the resources associated to the channel can be freed.


Regards

--


Jean AUNIS

Ingénieur R
R engineer

Tel : +33 1 30 85 90 22
Standard: +33 1 30 85 55 55


   Rue de Broglie
   22300 LANNION
   FRANCE
www.prescom.fr <http://www.prescom.fr/>

/"Les informations contenues dans ce courrier sont données à titre 
purement informatif et ne peuvent être considérées comme contractuelles 
entre les récipiendaires,
la société PRESCOM." //"The content of this e-mail is purely for 
information and may not be considered as contractual between the 
recipients, PRESCOM company."/


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

Astricon is coming up October 9-11!  Signup is available at: 
https://www.asterisk.org/community/astricon-user-conference

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

Re: [asterisk-dev] Regarding realtime audio streaming from mixmonitor

[Jean Aunis]

Le 06/07/2018 à 09:58, Mani Kanta Gadde a écrit :

Hi,
We are trying to stream audio coming from calls to an NLP engine to 
get the text transcription, for this we created a socket 
in_app_mixmonitor.c_ and we are writing audio frames to socket 
descriptor. We have tried with TCP(SOCK_STREAM) and UDP(SOCK_DGRAM) 
protocols to send the audio frames to the socket server.


We are using latest asterisk complied from GitHub source code 
(asterisk repo).


Here are some of the suggestions I found on asterisk forums
http://forums.asterisk.org/viewtopic.php?f=13=89365#p196720
on this thread, it was suggested to use CHANSPY, but we have edited 
mixmonitor code to both record and stream in realtime, which has 
sufficed our needs.


Here is the socket code we used inside the_mixmonitor_thread_function 
in app_mixmonitor.c file.






As suggested in the forum, it is probably easier to do this with the 
ChanSpy application, combined with a UnicastRTP channel.


Regards

Jean Aunis
-- 
_
-- 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] Unused channel tech ast_kill_tech ?

[Jean Aunis]

Hello,

Digging through Asterisk's code, I stumbled upon a strange channel 
technology called "ast_kill_tech" (take a look at channel.c / 
channel.h). There is a note stating it is used by Zombie channels, but 
actually it does not seem to be used at all, the technology is not even 
registered.


Am I missing something obvious, or could this piece of code be safely 
removed ?


Regards

--


Jean AUNIS

Ingénieur R
R engineer

Tel : +33 1 30 85 90 22
Standard: +33 1 30 85 55 55


   Rue de Broglie
   22300 LANNION
   FRANCE
www.prescom.fr <http://www.prescom.fr/>

/"Les informations contenues dans ce courrier sont données à titre 
purement informatif et ne peuvent être considérées comme contractuelles 
entre les récipiendaires,
la société PRESCOM." //"The content of this e-mail is purely for 
information and may not be considered as contractual between the 
recipients, PRESCOM company."/


-- 
_
-- 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 a call preemption feature

[Jean Aunis]

Le 15/11/2017 à 22:47, Joshua Colp a écrit :

On Wed, Nov 15, 2017, at 05:45 PM, Jean Aunis wrote:

Le 13/11/2017 à 23:17, Phil Mickelson a écrit :

Jean,

You should know that I wrote something very similar to what you are
asking for.  Slightly different reasons and I use ARI which makes it
very easy.  However, the result is the same. The inbound call gets
terminated.


I also considered the ARI option, but it does not fit my needs because
channels go through several ARI applications, and may eventually go back
to the dialplan, so it will not be possible to shut them down with ARI.

The DELETE operation in ARI on a channel works on any channel, including
those not in ARI.

Great, I was not aware. I will see what I can do with this. Thanks for 
the hint !


--
_
-- 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 a call preemption feature

[Jean Aunis]

Le 13/11/2017 à 23:17, Phil Mickelson a écrit :

Jean,

You should know that I wrote something very similar to what you are 
asking for.  Slightly different reasons and I use ARI which makes it 
very easy.  However, the result is the same. The inbound call gets 
terminated.


I also considered the ARI option, but it does not fit my needs because 
channels go through several ARI applications, and may eventually go back 
to the dialplan, so it will not be possible to shut them down with ARI.


--
_
-- 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 a call preemption feature

[Jean Aunis]

Le 13/11/2017 à 17:58, Steve Edwards a écrit :

On Mon, 13 Nov 2017, James Finstrom wrote:

Generally the idea of arbitrarily killing calls seems awful, even if 
the behavior is expected. Yeah so john we need to . RING 
John is confused, your brain has to reset because whatever was 
happening no longer matters.


At least play a message like "The boss needs to call his 
mom/bookie/hooker. Thank you for understanding, your call just wasn't 
important enough. Better luck next time -- and have a great day."




Thank you for your remarks. The fact is, it is not a question of user 
experience. We are working on critical communication networks, in which 
network resources are limited. Hanging up a low priority call to leave 
room to another is not an option, it is an absolute necessity, and it 
must be done in near real-time. We cannot afford to play any announcement.


By the way, I think call preemption is a native feature of ISDN networks 
(at least it's my understanding of the MLPP stuff, but I'm not a ISDN 
expert). But it is probably not used very often.
-- 
_
-- 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] Adding a call preemption feature

[Jean Aunis]

Hello,

As I highlighted recently on the asterisk-users list 
(http://lists.digium.com/pipermail/asterisk-users/2017-November/292079.html), 
there is no native way in Asterisk to implement call preemption. By call 
preemption, I mean the following :


- given calls have a priority, which may be notified by the network (see 
the SIP header Priority for instance), or which may be set by another way


- given the number of calls to or from a given peer is limited

- when this limit is reached, and an additional call comes in with a 
higher priority than previous ones, one of these calls should be hanged 
up to leave room to the new call.


At the moment, it is possible to limit the number of calls to a peer 
using the GROUP/GROUP_COUNT functions. It is also possible to list all 
channels in Asterisk and choose one to hangup in an AGI script, but 
there is no way to list channels in a particular group. And there is no 
concept of priority attached to a channel.


Therefore, I plan to add a new dialplan application which would preempt 
a channel in a particular group, below a given priority. It would be 
used this way : ChannelPreempt(mygroup,5) where "mygroup" is the group 
in which to look for a channel to hangup, and "5" is the priority below 
which the channel must by chosen. The application would return the 
preemption status and the preempted channel in channel variables.


I would like to have your opinions about the best way to implement this. 
Here are my thoughts so far:


1- add a "priority" field to the channel structure

2- allow the CHANNEL function to read and write this field

3- inside the new ChannelPreempt application:

    - loop through the group list, and find the channel in the given 
group with the lowest priority


    - if this priority is lower than the provided one, hangup the 
selected channel with ast_softhangup


    - otherwise, do nothing

    - set the following dialplan variables on completion:

        * PREEMPTION_STATUS: "SUCCESS" if we found a channel to hang 
up, "FAILURE" otherwise


        * PREEMPTED_CHANNEL: the name of the channel that was hanged up 
in case of success, empty otherwise


By the way, would this feature have a chance to be merged upstream ?

Regards

Jean Aunis


--
_
-- 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 an audio format in Asterisk

[Jean Aunis]

Le 24/03/2017 à 23:01, Matt Fredrickson a écrit :

On Fri, Mar 24, 2017 at 7:43 AM, Jean Aunis <jean.au...@prescom.fr> wrote:

Hello,

I need to add support for a new audio format in Asterisk. It will be
actually a very limited support : I just need to take the audio from one
side and transmit it to the other side. No decoding / transcoding will be
involved. One side will be a DAHDI endpoint, the other one a SIP endpoint.

What's the new audio format, if you don't mind me asking? (/me wonders
if it's CLEARMODE)
As far as I know it will be a home-made codec which I know nothing 
about. But it's a good thing you mentioned CLEARMODE : I had not heard 
about it before, but it seems perfectly fit for what I'm trying to achieve.

So maybe I will implement this by adding support for CLEARMODE.

Let's put aside for the moment the modifications which may have to be done
on the channels drivers to handle the codec negotiation. If I focus on
Asterisk's core and RTP handling, it seems I could achieve this simply by
registering a new format in codec_builtin.c. Two questions then :

- firstly, is this really the only thing to do, or am I missing something ?

I forget every time I've had to do this, and end up relearning it
every time.  Here are some other places that you'll need to modify:

main/rtp_engine.c: Some work here to work with SDP based protocols, like SIP.
include/asterisk/format_cache.h: To declare the new format in a header file.
main/format_cache.c: Also need to define the format here.
channels/chan_dahdi.c: It needs modified for support for any new
codecs that it needs to work with.
Thank you for these points. I originally thought that adding a new line 
"CODEC_REGISTER_AND_CACHE" would magically do everything required, but 
now I see there is some more work to do. Still, it seems to remain quite 
easy.



- secondly, is there a more "pluggable" way to do this ? Maybe with a shared
object which would be loaded on startup ?

Good question.  I don't think that there's a great way to add a
completely new codec (not previously described in Asterisk at all)
without patching Asterisk.  Perhaps Josh Colp or Kevin Harwell can
correct me if I'm wrong :-)




--
_
-- 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] Adding an audio format in Asterisk

[Jean Aunis]

Hello,

I need to add support for a new audio format in Asterisk. It will be 
actually a very limited support : I just need to take the audio from one 
side and transmit it to the other side. No decoding / transcoding will 
be involved. One side will be a DAHDI endpoint, the other one a SIP 
endpoint.


Let's put aside for the moment the modifications which may have to be 
done on the channels drivers to handle the codec negotiation. If I focus 
on Asterisk's core and RTP handling, it seems I could achieve this 
simply by registering a new format in codec_builtin.c. Two questions then :


- firstly, is this really the only thing to do, or am I missing something ?

- secondly, is there a more "pluggable" way to do this ? Maybe with a 
shared object which would be loaded on startup ?


Best regards

Jean Aunis


--
_
-- 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] Questions about Message/ast_msg_queue

[Jean Aunis]

Hello,

I am currently using a lot of SIP MESSAGEs, which rely on the 
Message/ast_msg_queue channel in Asterisk. Unless I misunderstood 
something, this channel is acting as a kind of "singleton" : there is 
only one instance of this channel, which processes one message after the 
other. This behaviour makes it more difficult to handle large amounts of 
messages, especially if the dialplan handling the messages takes a long 
time to execute.


So my questions are the following :

1- what is the reason for this "singleton" behaviour ? Why not creating 
one channel for each SIP message ?


2- is it technically possible (and even desirable) to change this 
behaviour ?


Best regards,

Jean Aunis


--
_
-- 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] Mistake in review 2520 (ChanSpy modification)

[Jean Aunis]

Hello,

I realize I did a mistake in the review 2520, which I submitted on 
gerrit and was merged last Friday.
I wanted to create the audiohook with AST_AUDIOHOOK_MUTE_WRITE if option 
'o' was set, but I did... the exact contrary.


This causes ChanSpy to listen only to the audio coming from the channel, 
when it should also listen to the audio coming into the channel.


Sorry for that, I did not test this case properly before. Should I 
submit a new patch on gerrit to fix it ?


Best regards

Jean Aunis

--
_
-- 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] Avoid audio loss in ChanSpy (ref: ASTERISK-25866)

[Jean Aunis]

Le 01/04/2016 18:33, Jean Aunis a écrit :

Le 01/04/2016 14:00, Joshua Colp a écrit :

I think this is fine, provided there is still some high ceiling 
value. Allowing a queue to potentially grow out of control would be bad.


I think if we were able to switch things to using a timer instead we 
could actually get rid of this synchronization. It exists because it 
has to bring together two directions and then provide the media.


I also don't see your review on gerrit. Java (yay Java!) ran out of 
memory somewhat overnight it seems and I've restarted gerrit this 
morning. That may have caused the review to not actually get 
submitted. If you do so again it should work fine and if not we can 
help figure out why.


Cheers,

I could add a constant AST_AUDIOHOOK_LONG_QUEUE set to 500 ms or 
another value, and flush the queues if they exceed this value, 
whatever the flags set on the audiohook.


By the way, shouldn't the audiohook be created with the flag 
AST_AUDIOHOOK_MUTE_WRITE if the option "o" is set ? It is not the case 
for the moment, and thus we are feeding the write factory with frames 
which will never be read.

I have just updated the review with these two modifications:
- setting AST_AUDIOHOOK_MUTE_WRITE if required
- checking against a constant AST_AUDIOHOOK_LONG_QUEUE in audiohook.c to 
prevent the queues from growing out of control


Best regards,

Jean Aunis

--
_
-- 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] Avoid audio loss in ChanSpy (ref: ASTERISK-25866)

[Jean Aunis]

Le 01/04/2016 14:00, Joshua Colp a écrit :

I think this is fine, provided there is still some high ceiling value. 
Allowing a queue to potentially grow out of control would be bad.


I think if we were able to switch things to using a timer instead we 
could actually get rid of this synchronization. It exists because it 
has to bring together two directions and then provide the media.


I also don't see your review on gerrit. Java (yay Java!) ran out of 
memory somewhat overnight it seems and I've restarted gerrit this 
morning. That may have caused the review to not actually get 
submitted. If you do so again it should work fine and if not we can 
help figure out why.


Cheers,

I could add a constant AST_AUDIOHOOK_LONG_QUEUE set to 500 ms or another 
value, and flush the queues if they exceed this value, whatever the 
flags set on the audiohook.


By the way, shouldn't the audiohook be created with the flag 
AST_AUDIOHOOK_MUTE_WRITE if the option "o" is set ? It is not the case 
for the moment, and thus we are feeding the write factory with frames 
which will never be read.


--
_
-- 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] Avoid audio loss in ChanSpy (ref: ASTERISK-25866)

[Jean Aunis]

Le 01/04/2016 14:00, Joshua Colp a écrit :

Jean Aunis wrote:

Hello,

As described in the issue ASTERISK-25866
<https://issues.asterisk.org/jira/browse/ASTERISK-25866>, it appears
that ChanSpy is randomly loosing audio frames, because it sets the flags
AST_AUDIOHOOK_TRIGGER_SYNC and AST_AUDIOHOOK_SMALL_QUEUE when creating
the audiohook: these option cause the audiohook's queue to be flushed of
"old" frames at very short intervals.

I have submitted a patch on gerrit which does two things :
1- do not set the flag AST_AUDIOHOOK_TRIGGER_SYNC if ChanSpy has been
called with the option "o": in this case we only listen to the audio
coming from this channel so this flag is useless
2- create a new option "l" which prevents the flag
AST_AUDIOHOOK_SMALL_QUEUE from being set. I find it better than just
removing the flag in all cases, because this may introduce some delay in
the audio, which may not be acceptable for many ChanSpy users.

What do you think of the idea ?


I think this is fine, provided there is still some high ceiling value. 
Allowing a queue to potentially grow out of control would be bad.


I think if we were able to switch things to using a timer instead we 
could actually get rid of this synchronization. It exists because it 
has to bring together two directions and then provide the media.


I also don't see your review on gerrit. Java (yay Java!) ran out of 
memory somewhat overnight it seems and I've restarted gerrit this 
morning. That may have caused the review to not actually get 
submitted. If you do so again it should work fine and if not we can 
help figure out why.


Cheers,

I just pushed again, but it seems the branch was not created. I used the 
following command (taken from the wiki):


git review -t ASTERISK-25866

And here is the output :

remote: Processing changes: new: 1, refs: 1, done
remote:
remote: New Changes:
remote:   https://gerrit.asterisk.org/2520 app_chanspy: reduce audio 
loss on the spying channel.

remote:
To ssh://presco...@gerrit.asterisk.org:29418/asterisk
 * [new branch]  HEAD -> refs/publish/master/ASTERISK-25866

Best regards

Jean Aunis
-- 
_
-- 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] Avoid audio loss in ChanSpy (ref: ASTERISK-25866)

[Jean Aunis]

Hello,

As described in the issue ASTERISK-25866 
<https://issues.asterisk.org/jira/browse/ASTERISK-25866>, it appears 
that ChanSpy is randomly loosing audio frames, because it sets the flags 
AST_AUDIOHOOK_TRIGGER_SYNC and AST_AUDIOHOOK_SMALL_QUEUE when creating 
the audiohook: these option cause the audiohook's queue to be flushed of 
"old" frames at very short intervals.


I have submitted a patch on gerrit which does two things :
1- do not set the flag AST_AUDIOHOOK_TRIGGER_SYNC if ChanSpy has been 
called with the option "o": in this case we only listen to the audio 
coming from this channel so this flag is useless
2- create a new option "l" which prevents the flag 
AST_AUDIOHOOK_SMALL_QUEUE from being set. I find it better than just 
removing the flag in all cases, because this may introduce some delay in 
the audio, which may not be acceptable for many ChanSpy users.


What do you think of the idea ?

Best regards,

Jean Aunis
-- 
_
-- 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