Stream voice to Asterisk

Roy Sigurd Karlsbakk wrote:
>>>> According to the Audiocodes engineer:
>>>>
>>>>> Unfortunately we're receiving back a
401 UNAUTHORIZED ... which  is a
>>>>> final response (4xx) <snip/>
>>>
>>>  From RFC3261 8.1.3.5:
>>>
>>>> If a 401 (Unauthorized) or 407 (Proxy
Authentication Required)
>>>> response is received, the UAC SHOULD follow
the authorization
>>>> procedures of Section 22.2 and Section 22.3
to retry the request  with
>>>> credentials.
>>
>>
>> And from RFC 3261 22.1:
>>
>>    A UAC MUST NOT re-attempt requests with the
credentials
>>    that have just been rejected (though the request
may be retried if
>>    the nonce was stale).
> 
> 
> But as stated just above that text, that is in the case
of a 403:
> 
>> ...In this instance a server may repeat its
challenge, or it may  
>> respond with a 403 Forbidden.  A UAC MUST NOT
re-attempt requests  
>> with the credentials that have just been rejected
(though the  request 
>> may be retried if the nonce was stale).
> 
> 
> A 401/407 is merely an answer meaning "hey! I need
to see your creds!"
> 

Correct, but you could end up in and endless loop of
REGISTER and 
401/407 responses if you re-attempt the REGISTER request
with the 
credentials that have just been rejected. Since the UAS can
choose 
between responding with 403 or repeat the challenge in a new
401/407 
response according to the section you quoted above.


Mikael
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

>>>>  From RFC3261 8.1.3.5:
>>>>
>>>>> If a 401 (Unauthorized) or 407 (Proxy
Authentication Required)
>>>>> response is received, the UAC SHOULD
follow the authorization
>>>>> procedures of Section 22.2 and Section
22.3 to retry the  
>>>>> request  with
>>>>> credentials.
>>>
>>>
>>> And from RFC 3261 22.1:
>>>
>>>    A UAC MUST NOT re-attempt requests with the
credentials
>>>    that have just been rejected (though the
request may be  
>>> retried if
>>>    the nonce was stale).
>> But as stated just above that text, that is in the
case of a 403:
>>> ...In this instance a server may repeat its
challenge, or it may   
>>> respond with a 403 Forbidden.  A UAC MUST NOT
re-attempt  
>>> requests  with the credentials that have just
been rejected  
>>> (though the  request may be retried if the
nonce was stale).
>> A 401/407 is merely an answer meaning "hey! I
need to see your  
>> creds!"
>
> Correct, but you could end up in and endless loop of
REGISTER and  
> 401/407 responses if you re-attempt the REGISTER
request with the  
> credentials that have just been rejected. Since the UAS
can choose  
> between responding with 403 or repeat the challenge in
a new  
> 401/407 response according to the section you quoted
above.

A 403 should not initiate a new attempt, but a 40[17]
should. Could  
it be a wrong password causing this? Or perhaps a wrong
nonce?Have  
you tried a different client to see if it's client
dependent? If you  
still, after going through these tests, beleive it's a bug,
please  
file it on bugs.digium.com

roy
---
"Humans mostly aren't particularly evil. They just get
carried away  
by new ideas, like dressing up in jackboots and shooting
people, or  
dressing up in white sheets and lynching people, or dressing
up in  
tie-dye jeans and playing guitars at people"
  - Terry Pratchett
-------------------------------
Roy Sigurd Karlsbakk
roykarlsbakk.net



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

>>> int to2 = DEFAULT_FREQ_OK + thread_safe_rand()
% 8000 - 40000;
>>> peer->pokeexpire = ast_sched_add(sched, to2,
sip_poke_peer_s, peer);
>>
>> Shouldn't that be 4000 (so you vary +/- 4000 from
the DEFAULT_FREQ_OK),
>> rather than 40000?

Yes, that should be 4000, typo on my behalf, thanks.

> Perhaps if this became an option that these numbers
would be settable
> from within sip.conf? I always get a vague feeling of
unease when I
> see numbers like timers hardcoded into chan_sip...
>
> JT

Agreed, this was just my code to test proof-of-concept. In
terms of a
variable, you could then write:

int to2 = DEFAULT_FREQ_OK + rand() % poke_rand_drift_ms -
poke_rand_drift_ms/2;

Also if you didn't set that number explicitly in sip.conf,
you could
express it as a percentage, e.g. to2=DEFAULT_FREQ_OK +/- x%.
Where 'x'
can be specified in sip.conf, and defaults to 0.


--Ryan

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

>>>>> "JT" == John Todd
<jtoddloligo.com> writes:

JT> Perhaps if this became an option that these numbers
would be
JT> settable from within sip.conf? I always get a vague
feeling of
JT> unease when I see numbers like timers hardcoded into
chan_sip...

Tunables are a problem, everyone gets them wrong. IMHO this
issue is
being fixed in a way too heavy-handed way. Trying to reduce
CPU load
by adding rand() (not a fast function) and a modulo is a bit
odd.


/Benny


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

F. Mitchell Felling II wrote:
> I have a need to not only launch, but control
app_dictate from the
> Asterisk Management Interface.  I expected this to be
rather simple by
> using the playdtmf action.  However, it seems the DTMF
is only played to
> the channel (extension) not to the instance of the
dictation app.
> 
> Any thoughts on how I could get the dtmf signals sent
to the instance of
> the app for control purposes?

You can't 'launch' app_dictate from the Manager interface at
all,
although you can create a channel that is talking to it. The
problem you
are having is that you need _another_ channel that is
bridged to the
first one to send DTMF actions on.

However, where is the audio going to come from if you do
this?
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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

>F. Mitchell Felling II wrote:
>>  I have a need to not only launch, but control
app_dictate from the
>>  Asterisk Management Interface.  I expected this to
be rather simple by
>>  using the playdtmf action.  However, it seems the
DTMF is only played to
>>  the channel (extension) not to the instance of the
dictation app.
>>
>>  Any thoughts on how I could get the dtmf signals
sent to the instance of
>>  the app for control purposes?
>
>You can't 'launch' app_dictate from the Manager
interface at all,
>although you can create a channel that is talking to it.
The problem you
>are having is that you need _another_ channel that is
bridged to the
>first one to send DTMF actions on.
>
>However, where is the audio going to come from if you do
this?

I have modified app_dictate to accept a filename and path of
an mp3 
instead of raw, and to allow control to include skip
forward, 
backward, and skip to start.  In reality I have changed it
to more 
closely mimic controlPlayback, but with playback speed
control.

The solution currently has us delivering the playback to an
extension 
on an Avaya G3R.  The Avaya extensions are controlled by
Genesys CTI, 
and we are sending DTMF using the Genesys functions for the
Avaya. 
However, this is a very crude solution, requiring the
desktop control 
app to include both the AMI connections and Genesys T-Server

connections.  Additionally, when a user controls the
playback, they 
hear the DTMF.

Ultimately I will probably build a way to control our
modified 
app_dictate directly without DTMF.  However, none of the
immediately 
obvious solutions seem attractive.

-- 
F. Mitchell Felling II
mitchfellingfamily.com
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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