Re: [asterisk-dev] Dundi library

[Klaus Darilion]

Thanks for the feedback. Corey, thanks for the work on the library.

Meanwhile I implemented the workaround: let Kamailio forward the request 
to an Asterisk server which does the lookup and responds with a 302 
redirect to (Transfer()) the proper Asterisk server.


Using SIP for the query has the advantage that the query is handled 
asynchronous inside Kamailio. For INVITEs it is quite easy (as they are 
handled in the Asterisk dialplan of the Asterisk server which does the 
DUNDI query). But it was a bit more complicated than expected as I also 
have to do the lookups also for REGISTERs, SUBSCRIBE  Therefore I 
implemented a "hack" in Kamailio, faking another INVITE transaction 
while putting the original transcation on hold. (yes there are plenty of 
hacks you can do in Kamailio).


Basically it works but I have not tested it in detail. If you are 
interested take a look at the Kamailio config below.


regards
Klaus


dundi.host = "1.2.3.4:5060" desc "Asterisk which performs the DUNDI 
query. Host:Port"
dundi.deftarget = "2.3.4.5:5160" desc "Default Asterisk server if DUNDI 
lookup failed. Host:Port"



route[RELAY_TO_DUNDI] {
$var(dundicache) = $sht(dundicache=>$tU);
if( $var(dundicache) == 0) {
xlogl("L_INFO","$tU not found in cache, quering 
Dundi-Asterisk for DUNDI lookup...");

if(t_suspend()) {
# build a new transaction, use From and To URI 
to store

# the transaction identifiers
xlogl("L_INFO","transaction suspended 
[$T(id_index):$T(id_label)]\n");

$uac_req(method)="INVITE";
$uac_req(ruri)="sip:" + $tU + "@" + 
$sel(cfg_get.dundi.host);

$uac_req(furi)="sip:" + $T(id_index) + "@proxy";
$uac_req(turi)="sip:" + $T(id_label) + "@proxy";
$uac_req(callid)=$(mb{s.md5});
uac_req_send();
exit;
} else {
xlogl("L_ERR","Failed to suspend transaction 
... 500");

send_reply("500","Failed to suspend transaction");
exit;
}
} else if( $var(dundicache) == "unknown" ) {
xlogl("L_INFO","$tU found in cache but unknown, sending 
to $(sel(cfg_get.dundi.deftarget))");

$du="sip:" + $sel(cfg_get.dundi.deftarget);
} else {
xlogl("L_INFO","$tU found in cache, sending to 
$var(dundicache)");

$du="sip:" + $var(dundicache);
}
add_contact_alias();

if (!t_relay()) {
sl_reply_error();
}
exit;
}


event_route [tm:local-request] {
# Handle locally generated requests
xlogl("L_INFO", "local-request: Routing locally generated $rm 
to <$ru>:");

t_on_reply("REPLY_DUNDI");
# 2 seconds prober timeout
t_set_fr(0, 2000);
}
onreply_route[REPLY_DUNDI] {
xlogl("L_INFO","REPLY_DUNDI: response received from $si:");

$var(index) = $(fU{s.int});
$var(label) = $(tU{s.int});
if (t_check_status("3[0-9][0-9]")) {
# this reply route is only executed for DUNDI 
responses, thus, no need to check the source

$var(target)= @msg.header.Contact[0].nameaddr.uri.host;
xlogl("L_INFO","REPLY_DUNDI: Tindex=$var(index), 
Tlabel=$var(label), target=$var(target)");

$sht(dundicache=>$fU:$tU)=$var(target);
t_continue("$var(index)", "$var(label)", "AFTER_DUNDI");
} else {
xlogl("L_ERR", "Unexpected response from Dundi server");
t_continue("$var(index)", "$var(label)", "AFTER_DUNDI");
}

}

route[AFTER_DUNDI] {
xlogl("L_INFO","AFTER_DUNDI: transaction 
$T(id_index):$T(id_label) continues ");

$var(target) = $sht(dundicache=>$T(id_index):$T(id_label));
if ($(var(target){s.len}) > 1) {
$du = "sip:" + $var(target);
$ru = $ou;
xlogl("L_INFO", "Got redirect from Dundi server, target 
is $ru, sending to $du");

$sht(dundicache=>$tU)=$var(target);
r_relay();
exit;
} else {
xlogl("L_ERROR","AFTER_DUNDI: no target found ... using 
default");

$du="sip:" + $sel(cfg_get.dundi.deftarget);
$ru = $ou;
$sht(dundicache=>$tU)="unknown";
r_relay();
exit;
}
exit;
}






--
_
-- 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] Dundi library

[Klaus Darilion]

Hi!

I have an Asterisk cluster and use Dundi for the internal routing. Now I 
want to query Dundi also from other systems, e.g. a Kamailio proxy. I 
thought there will be a Dundi library which can be used, but my web 
search didn't find any. I also checked Dundi in Asterisk and it seems 
that Dundi can not easily extracted.


Is anybody aware of some Dundi library or tool that can be integrated 
into other systems?


Thanks
Klaus

PS: My plan B would be to forward a SIP request to one of the Asterisk 
boxes, there perform the Dundi lookup and user Transfer() to signal the 
result back in a 302 SIP response.


--
_
-- 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] introduce a codec

[Klaus Darilion]

no.

Just take a look at one of the existing codecs.

klaus

[EMAIL PROTECTED] schrieb:
> Hello,
> 
> i have another problem (sorry but i'm totally lost): do i need sockets to
> pass the information through the codec to asterisk???
> thank you very much
> 
> 
> ___
> --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] Introduce a codec

[Klaus Darilion]

I also suggest to just "grep" the source code for another codec, e.g.
"grep -r -i gsm"

Then you see were you have to define the codec and how to add certain 
codec related functions.

regards
klaus

Moises Silva schrieb:
> You have a lot of examples in the codecs/ directory of Asterisk.
> Basically you just need to implement the codec interface specified in
> the struct ast_translator. Red the comments in
> include/asterisk/translate.h
> 
> Regards,
> 
> Moisés Silva
> 
> On Feb 6, 2008 7:01 AM,  <[EMAIL PROTECTED]> wrote:
>> hello,
>> i have a problem: i need to introduce an audio codec in asterisk and i
>> don't know how to do it!
>> the codec is MELP. can you help me?
>>
>>
>> ___
>> --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] Asterisk mishandling user busy isdn releases

[Klaus Darilion]

I would try this:

exten => 123,1,Dial(.)
exten => 123,2,Gotoif($["${DIALSTATUS}" == "BUSY"]?3:4)
exten => 123,3,Busy()
exten => 123,4,Hangup()

regards
klaus


Ken Leland III schrieb:
>  > > Hello All,
>  > > I have found that Asterisk does not play a busy tone when it 
> receives a
>  > > USER BUSY ISDN RELEASE messages following an ISDN CONNECT message.
>  > >
>  > > Details:
>  > > We are connecting our Asterisk PBX to a Lucent telephone switch via 
> ISDN
>  > > PRIs.  The telephone switch provides an authorization code feature 
> where
>  > >   every call originated from asterisk is immediately answered by the
>  > > telephone switch, and prompted for an authorization code, before
>  > > completing the call.  The sip phone registered with Asterisk dials 
> a 10
>  > > digit number, hears the prompt, and dials a 4-digit code.  The 
> telephone
>  > > switch authenticates the code and attempts to complete the call. 
> In the
>  > > event that the far end is available the telephone switch passes the
>  > > ringing tones inband over the pri.  In the event that the far end is
>  > > busy,  the telephone switch sends an ISDN RELEASE message with the
>  > > cause: USERBUSY.  Asterisk receives the RELEASE message and sends a 
> BYE
>  > > message to the sip phone and a RELEASE COMPLETE back to the switch. 
> This
>  > > does NOT result in the user hearing a busy signal.  Instead, the user
>  > > hears a click and dead air as if they were hung up on.
>  > >
>  > > Questions:
>  > > Is there a way to configure this behavior in the dial plan?
> 
>  > You can check DIALSTATUS after Dial() and play Busy() if the DIALSTATUS
>  > is busy.
>  > klaus
> Thanks klaus,  I gave this a try, with no luck, using the following 
> hangup extensions:
> 
> exten => h,1,Gotoif($[${HANGUPCAUSE} = 17]?BUSY:HANGUP)
> exten => h,n(BUSY),Playtones(busy)
> exten => h,n(HANGUP),Hangup
> 
> Here is some partial console output + SIP debug:
> 
> -- Executing [EMAIL PROTECTED]:1] GotoIf("SIP/testuser-10685f60", 
> "1?BUSY:HANGUP") 
> in new stack
> -- Goto (test,h,2)
> -- Executing [EMAIL PROTECTED]:2] PlayTones("SIP/testuser-10685f60", "busy") 
> in 
> new stack
> -- Executing [EMAIL PROTECTED]:3] Hangup("SIP/testuser-10685f60", "") in new 
> stack
> -- Asterisk sends SIP BYE message.
> 
> It seems whatever attempts i made at adding audio in the special 'h' 
> hangup extension would fail.  As you can see the PlayTones("busy") is 
> happening before the SIP BYE message but it still doesn't make it to the 
> audio stream.  Does the Dial cmd tear down the rtp session before 
> returning?  Did you mean for me to check the DIALSTATUS in the special 
> hangup extension or somewhere else?
> 
>  > >
>  > > If not does anyone think that adding the following logic to Asterisk
>  > > would be a useful patch?
>  > >
>  > > If a zap channel is bridged with a sip channel, and the zap channel
>  > > receives a user busy RELEASE, play a busy tone inband on the sip 
> channel.
>  > >
>  > > Cheers,
> -
> Ken W. Leland  III
> Engineering
> [EMAIL PROTECTED]
> Monmouth Telecom
> 10 Drs. James Parker Blvd., Suite 110
> Red Bank, NJ  07701
> 732-704-1000  X283
> 
> ___
> --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] q931 decoding question

[Klaus Darilion]

Matthew Fredrickson schrieb:
> Klaus Darilion wrote:
  Ext: 0  User information layer 1: Unknown (24)
>>
>> My questions: Why does it gets parsed? Why is it set to 24? I checked 
>> libpri source code but could not find the relevant code. Maybe someone 
>> can point to the corresponding code.
> 
> This looks like a bug in the Q.931 dumping code.  After I looked into 
> it, I saw that an oversight was made in the bearer_capability_dump 
> routine that is assume a length that doesn't include the IE name and 
> length in the length passed to it.  The bug was not present in the 
> bearer_capability_transmit routine, but on the off chance there might be 
> something like this elsewhere, I saw something similar in the _receive 
> routine and fixed it as well.  The bug in the receive routine appears to 
> be benign because of the way we're using it in Asterisk.  Please update 
> to latest 1.2, 1.4, or trunk from svn to see if it is fixed now.
> 

Ok. So how is it handled now if UL1 it is not present?

Do you know if there is a difference in Q.931 between missing octets and 
values set to zero? E.g. is there a difference between UL1 set to zero 
or a missing UL1 octet?

Btw - there is also a new patch on mantis for proper decoding:
http://bugs.digium.com/view.php?id=11593


regards
klaus

___
--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] dialog matching

[Klaus Darilion]

Hi Steve!

pedantic in Asterisk is buggy - regardless if it is turned on or off.

Thus, please do not just reimplement the old behavior but fix it.

AFAIK pedantic controls 2 things:
  1. accept short header names and header which are wrapped around 
multiple lines if pedantic=on
  2. use to-tag for dialog matching if pedantic=on.

IMO part 2 should be removed from pedantic setting and dialog matching 
should be done standard conform.

Current problems with dialog matching with pedantic=off: Asterisk 
accepts an to-tag. Thus for example a reINVITe will cause a new call if 
Asterisk can not find an existing call -> bad security

Current problems with dialog matching with pedantic=on: Asterisk learns 
the totag from the first provisional response and ignores responses with 
different to-tag although they belong to the same transaction -> causes 
problems if the outgoing SIP call is forked and causes multiple 
early-dialog.

The fix would be to always use RFC conform dialog matching - meaning 
call-id/fromtag/totag for indialog requests and accept multiple 
provisional responses (I know asterisk can not handle multiple early 
dialogs but a reasonable workaround would be to learn the totag only 
from the final response, not from the provisional response and treat all 
early dialog as one early dialog).

regards
klaus




Steve Murphy schrieb:
> Olle--
> 
> I thought to double check with you... the price of missing something is 
> pretty high.
> 
> Put on your thinking cap, pull out some paper and a pencil, turn off the 
> cell phone... this is going to require
> some thought!
> 
> 
> For reference, here's the search loop in find_call:
> 
> 
> dialoglist_lock();
> for (p = dialoglist; p; p = p->next) {
> /* In pedantic, we do not want packets with bad syntax 
> to be connected to a PVT */
> int found = FALSE;
> if (ast_strlen_zero(p->callid))
> continue;
> if (req->method == SIP_REGISTER)
> found = (!strcmp(p->callid, callid));
> else
> found = (!strcmp(p->callid, callid) &&
>(!pedanticsipchecking || !tag || 
> ast_strlen_zero(p->theirtag) || !strcmp(p->theirtag, tag))) ;
> 
> ast_debug(5, "= %s Their Call ID: %s Their Tag %s Our 
> tag: %s\n",
>  found ? &qu ot;Found" : 
> "No match", p->callid, p->theirtag, p->tag);
> 
> /* If we get a new request within an existing to-tag - 
> check the to tag as well */
> if (pedanticsipchecking && found  && req->method != 
> SIP_RESPONSE) { /* SIP Request */
> if (p->tag[0] == '\0' && totag[0]) {
> /* We have no to tag, but they have. 
> Wrong dialog */
> found = FALSE;
> } else if (totag[0]) {  /* Both 
> have tags, compare them */
> if (strcmp(totag, p->tag)) {
> found = FALSE;  /* This 
> is not our packet */
> }
> }
> if (!found)
> ast_debug(5, "= Being pedantic: This ... 
> request: Call ID: %s Ourtag  Totag %s Method %s\n",
>p->callid, totag, 
> sip_methods[req->method].text);
> }
> 
> 
> if (found) {
> /* Found the call */
> sip_pvt_lock(p);
> dialoglist_unlock();
> return p;
> }
> }
> dialoglist_unlock();
> 
> The object: remove the loop, and replace it with astobj2 hash table lookups.
> 
> I checked Luigi's astobj2 branch, where he put dialogs in a table, but 
> he implements the above as a linear traversal, which is not my goal. I 
> want to improve performance, not just convert the code to be astobj2 
> based...
> 
> There seem to be two main modes: with pedanticsipchecking ON, and 
> pedanticsipchecking OFF.
> 
> 
> 
> 
> Things are simple in OFF mode:
> 
> fundamentally, whether req->method is SIP_REGISTER or not, found is true 
> when a dialog's callid matches.
> No code after setting found could disqualify this choice.
> 
> 
> 
> 
> 
> Things get more complex in pedanticsipchecking ON mode:
> 
> It seems split into whether req->method is SIP_REGISTER/SIP_RESPONSE  or 
> not:
> 
> If req->method is SIP_REGISTER:
> 
>if match(p->callid,callid)  AND (!totag[0] ||  (p->tag[0] && 
> match(p->tag,totag))
> 
> else
> 
> If req->method is SIP_RESPONSE:
> 
> If callid matches AND ( empty(p->theirtag)  || 

Re: [asterisk-dev] Kill the user, kill the user!

[Klaus Darilion]

Johansson Olle E wrote:
> 7 dec 2007 kl. 17.45 skrev Igor A. Goncharovsky:
> 
>> Hi!
>>
>> Johansson Olle E wrote:
>>> Incoming calls are handled this way
>>>
>>> * First, we match on peer object name with the From username
>>> * Then we try to match on IP/Port
>>> * If we can't match, we send to the context defined in the "general"
>>> section in sip.conf or to "default".
>>>
>>> If you can find any way this may give you problems, please inform me
>>> now. Otherwise, I'm going
>>> to test this branch with all of you. I don't foresee any problems
>>> going ahead with this in trunk.
>>>
>>> Feedback is appreciated!
>>>
>> Should it solve my problems with incoming calls from my telco. I have
>> registered many lines on single SBC then incoming call have the same  
>> IP
>> and port. Difference only in To: user name. Incoming INVITE have not
>> auth, but when we send final BYE we have problem with auth name,  
>> because
>> it is wrong selected on initial INVITE. Can also peer search able by  
>> To
>> field?
> 
> Well, that is a different thing. After I've removed the user, my plan
> was to add "service" and "trunk".

What if Asterisk uses a dedicated Contact URI when registering to the 
service provider. Then, incoming requests can be distinguished based on 
the RURI. (this is what eyebeam and SNOM does by adding an instance/line 
parameter to the contact URI).

Thus:
1. check RURI if it matches an existing registration (optionally verfiy 
if requests comes from the specified IP address as additionally security 
check)

2. check From URI. If the domain correlates with the local configured 
domains then challenge the user (realm=domain) (old user behavior)

3. check source IP (optional port) (old peer behavior). Optional do 
authentication

4. use default context


regards
klaus



___
--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] Kill the user, kill the user!

[Klaus Darilion]

Ryan Mitchell wrote:
> 
> To raise an issue that's come up a few times before, instead of checking 
> user then ip/port, why not check ip/port first then user?

I think this will cause trouble if you have multiple "ex-users" pointing 
to the same ip:port. Checking ip:port first this will always resolve to 
the "peer" instead to the "users".

klaus

___
--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] ast_frame allocation/free question

[Klaus Darilion]

Sergio Garcia Murillo schrieb:
> From: Klaus Darilion [mailto:[EMAIL PROTECTED]
>> Sergio Garcia Murillo wrote:
>>> From: "Simon Perreault" <[EMAIL PROTECTED]>
>>>> Either I'm getting it all wrong, or I have an even bigger problem than I
>>> first
>>>> thought. And my code is largely inspired from Sergio's on
>>> sip.fontventa.com
>>>> so we'd be two. ;)
>>>>
>>> I've changed all my allocations to be static, so I just avoided the issue...
>> Are static buffers thread safe?
> 
> From previous answers I assume that within an application the frame is only 
> acceses while the ast_write is executed. So it would be safe to do something
> like that:
> 
> struct ast_frame *f = (struct ast_frame*)malloc(sizeof(ast_frame));
> ast_write(f);
> free(f)
> 
> In that case that 
> 
> unsigned char aux[sizeof(ast_frame)];
> struct ast_frame *f = (struct ast_frame*)aux;
> ast_write(aux);
> 
> would be equally thread safe.

True, but I thought it is a "static" buffer, like:
static unsigned char aux[sizeof(ast_frame)]; ?

regards
klaus



>  If asterisk would like to make anything weird with the frame (like some kind 
> of
> jitter buffering or delay sending) it should duplicate the whole frame and 
> take
> care of the clone.
> 
> Best regards
> Sergio
> 
> 
> 
> 
> 
> ___
> --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] New branch: calleridutf8

[Klaus Darilion]

Olle E Johansson schrieb:
> 26 nov 2007 kl. 11.14 skrev Klaus Darilion:
> 
>> Johansson Olle E schrieb:
>>
>>> Feedback, ideas and suggestions is always welcome.
>> If you ever need to enter characters on Windows using UTF-8 I can
>> recommend http://www.fileformat.info/tool/unicodeinput/index.htm
>>
>> (e.g. you want to test if you SIP client can handle Czech háček and  
>> you
>> have no glue how you can enter this on your keyboard).
> I have glue :-) 

Monday morning  ;-)

___
--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] New branch: calleridutf8

[Klaus Darilion]

Johansson Olle E schrieb:

> Feedback, ideas and suggestions is always welcome.

If you ever need to enter characters on Windows using UTF-8 I can 
recommend http://www.fileformat.info/tool/unicodeinput/index.htm

(e.g. you want to test if you SIP client can handle Czech háček and you 
have no glue how you can enter this on your keyboard).

regards
klaus

___
--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] why 4 UDP ports per SIP call?

[Klaus Darilion]

Johansson Olle E schrieb:
> 22 nov 2007 kl. 10.29 skrev Klaus Darilion:
> 
>>
>> Olle E Johansson wrote:
>>> 19 nov 2007 kl. 20.53 skrev Klaus Darilion:
>>>
>>>> Hi!
>>>>
>>>> Analyzing Asterisk I see 4 new UPD sockets opened by Asterisk per
>>>> incoming SIP call. I would assume RTP+RTCP=2, but why are there 4
>>>> ports
>>>> opened?
>>> Have you enabled video at all?
>> I have video enabled in Asterisk, but the INVITE sent to Asterisk  
>> had no
>> video description in the SDP. Will Asterisk open the video RTP ports
>> also if the incoming INVITE does not offer video?
> 
> Well, *embarrassing smile*, yes. Hrrm.
> 
> Due to the interesting architecture of the SIP channel, we open all  
> those ports
> for every call, but should close them after the initial INVITE/200 OK/ 
> ACK if I
> remember correctly, or sooner if the actual device doesn't support  
> video.


I am using Asterisk SVN-branch-1.4-r75450M with videosupport=yes.

The incoming INVITE does not include video in the SDP. Also the 200 OK 
from Asterisk does not include video in the SDP. Asterisk opens 4 new 
UDP ports which will be opened for the whole call duration.

Is there a method to find out if the 2 additional ports are really the 
video RT(C)P ports or if they belong to something else?

regards
klaus

___
--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] any experience building asterisk under windows ?

[Klaus Darilion]

Dinesh Nair schrieb:
> On Wed, 3 Oct 2007 22:52:39 -0700, Luigi Rizzo wrote:
>> I couldn't find a decent video client under windows: 
> 
> try playing around with openwengo, a linux/mac/windows qt-based softphone
> which is also gpl-licensed. we've tested it with asterisk 1.2.x and video
> (using h.263) works like a charm with a simple patch. troll through the
> wengophone-dev mailing lists for the patch which i submitted there. afaik,
> the patch has yet to be comitted to the wengophone svn repo. 


I tried OW 2.1 but it crashed really often. But the release candidate 
looks more stable (not heavily tested yet).

regards
klaus

___
--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] AST_FRAME_DIGITAL

[Klaus Darilion]

Steven Critchfield wrote:
> On Fri, 2007-09-14 at 17:15 +0200, Klaus Darilion wrote:
>> critch schrieb:
>>> The addon would then be a transcoder of H223 data to the demuxed
>>> audio/video/control frames using the library that is GPL licensed.
>>>
>>> This way is a lot more likely to get merged with the official releases
>>> as it is the asterisk way, and requires little changes to the core of
>>> the application.   
>> I agree. But extending the translation framework to translate 
>> AST_FRAME_VOICE(AST_FORMAT_H223) into AST_FRAME_VOICE(AST_FORMAT_AMR) 
>> and AST_FRAME_VIDEO(AST_FORMAT_H63_PLUS) is not easily done. Thus, to 
>> make 3G calls possible now I prefer the application, but if for example 
>> 1.6 allows translation between frame types then the application should 
>> be migrated in to translation framework.
> 
> So let us go about this in an interim manner.
> 
> Modify the ISDN channel drivers to hand up
> AST_FRAME_VOICE(AST_FORMAT_H223) from them to asterisk. Your application
> could request format AST_FORMAT_H223 such that there is no translation
> required. From here you continue your current development as you are.
> 
> The benefit here is that you get asterisk to the point of being able to
> native bridge 3g calls, and you get to worry only about your app for now
> while looking at how to get the translation layer to handle things
> better in the future. 
> 
> Also when you request from your application the format AST_FORMAT_H223,

how do I do this (in lines of code)?

klaus


> you can see if asterisk was able to handle the request. If the call
> wasn't a H223 call, asterisk couln't get you a H223 format and you will
> know you don't have the data you are looking for and can fail in a
> predictable manner. 
> 
> For instance, you could pass all your incoming calls into your 3g video
> application as a brute force detection this way. If your app gets 3g
> video stream, then it handles it the way you intend to, else it exits
> and allows the call to pass to the rest of your normal extension logic.
> 
> See how just a little effort yields lots of cool magic from the core
> knowing what it is transfering around?


___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

Steven Critchfield wrote:
> So let us go about this in an interim manner.
> 
> Modify the ISDN channel drivers to hand up
> AST_FRAME_VOICE(AST_FORMAT_H223) from them to asterisk. Your application
> could request format AST_FORMAT_H223 such that there is no translation
> required. From here you continue your current development as you are.

Almost done ;-)

What about adding AST_FORMAT_H223 to rtp.c too? This way we could 
forward H223 to other Asterisk Boxes doing the demux and video stuff.

regards
klaus

___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

Matthew Fredrickson wrote:
> Klaus Darilion wrote:
>> Russell Bryant schrieb:
>>> Matthew Fredrickson wrote:
>>>>> So, if I get it right - there is no need to introduce AST_FRAME_DIGITAL 
>>>>> as it is already there (but named AST_FRAME_MODEM)?
>>>> Yes, basically.  Look in include/frame.h in asterisk 1.4 sources.  There 
>>>> are already subclasses defined for T38 and V150.  I'm thinking that an 
>>>> extension to this frametype would give us what we want.  Then an 
>>>> extension to the translator architecture so that we can make translators 
>>>> for frames other than AST_FRAME_VOICE.
> 
> 
> 
>>> AST_FRAME_MODEM or DIGITAL or whatever is not going to work without a lot of
>>> extra effort.  However, as has been suggested, creating an AST_FORMAT_H223 
>>> would
>>> do it.  It's a hack, but you'd have to put the data in an AST_FRAME_VOICE 
>>> with a
>>> subclass of AST_FORMAT_H223.  In that case, Asterisk would happily pass it
>>> through without transcoding it, since it has no codec module to handle it.
>>>
>>> I don't want to keep this feature from being available to users of 
>>> Asterisk, I
>>> just want to make sure it is done the most flexible way.
>> This solution is what I am currently working on. Nevertheless I would
>> call it AST_FORMAT_DIGITAL to be more generic and allow bridging of
>> non-h223 calls too (e.g. proprietary data services). The differentiation
>> can be done in the dialplan by analyzing for example user information 
>> layer 1 (e.g. with this patch: http://bugs.digium.com/view.php?id=10217)
> 
> I think that I agree with Russell and Tilghman that having an opaque 
> AST_FORMAT_DIGITAL is ugly for this purpose, especially if it requires 
> analysis in the dialplan for it to even work correctly.  If we were 
> talking about true ISDN data calls, it might be appropriate, but for 
> purposes of passing H223 content through Asterisk, I think that this is 
> the *wrong* approach.

Ok. I will make it AST_FORMAT_H223. My first version will send 
AST_FORMAT_H223 as AST_FRAME_VOICE (this is not very complicated) and 
works fine with current translation core. Further versions should send 
AST_FORMAT_H223 inside AST_FRAME_MODEM/DIGITAL/RAW/OPAQUE/TOBEDEFINED 
when the translation framework is able to handle it.

regards
klaus

> 
> Nothing like that should be considered an opaque type by the core.  True 
> data should be, but when we have audio and video involved like there is 
> in H223, there should be a way that (if necessary) it can be decoded and 
> passed to non ISDN channel types.
> 


___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

Matthew Fredrickson wrote:
> Tony Mountifield wrote:
>> In article <[EMAIL PROTECTED]>,
>> Sergio Garcia Murillo <[EMAIL PROTECTED]> wrote:
>>> Just cheking q931 bearer capability:
>>>
>>> pri debug span 1
>>> Bearer Capability (len= 3)
>>>  Ext: 1  Q.931 Std: 0  Info transfer capability:
>>>  Unrestricted digital information (8)
>>>  Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>>>  Ext: 1  User information layer 1: H223/H245 data (38)
>> Was one of the original posts in this thread suggesting that a frame
>> such as the above was being treated by Asterisk as G.711 speech?
>>
>> If so, surely that is wrong, and the frame/call should be rejected,
>> until such time as the proper handling is designed and implemented.
> 
> We do not reject by default, since there was a time (I'm not sure if it 
> still works since I can't test it directly) that zap-to-zap bridges 
> could pass through video, data, etc without a problem.  So, this is not 

Vanilla Asterisk 1.4 copies transfer capability from incoming to 
outgoing call but user information layer 1 is lost.

regards
klaus


> "wrong", it's just that it won't work very well outside the context of 
> chan_zap.
> 


___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

--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] proper way to signal user information layer 1 (ISDN)

[Klaus Darilion]

Matthew Fredrickson wrote:
> Klaus Darilion wrote:

> I think that probably making chan_zap so that it is more codec aware 
> would be the right way to adjust this field.

I thought having a generic mechanism which allows changing UL1 without 
coding would be cool - but I have no problem to hardcode it into chan_zap.

regards
klaus

___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

critch schrieb:
> On Thu, 2007-09-13 at 14:55 +0200, Klaus Darilion wrote:
>> Tilghman Lesher schrieb:
>>> On Thursday 13 September 2007 05:14:40 Klaus Darilion wrote:
>>>> Do you transcode IP packets from ulaw to alaw when sent from US to
>>>> Europe? No - because it is digital.
>>> Yes, you do, because it is a different codec.
>> Is this IPv7?
> 
> Someone must transcode ulaw to alaw or you don't get any usable audio
> out the otherside. 


I know - but in the previous example I was talking about IP (Internet 
Protocol) - not ISDN
> 
> Could this be the communications problem we are having right
> now

It is good that you can still laugh about it :-)

> Any of the VoIP protocols would have told one side or the other what
> codec they are using, and the otherside will have decided they can deal
> with the incoming or not. That descision is based on knowing what it is
> that they are to be getting on the wire.
> 
> Asterisk needs to treat the data it receives in a standard way because
> we need to hand this information off to many differing technologies. So
> having the base data converted into something that asterisk can then
> pass around and know what it is, is important. 

Yes. Currently we have g729 pass through - no need for Asterisk to 
transcode - Asterisk only knows this is something I do not understand 
thus I pass it through. The same applies for T.38.

I think one problem is that Asterisk is still focused very much on 
voice. For example if we have 2 channels drivers which only support 
AST_FRAME_TEXT asterisk still tries to find the best voice codec when 
bridging.

Thus, my idea, to just introduce the voice format AST_FORMAT_DIGITAL. 
This can be used by any channel_driver which supports raw data delivery 
(I think Cisco calls it "clear channel" for VoIP). I will add it to core 
and chan_zap and later it can be added to other channel drivers too.

> How much effort is truly involved in splitting the original data stream
> into the 3 constituent streams, and then remerging them? Is this really

I do not know it exactly - it is H.223 decoding (which depends on the 
used mobility level. Level 0 is just HDLC whereas higher levels are very 
robust to bit errors but are complex to decode).

> too much load to handle? Yes it may seem unnecessary to you, but for the
> same reasoning we shouldn't packetize the audio coming off of a
> streaming channel driver then. Asterisk tries to handle everything as
> generically as possible. Hand it packets of audio, and it will pass
> those on to whatever channel driver needs it and then those drivers can
> start from a simple known starting point and provide the proper output.
> Get your data to simple known spec, and most channel drivers will be
> able to get it out to the otherside.

One more reason to have the 3G video decoding in an application is the 
current state of the application. I guess we need to fix lots of things 
to make it stable and more robust and applying the fixes to each ISDN 
channel drivers is very time consuming.

regards
klaus

___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

Tilghman Lesher schrieb:
> On Thursday 13 September 2007 04:52:20 Klaus Darilion wrote:
>> Russell Bryant schrieb:
>>> Klaus Darilion wrote:
>>>> Thus, why do we have a AST_FRAME_IMAGE? Why is IMAGE not treated as
>>>> VOICE? Obviously because Asterisk would transcode and the image is
>>>> broken - the same reason why I like AST_FRAME_DIGITAL.
>>> I don't think that comparing IMAGE to DIGITAL is a valid comparison.  I
>>> can look at the image in an IMAGE frame.  I can listen to the audio in a
>>> VOICE frame. But what about DIGITAL?  How is Asterisk supposed to
>>> interpret a DIGITAL frame?
>> That's the whole point - it should not interpret it at all.
> 
> In that case, you should not queue the frame to Asterisk.  Period.  If you are
> telling me that Asterisk should not know anything about the contents, then
> it will not handle that frame for any reason whatsoever.
> 
> I don't think, however, that that is what you want.  You want, essentially,
> Asterisk to become a carrier of proprietary information that it just blindly
> passes on to whatever is on the other side.  That does not jibe with the
> model of ANY of the existing channel drivers in Asterisk today.  EVERYTHING
> must know _what_ it is that it is carrying, in order to properly queue it to
> the other side.  We don't support unknown codecs, we don't support unknown
> video types, and we certainly do not support "here's this packet of unknown
> information, just pass it blindly".
> 
> Asterisk is an intelligent application, and you're trying to treat it like a
> dumb pipe.

I know Asterisk is an intelligent application - but it should be so 
intelligent to know that digital data should not be transcoded.

I do not understand why you resist to make Asterisk useful to more 
scenarios. Currently Asterisk does not correctly bridge digital ISDN 
calls and I want to fix - but you tell me that Asterisk can't do that 
because it is to intelligent?


To me that sounds like "please do not make Asterisk useful in other 
scenarios too..."

regards
klaus

___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

Russell Bryant schrieb:
> Christian wrote:
>> I vote for AST_FRAME_DIGITAL too! I think i suggested that about over 
>> one year already..  It would be very useful to transport Digital Data 
>> like HDLC Frames which might occur in the media channel of chan_zap and 
>> chan_misdn. At the moment such data would be sent with AST_FRAME_VOICE 
>> which is not appropriate.
> 
> I will not argue that such a thing would not be useful.  However, I want to be
> _very_ strict about what it could be used for.  In the context of this thread,
> where the stream is actually voice and video, it is absolutely not 
> appropriate.

What about G3 fax. It is rather the same as 3G video:
  fax delivers images over a telephone line
  3G video deliver audio and video over a telephone line

In case of G3 fax, the image data is modulated
In case of 3G video, the audio/video is multiplexed with H223.

Currently fax is handled inside an application. Taking your argument, 
the fax decoder should be in the channel driver and deliver 
AST_FRAME_IMAGE (maybe one per page) to Asterisk's core. But I think the 
current implementation which is a single application is much better then 
adding modem functionality to each channel driver.

IMO it is much more flexible only add support for generic data 
(AST_FRAME_DIGITAL) to channel drivers. Then, new services and features 
can be added as application without touching the code of channel drivers.

regards
klaus

___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

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

[Klaus Darilion]

Russell Bryant schrieb:
> I can tell you right now that you will not be able to convince me that we 
> should
> add an opaque frame type for this situation.  It is completely against the
> Asterisk architecture.  As you said, the stream you are handling is in fact
> voice and video.  Asterisk has explicit handling for voice and video, and the
> streams should be passed into Asterisk using those frame types.

Hi Russel!

A simple scenario: A Asterisk server is used as PBX and is connected to 
the PSTN with a PRI (zap). Further, it has a BRI card to connect to 
in-house BRI devices.

Asterisk bridges calls between BRI and PRI, and sometimes this is a 
digital call. As digital calls do not have proper treating yet, it will 
happen that Asterisk thinks that PRI uses ulaw and BRI uses alaw and 
starts transcoding - which is a very bad thing for digital connections.

Thus, why do we have a AST_FRAME_IMAGE? Why is IMAGE not treated as 
VOICE? Obviously because Asterisk would transcode and the image is 
broken - the same reason why I like AST_FRAME_DIGITAL.

Maybe I do not need AST_FRAME_DIGITAL at all but could use 
AST_FRAME_IMAGE too - but I do not know how Asterisk handles images and 
maybe someday a feature is added to resize images and then it aagin 
would break digital connections.

Thus I think Asterisk should have a AST_FRAME_DIGITAL for bridging any 
data without interpretation.

regards
klaus

___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

--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] AOC in chan_sip

[Klaus Darilion]

Hi Wolfgang!

Regarding AOC-encoding/decoding:

For AOC decoding there is already code in libpri.
For AOC encoding you can take a look at 
http://bugs.digium.com/view.php?id=7494

regards
klaus

Wolfgang Pichler schrieb:
> Hi all,
> 
> as far as i know there is no standard way (no RFC...) to implement AOC 
> (AOC-S, AOC-D and AOC-E) within sip. But there are already some devices 
> out there which does support SIP AOC Messages. I am currently playing 
> with 2 of them.
> 
> The first one are snom devices - the are supporting AOC with a special 
> SIP INFO Messages which are getsting described here:  
> http://wiki.snom.com/wiki/index.php/Advice_of_charge_%28AOC%29_in_SIP
> 
> The second one are patton gateways - which are using the following SIP 
> INFO Message to transfer the AOC info.
> 
> INFO sip:[EMAIL PROTECTED]:5060 SIP/2.0
> Via: SIP/2.0/UDP 000.000.000.0:5062;branch=z9hG4bKfb0c15d1d
> Max-Forwards: 70
> Content-Length: 60
> To: sip:[EMAIL PROTECTED]:5060;tag=565aadc2bfc3677
> From: sip:[EMAIL PROTECTED]:5062;tag=2aa3479136cfb29
> Call-ID: [EMAIL PROTECTED]
> CSeq: 667497007 INFO
> Supported: timer
> Content-Type: application/QSIG
> Supported: replaces
> User-Agent: Patton SN4638 5BIS UI MxSF v3.2.8.45 00A0BA020142 R4.T 
> 2007-05-28_RFE745 H323 SIP BRI
> 
> 91a11a0201000201213012a10d810346522ea206810100820101820100
> 
> Basicaly the patton gateway does encapsulate the ISDN binary code into a 
> sip info message with Content Type application/QSIG
> 
> Now i do want to implement the patton AOC support within the sip channel.
> 
> The big question now is - where and how to start...
> 
> I have taken a look at the code in chan_sip.c, and i do have some 
> questions about it.
> 
> - The iflist linked list - is this a list with all currently open sip 
> dialogs ?
> - The do_monitor thread in chan_sip does monitor all currently open 
> dialogs (iflist) and loaded sip peers. It will check if a dialog needs 
> to get destroyed, and so on. So this thread seems to me to be the best 
> starting point.
> 
> What i have tried to do is the following - i have added some extra vars 
> to the iflist struct - so that i can remember when i has sent the last 
> SIP INFO aoc Message. In do_monitor i do check the last time against the 
> current time - and if 1 second is over - then the next SIP INFO AOC 
> message will get generated and send. This does already work - but the 
> generated SIP INFO Messages does not seem to be correct.
> 
> Here is my code which does generate the SIP INFO Message:
> 
> static int sip_send_aocd_to_peer(struct sip_pvt *p)
> {
> struct sip_request req;
> char buf[2048];
> 
> reqprep(&req, p, SIP_INFO, 0, 1);
> // Insert already generated ISDN binary for testing purpose
> snprintf(buf, sizeof(buf), 
> "91a11a0201000201213012a10d810346522ea206810100820101820100");
> /*  add_header(&req, "AOC", buf);
> add_header_contentLength(&req, 0);  */
> 
> add_header(&req, "Content-Type", "application/QSIG");
> add_header_contentLength(&req, strlen(buf));
> add_line(&req, buf);
> 
> return send_request(p, &req, 1, p->ocseq);
> }
> 
> this does generate the following sip messages:
> 
> INFO sip:[EMAIL PROTECTED]:5061 SIP/2.0
> Via: SIP/2.0/UDP 88.198.158.245:5060;branch=z9hG4bK2a0ddade;rport
> From: ;tag=as5f87418c
> To: 101 ;tag=868274887
> Contact: 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 102 INFO
> User-Agent: Commoveo Cockpit
> Max-Forwards: 70
> Content-Type: application/QSIG
> Content-Length: 58
> 
> 91a11a0201000201213012a10d810346522ea206810100820101820100
> 
> 
> 
> Seems to be quit ok - but want work...
> 
> Does anyone here has already tried something like that and can give me a 
> hint about this ?
> 
> I am doing something completly wrong here ?
> 
> Or - does anyone here already have a working aoc implementation for sip ?
> 
> regards,
> Wolfgang Pichler
> 
> 
> 
> 
> ___
> --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] behavior of 'nat=yes' with 'directrtpsetup=yes'

[Klaus Darilion]

You can make things even complicater - e.g. if you Answer() before 
Dialing out to the other client (e.g. for some announcements) - then 
directrtp wont work without reINVITE.

regards
klaus

Adam Gundy wrote:
> following on from a suggestion that a bug report I raised (10335) is at
> least partly a feature request and should be discussed on -dev, I have a
> question about the meaning of 'nat=yes', and a feature request...
> 
> basically, I have some NAT-blind SIP clients (OpenWengo) which do not
> support SIP reinvites, and I was hoping the directrtpsetup option in
> asterisk 1.4.x would help with this.
> 
> the problem is that it doesn't work, basically because of the way
> 'nat=yes' deals with RTP - asterisk waits for an incoming packet, then
> sends all RTP to the IP/port that it came from. this works around the
> fact that the NAT-blind SIP client put LAN IP/ports in the SIP packet.
> 
> so, when we get to directrtpsetup=yes, asterisk ends up sending the LAN
> IP/ports of the two clients to each other, which obviously doesn't work
> (unless they both happen to be behind the same NAT!), because asterisk
> *never receives any RTP from the clients to fix its idea of the IP/ports*.
> 
> now here's the real question: what does 'nat=yes' mean? if it implies
> 'symmetric NAT' or 'router with ports forwarded', then we can actually
> fix up this situation; we DO know the IP address that the SIP packet
> came from, and if (as in my case) the SIP IP address is the same as the
> RTP IP address, we could fix our idea of the RTP address without any
> packets arriving, and the direct connection should work.
> 
> alternatively, if 'nat=yes' means 'dumb SIP client with no clue what its
> IP/ports are', then we basically have to ban directrtp for this case,
> and either use reinvites (if enabled), or proxy.
> 
> if that IS the case, can we have a 'nat=symmetric' which means
> 'symmetric NAT/router with ports forwarded' please? I'm sure there are
> many SIP clients or hardware widgets out there which have no idea about
> STUN and basically come with instructions to forward a range of ports
> (I'm looking at the Polycom phone on my desk here as one example)
> 
> thanks..
> 
> 
> ___
> --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] common functions for int2string conversion

[Klaus Darilion]

Hi!

Are somewhere common functions for string/integer conversion defined?

thanks
klaus

___
--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] Fixing Asterisk DNS - bug 9152, asynchronous DNS, etc

[Klaus Darilion]

Olle E Johansson wrote:
> If dnsmgr is not asynch DNS, I suggest that someone takes a look into  
> the C-ares library.
> It has a license that Kevin/Mark has approved of and will help us to  
> proper asynch
> DNS. It's used by curl, so in some installations it's already used by  
> asterisk in app_curl.

FYI: There is also an extended version of ares included in the 
resiprocate stack.


klaus

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

Re: [asterisk-dev] Adding Octastic Soft-Echo to external SIP adapters

[Klaus Darilion]

Vazir wrote:
How than my CISCO AS5350 gets H323 VOIP and echo-cancels so 
exelently :))


If it is a plain H323-H323 call then there should not be any echo at all.

If you have a PSTN<->VoIP call and the PSTN leg uses analog lines then 
the PSTN side will create an echo which will be cancelled by the PSTN 
side of the gateway.


regards
klaus



On 7 May 2007 12:45, Eric "ManxPower" Wieling wrote:

Generally, once the audio is converted to VoIP audio
latency is far too high for echo canceling to work.  Echo
needs to be canceled BEFORE the call is converted to
VoIP.

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

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

Re: [asterisk-dev] TLS/SSL futures

[Klaus Darilion]

Michiel van Baak wrote:


On Nov 6, 2006, at 10:21 PM, Kevin P. Fleming wrote:


Luigi Rizzo wrote:


iksemel is third party software that uses whatever its authors
decided to use, and i don't think anyone has the interest of rewriting
it to use openssl.


Actually, that's not correct. Due to various other issues, Matt O'Gorman
has been working on exactly that, and will soon have a branch of iksemel
available that uses OpenSSL instead of GnuTLS.


Great.
I think it's a good idea to use OpenSSL for all the SSL things because 
it's the most portable SSL thing I've seen.

It's there by default on my osx, openbsd and debian installs.
I hope Matt will have something to test soon.


Debian and openssl is not that easy. E.g. the openser shipped with 
debian has TLS disabled as it uses openssl and there are some conflicts 
with the GPL if openser is shipped as part of the Linux distribution.


It's somehow crazy - it is legal to offer debian packages for an TLS 
enabled openser, but it is illegal to include these packages to debian 
itself.


Thus, I suspect Asterisk may have the same problems.

regards
klaus

--
Klaus Darilion
nic.at

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

Re: [asterisk-dev] SIP Address port remove suggestion

[Klaus Darilion]

Alexandre Almeida wrote:

I have a peer with this configuration, it's used as trunk for outgoing
calls.


[xxyy]
username=123456
type=peer
secret=1423241
port=5070
outboundproxy=my.proxy.com
host=gateway.server.com


workaround: make SRV records which point to port 5070 and remove the 
port= option


regards
klaus
___
--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

Re: [asterisk-dev] shutting down zaptel spans

[Klaus Darilion]

Kevin P. Fleming wrote:

- Tzafrir Cohen <[EMAIL PROTECTED]> wrote:

When is there a need to shut down zaptel spans from userspace?


I'm not aware of any benefit of doing so.


What if I want to "reset" an E1 link remotely without stopping asterisk? 
Sometimes connected PBXs behaves strange and restart of the E1 link 
solves the problem. For this I could unplug the E1 link (if I am 
physically at the Asterisk location) or stop/start asterisk/zaptel.


Or is there a command to shut down a PRI link without stopping asterisk?

regards
klaus

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

Re: [asterisk-dev] Re: Advice of charge

[Klaus Darilion]

Tomislav Parčina wrote:

-Original Message-
From: Klaus Darilion [mailto:[EMAIL PROTECTED] 
Sent: 28. rujan 2006 10:29

To: Asterisk Developers Mailing List; Tomislav Parčina
Subject: Re: [asterisk-dev] Re: Advice of charge

The patch is on the bug tracker. It is not a nice solution, 
because a nice solution would require deep changes in 
asterisk (do not hangup a call until the AOC is received from 
the other call leg - see old aoc discussion threads) - 
nevertheless it works fine in our scenario.


Can you please be more specific. Which part of Asterisk code requires deep 
changes to make this work? Is it app_dial.c or something else?




Please search the archive for AOC threads.

regards
klaus
___
--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

Re: [asterisk-dev] Advice of charge

[Klaus Darilion]

Only ZAPTEL PRI

regards
klaus

Kai Ober wrote:

does this patches provide AOC to mISDN as well?
or just PRI CARDS?

Kai

Klaus Darilion schrieb:

http://bugs.digium.com/view.php?id=7495
http://bugs.digium.com/view.php?id=7494

It is in use since 2 month without problems (1.2)

regards
klaus



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


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

Re: [asterisk-dev] Advice of charge

[Klaus Darilion]

http://bugs.digium.com/view.php?id=7495
http://bugs.digium.com/view.php?id=7494

It is in use since 2 month without problems (1.2)

regards
klaus

Tomislav Parčina wrote:

What is current status of advice of charge messages in Asterisk? Will it be 
full supported in next releases? I would appreciated any info about this.


--
Tomislav Parčina
Lama Computers Split
Stinice 12, 21000 Split
Tel.: +385(21)495148
Mob.: +385(91)1212148
SIP: [EMAIL PROTECTED]
e-mail: tparcina#lama.hr
http://www.lama.hr
___
--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


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

Re: [asterisk-dev] Zaptel-1.2.8 compile problem

[Klaus Darilion]

Vidura Senadeera wrote:

Please guide me on this Sir .. How do I get rid of this?


Update to Centos 4.4 (or RedHat 4.4) or fix the kernel sources. Google 
is your friend.


regards
klaus




On 9/4/06, *Kevin P. Fleming* <[EMAIL PROTECTED] 
 > wrote:


- Vidura Senadeera <[EMAIL PROTECTED]
> wrote:
 > Thanks for the input. I have compiled again and had the out put.
 > please refer the make.txt file.

This is a well known problem with CentOS 4.3 kernel headers. Fix
your kernel headers.

--
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.

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




--
Thanks & Regards,
Vidura B. Senadeera.




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


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

Re: [asterisk-dev] Asterisk as voice gw to the IMS world

[Klaus Darilion]

Raphael Jacquot wrote:

George Thanos wrote:

SIP signalling from IMS is a little bit different from the Asterisk 
SIP stack. 3GPP has defined some extentions to the protocol.


yet another case of "lets break the RFCs for profit" ?


AFAIK all 3GPP extensions are RFCs (or on the way to an RFC)


do you have specs available for the changes ?
___
--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


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

Re: [asterisk-dev] chan_zap questions

[Klaus Darilion]

Armin Schindler wrote:

On Wed, 12 Jul 2006, Klaus Darilion wrote:

Maybe an additional subclass
AST_CONTROL_AOC
should be introduced.

Thats what I did and it works fine. But ast_indicate_data requires a
ast_channel as first parameter. If FACILITY is received on leg2, I have to
find out the ast_channel of leg 1 to indicate on the proper channel. Fur this
purpose I still use ast_bridged_call. Any other suggestion?


No, don't use ast_indicate*() directly, just use the normal *read function 
to give this CONTROL frame to asterisk. The asterisk code (bridge or 
dial-before-bridge) will forward this CONTROL frame to the other leg. 


Aha, sounds interesting. Can you give me a pointer to the code where 
this is already used? Why should I use *read functions? I would rather 
think of *write functions?


regards
klaus

 

during processing of case PRI_EVENT_FACNAME:
struct ast_channel *otherchan;
otherchan = ast_bridged_channel(pri->pvts[chanpos]->owner);
if (otherchan && (!strcmp(otherchan->tech->type, "Zap"))) {
/* Only for Zap channels */
ast_indicate_data(otherchan, AST_CONTROL_AOCD, &aocd,
 sizeof(struct aocd_data));


Yes, that's the direct way, but you don't need that. See above.

Armin

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


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

Re: [asterisk-dev] chan_zap questions

[Klaus Darilion]

Armin Schindler wrote:

On Wed, 12 Jul 2006, Klaus Darilion wrote:

Armin Schindler wrote:

On Tue, 11 Jul 2006, Kevin P. Fleming wrote:

- Armin Schindler <[EMAIL PROTECTED]> wrote:

I think a defined indication via ast_indicate() (which is
forwarded by
Asterisk even in app_dial()) would be more appropriate.

We've already added the ability to queue control frames (which are
delivered by ast_indicate()) that carry a payload, which was done
specifically for this purpose.

Yes, I noticed the additional Parameter to the indicate function.
That's why I mentioned this. It's a better way than doing it via the
bridge.

Klaus, what is the reason for using the bridge instead of indicate?

Probably it is lack of Asterisk know-how. ast_indicate_data looks promising -
but I still do not know how to get the reference to the other call leg.


Caller  AsteriskCallee
leg 1 leg2
<---FACILITY---


Currently, if there is an incoming FACILITY message, the facility event is
sent to chan_zap, which gets the AOC-D units from the event structure. But to
forward it on call leg 1 I need to get a reference to the ast_cannel of leg 1.
How do I get this?


I don't think you need to know the other leg.
Just pass a CONTROL FRAME to Asterisk.
It seems that currently these CONTROL frames are supported for
additional data:
 AST_CONTROL_HOLD
 AST_CONTROL_UNHOLD
 AST_CONTROL_VIDUPDATE

Maybe an additional subclass
 AST_CONTROL_AOC
should be introduced.


Thats what I did and it works fine. But ast_indicate_data requires a 
ast_channel as first parameter. If FACILITY is received on leg2, I have 
to find out the ast_channel of leg 1 to indicate on the proper channel. 
Fur this purpose I still use ast_bridged_call. Any other suggestion?



during processing of case PRI_EVENT_FACNAME:
  struct ast_channel *otherchan;
  otherchan = ast_bridged_channel(pri->pvts[chanpos]->owner);
  if (otherchan && (!strcmp(otherchan->tech->type, "Zap"))) {
/* Only for Zap channels */
ast_indicate_data(otherchan, AST_CONTROL_AOCD, &aocd,
  sizeof(struct aocd_data));
...


regards
klaus




Armin

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


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

Re: [asterisk-dev] chan_zap questions

[Klaus Darilion]

Armin Schindler wrote:

On Tue, 11 Jul 2006, Kevin P. Fleming wrote:

- Armin Schindler <[EMAIL PROTECTED]> wrote:

I think a defined indication via ast_indicate() (which is forwarded by
Asterisk even in app_dial()) would be more appropriate.

We've already added the ability to queue control frames (which are delivered by 
ast_indicate()) that carry a payload, which was done specifically for this 
purpose.


Yes, I noticed the additional Parameter to the indicate function.
That's why I mentioned this. It's a better way than doing it via the bridge.

Klaus, what is the reason for using the bridge instead of indicate?


Probably it is lack of Asterisk know-how. ast_indicate_data looks 
promising - but I still do not know how to get the reference to the 
other call leg.



Caller  AsteriskCallee
  leg 1 leg2
<---FACILITY---


Currently, if there is an incoming FACILITY message, the facility event 
is sent to chan_zap, which gets the AOC-D units from the event 
structure. But to forward it on call leg 1 I need to get a reference to 
the ast_cannel of leg 1. How do I get this?


thanks
Klaus
___
--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

Re: [asterisk-dev] Bridging two H324M calls

[Klaus Darilion]

Please edit the Wiki page and attach it to the Wiki page. Then we can a 
single point of information


regards
klaus

zhuoqun Li wrote:

Hi Sergio,
Could you leave your email address here so I can email my trace files  
to you?


regards,
Zhuoqun


Message: 4
Date: Wed, 3 May 2006 08:45:04 +0200
From: Sergio Garc?a Murillo <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Subject: RE: [asterisk-dev] Bridging two H324M calls
To: "Asterisk Developers Mailing List" <
asterisk-dev@lists.digium.com <mailto:asterisk-dev@lists.digium.com>>
Message-ID:
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Content-Type: text/plain; charset="iso-8859-1"

Could you share the dumped files at least?
They would be very usefull..



From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] On Behalf Of zhuoqun Li
Sent: martes, 02 de mayo de 2006 18:19
To: asterisk-dev@lists.digium.com <mailto:asterisk-dev@lists.digium.com>
Subject: Re: [asterisk-dev] Bridging two H324M calls




Hi Klaus,
to record a live video conversation, you just need to insert some
pieces of code into chan_zap.c, i.e. in the part where chan_zap do
native bridging:I inserted several lines (e.g. tmp = write(ftrace,
f->data, f->datalen); ) in line 3464 ( zt_bridge(), chan_zap.c).
BTW, I did the  H324M call briding in a v-1.2.4 Asterisk in the UK.

regards,
Zhuoqun Li






    Date: Tue, 02 May 2006 11:17:14 +0200
From: Klaus Darilion < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Subject: Re: [asterisk-dev] Bridging two H324M calls
To: Asterisk Developers Mailing List <
asterisk-dev@lists.digium.com <mailto:asterisk-dev@lists.digium.com>>
Message-ID: <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Content-Type: text/plain; charset=ISO-8859-1;
format=flowed

zhuoqun Li wrote:
>  Hi,
>  I have successfully bridged H324m calls through
Asterisk (configured
> with a ISDN BRI interface).
>  I have aslo dumped the live video conversation
into a binary file.
>  What I did is a "native channel bridge" and the
dump functions are
> inserted in the zt_bridge() in chan_zap.c.
>  Hope this helps...

Can you share your code? E.g. post it on
bugs.digium.com <http://bugs.digium.com>

regards
klaus

>
>
>  regards,
>  Zhuoqun Li
>
>
>
> --
>
> Message: 4
> Date: Fri, 28 Apr 2006 08:41:24 +0200
> From: Sergio Garc?a Murillo <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> >>
> Subject: RE: [asterisk-dev] Bridging two H324M
calls
> To: "Asterisk Developers Mailing List" <
> asterisk-dev@lists.digium.com
<mailto:asterisk-dev@lists.digium.com>
<mailto:asterisk-dev@lists.digium.com
<mailto:asterisk-dev@lists.digium.com> >>
> Message-ID:
    ><[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> mailto:[EMAIL PROTECTED]>>>
> Content-Type: text/plain;  
charset="iso-8859-1"

>
> Klaus Darilion wrote:
>  > Hi Sergio!
>  >
>  > I've done this once and it worked
(relaying). But I was not able to
>  > record the sessions. When I tried the
various "recording"
>  > applications the video call setup did not
worked anymore. Relaying
>  > was only successful when the bridging was
done directly on the ISDN
>  > card.
>  >
>  > I did this once with an old Asterisk
version. With ne

Re: [asterisk-dev] Bridging two H324M calls

[Klaus Darilion]

Hi Sergio!

I've done this once and it worked (relaying). But I was not able to 
record the sessions. When I tried the various "recording" applications 
the video call setup did not worked anymore. Relaying was only 
successful when the bridging was done directly on the ISDN card.


I did this once with an old Asterisk version. With newer Asterisk 
version relaying is not possible anymore, as the zaptel code changes 
some call parameters (from data calls to anything else ...).


I tried to debug this once (message 0025307)
http://bugs.digium.com/view.php?id=3891

but did not received any help and could not solved it myself.

regards
klaus

Sergio García Murillo wrote:

 Hi again,

I have been looking at the traces and rereading the standards and I have been 
only able to find the empty pdu (e1 4d 00 00 00 e1 4d) in them (apart of the 
strange groups at the beginning of the nokia file, which I'm still not able to 
understand).
Would it be possible to have to bridge to b channels to try to get a full trace?
I mean, when receiving an incoming videocall in asterisk make an outgoing one to another mobile phone and just copy the data received from one to another. 
I don't know if they would be able to successfully establish a videocall, but the traces would be very useful.


Regards
 

 
Sergio Garcia Murillo

Research & Development

.y dilo 
Advanced Voice Solutions

Paseo de la Castellana 216
28046 Madrid (Spain)
Phone: +34 91 252 8480
Fax: +34 91 252 8448
http://www.ydilo.com 

 

 


--
This message and any files transmitted with it are confidential and intended solely 
for the use of the individual or entity to whom they are addressed. No confidentiality 
or privilege is waived or lost by any wrong transmission. 
If you have received this message in error, please immediately destroy it and kindly 
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any 
part of this message if you are not the intended recipient. Opinions, conclusions and 
other information in this message that do not relate to the official business of 
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it. 
--

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


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

Re: [asterisk-dev] H324M Gateway

[Klaus Darilion]

Sergio García Murillo wrote:
Just ftp and decode FTP-DATA as h223. 
That does nto work. My ethereal only offers H245, no h223. I'm using 
ethereal 0.10.13 on windows. Are you using a special version of ethereal?


Ethereal 0.10.14 on windows also.. check in help->about->plugins 


Protocol field name: h223
Versions: 0.10.14 to 0.99.0

I have to update :-)
___
--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

Re: [asterisk-dev] H324M Gateway

[Klaus Darilion]

Sergio García Murillo wrote:
Just ftp and decode FTP-DATA as h223. 


That does nto work. My ethereal only offers H245, no h223. I'm using 
ethereal 0.10.13 on windows. Are you using a special version of ethereal?


regards
klaus



But I have just see that the first packet are not decoded properly (it complains about "No complete PDUS") and some more gave errors also, probably we should find a better way to make ethereal analyze the stream. 


I have look at the ethereal source code and it has a directory called h223 with 
a golay encoder/decoder and info for h223 and srp.

I've look also for the guys that make the plugin and their company offer 3G 
video gateway services, so I don't expect to get much help from them.. :(

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion
Sent: martes, 25 de abril de 2006 11:05
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] H324M Gateway

Sergio García Murillo wrote:

Is anyone currently interested or doing some work about that?

 

I have been investigating a bit and find that the capture files that are 
in the wiky are correctly parser by ethereal (just send it over tcp, 
capture and decode as h223, it will decode perfectly).  


Hi Sergio!

Great news - I tried decoding manually (hex editor) and failed. How did 
you sent it via TCP - just with netcat?


regards
klaus

Perhaps the h223 parser and de gollay decoder of ethereal is a good 
point of start..




 


Sergio

 





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


___
--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
--
This message and any files transmitted with it are confidential and intended solely 
for the use of the individual or entity to whom they are addressed. No confidentiality 
or privilege is waived or lost by any wrong transmission. 
If you have received this message in error, please immediately destroy it and kindly 
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, or copy any 
part of this message if you are not the intended recipient. Opinions, conclusions and 
other information in this message that do not relate to the official business of 
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it. 
--

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


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

[asterisk-dev] Zaptel echo canceler as runtime option

[Klaus Darilion]

Hi!

Currently, the echo canceler in zaptel modules is a compile time option. 
This makes echo tweaking complicated.


HAve there ever been thoughts about having all of them available and 
choose them as zapata.conf option?


btw: Why is the echo cannceler not a generic PBX feature? Instead it is 
present in various channel drivers of hardware modules.


regards
klaus
___
--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

Re: [asterisk-dev] H324M Gateway

[Klaus Darilion]

Sergio García Murillo wrote:

Is anyone currently interested or doing some work about that?

 

I have been investigating a bit and find that the capture files that are 
in the wiky are correctly parser by ethereal (just send it over tcp, 
capture and decode as h223, it will decode perfectly).  


Hi Sergio!

Great news - I tried decoding manually (hex editor) and failed. How did 
you sent it via TCP - just with netcat?


regards
klaus



Perhaps the h223 parser and de gollay decoder of ethereal is a good 
point of start..






 


Sergio

 





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


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

Re: [asterisk-dev] ENUM changes: discussion

[Klaus Darilion]

On Wed, February 15, 2006 11:00, Mark Elkins said:
> On Tue, 2006-02-14 at 20:44 -0800, John Todd wrote:
>> I saw the changes to the ENUMLOOKUP function below, and one of them
>> raises a question in my mind.  It seems to be going backwards to
>> continue using the "enum.conf" file when this is easily specified in
>> the function call itself, or assuming the "default" of e164.arpa.
>> The RFC for ENUM describes e164.arpa as the "only" ENUM suffix, so
>> while I don't agree that it is the "only" suffix that is useful for
>> ENUM lookups, having it as a default seems perfectly reasonable.
>
> The RFC may state that e164.arpa is the one and only suffix - but in the
> real world - we need alternatives. For example - how many countries
> (governments?) are even aware that e164 exists? Certainly in South
> Africa - ICASA (the regulator) is aware of e164 - but does nothing.
> Meanwhile, there are a few thousand entries in e164.org for South
> Africa.

Just because of having e164.arpa the default one does not restrict the
usage to other trees. Any tree is supported. But if there is a default
tree, which one should it be? e164.org? e164.info?... IMO, the default
tree should be the standard one.

regards
klaus

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

Re: [asterisk-dev] ENUM changes: discussion

[Klaus Darilion]

Hi!

I agree with John.

regards
Klaus

On Wed, February 15, 2006 5:44, John Todd said:
>
> I saw the changes to the ENUMLOOKUP function below, and one of them
> raises a question in my mind.  It seems to be going backwards to
> continue using the "enum.conf" file when this is easily specified in
> the function call itself, or assuming the "default" of e164.arpa.
> The RFC for ENUM describes e164.arpa as the "only" ENUM suffix, so
> while I don't agree that it is the "only" suffix that is useful for
> ENUM lookups, having it as a default seems perfectly reasonable.
>
> Using .conf files when there is only one value in them seems to be
> wasteful and confusing.  The "h323driver" value is now meaningless
> (and should be removed) since the ENUMLOOKUP function no longer
> creates a "Dial" action.  So that narrows the number of features in
> enum.conf down to simply "search" and that doesn't do anything,
> either, since the ENUMLOOKUP function only searches through a single
> suffix.
>
> If the dialplan author wishes to search through multiple ENUM zone
> suffixes, it is not (IMHO) an overwhelming burden to use a simple
> "GotoIf" to analyize the results of the prior ENUMLOOKUP function to
> see if there is a value in there.
>
> I was rather hoping to have enum.conf become depreciated, and this
> change seems to go backwards a few steps and solidify it's rather
> confusing position in the config file directory.
>
> JT
>
>
>>
>>Author: kpfleming
>>Date: Tue Feb 14 16:20:14 2006
>>New Revision: 10065
>>
>>URL: http://svn.digium.com/view/asterisk?rev=10065&view=rev
>>Log:
>>warn people about ENUMLOOKUP counting change
>>
>>Modified:
>> trunk/UPGRADE.txt
>>
>>Modified: trunk/UPGRADE.txt
>>URL:
>>http://svn.digium.com/view/asterisk/trunk/UPGRADE.txt?rev=10065&r1=10064&r2=10065&view=diff
>>==
>>--- trunk/UPGRADE.txt (original)
>>+++ trunk/UPGRADE.txt Tue Feb 14 16:20:14 2006
>>@@ -40,8 +40,10 @@
>>modules.conf file then you will need to explicitly load the modules
>> that
>>contain the functions you want to use.
>>
>>-* The ENUM() function no longer supplies a default zone for
>>searching; instead,
>>-  it uses the default zone(s) defined in enum.conf.
>>+* The ENUMLOOP() function no longer supplies a default zone for
>>searching; instead,
>>+  it uses the default zone(s) defined in enum.conf. In addition, when
>> the 'c'
>>+  option (for counting the number of records is specified), but the
>>lookup fails
>>+  to match any records, the returned value will now be "0" instead of
>> blank.
>>
>>  The SIP channel:
>
>
> ___
> --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
>


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

Re: [Asterisk-Dev] startup

[Klaus Darilion]

Hi!

Take a look at the briStuff from junghanns.net. This patch includes 
res_watchdog.c, which sends keep alive to an ISDN failover switch (via 
serial connection). This sounds similar to the application you need.


klaus

himanshoo kumar saxena wrote:

Hi all,

I am new to asterisk and am looking for following information, any help will
be greatly appreciated.
When my asterisk starts, I want it to connect it to another server and then
continuously keep pinging that server by sending heartbeat messages. So in
asterisk, is there some way of specifying an app or some thing can be
started by asterisk at start up time and then this app can be on it's own,
having it's own logic?
Any ideas ?

-himanshoo

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




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

Re: [Asterisk-Dev] Q.956 Advice of Charge (AOC) - basic implementation now in CVS

[Klaus Darilion]

Hi!

Are there any news on Advice of Charge inegration into asterisk?

I understand the problem of relaying the AOC at teh end of the call in a 
bridged scenario. But is it possible to relay AOC-D messages during the 
call?


regards,
klaus


Frank Sautter wrote:

hi,

my patches for basic support of Advice of Charge Q.956 (AOC) are now in 
the cvs version of asterisk 
http://bugs.digium.com/bug_view_page.php?bug_id=0003843 .


The ROSE messages are decoded and encoded in libpri and delivered to 
chan_zap which is displaying the charged units as debug message.


At the moment the behaviour of a bridged channel does not allow to 
forward these AOC messages to another channel. The problem is, that the 
bridge is destroyed very early and there is no possibility to send the 
AOC messages to a connected PBX or to the CDR when they are received 
from the telco .


now, as the lowlevel part is done, maybe there are some decent 
developers with more insight into the channel bridging than me who can 
change the behaviour of a bridge when a call is hungup.


regards
 frank sautter
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev




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

Re: [Asterisk-Dev] ENUM multiple records handling

[Klaus Darilion]

Conroy, Lawrence (SMTP) wrote:
Hi Klaus, folks,
I beg to differ.
Your SIP proxy is no damn good if one of the NAPTRs is voice:X-iax2
(or voice:X-skype :), so it's a dangerous to assume that SIP is the
answer, now what was the question? In particular, I *strongly*
disagree with the argument that one should only having a single entry
in ENUM; this is poor advice.
Check out +878108781087810 for example (I'll let you argue with him :).
I agree with you - the thing I wanted to say was: Just by using several 
SIP NATPRs with different order does not imply that the caller will use 
serial forking.

Thus, if I want to have serial forking to all my sip contacs in all 
cases, I have to implement the logic inside an application (ser or 
asterisk) and publish only one sip NAPTR which points to the 
applications implementing the logic.

regards,
klaus
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

[Asterisk-Dev] help needed implementing H324M (UMTS Video)

[Klaus Darilion]

Hi all!
I investigae implementing a UMTS Video <-> SIP Video gateway in 
astersik. Currently I'm analyzing the asterisk code and reading the 
specifications (H.324M, H.223). I have several questions how to 
incorporate this into asterisk and hope that some of you can give me 
some answers. (If someone is already working on this, I would be happy 
to work with you)

First, I will give a very short introduction into H.324M. H.324M is 
basically the same as H.324 with some adaptions for mobile terminals - 
it uses the mobile levels of H.223 for better frame detection and error 
recovery. In case of ISDN, the setup procedure is similar to an audio 
call, except the "User information layer 1": (btw: the debug output of 
asterisk is wrong - it should be "H.324M" instead of "G.7xx 384k Video")

  < Bearer Capability (len= 3)
  Ext: 1  Q.931 Std: 0  Info transfer capability:
   Unrestricted digital information (8)
  Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
  Ext: 1  User information layer 1: G.7xx 384k Video (38)
After the channel is established, the setup procedure will proceed in 
the established B-channel. H.223 will be used to multiplex the various 
logical channels (audio, video, control) over the B-channel. One logical 
channel will be established implicitly for enabling call control using 
H.245. Depending on the mobile level of H.223, the H.223 packets will be 
delimited using HDLC flags (0110) (mobile level 0), 16 bit flags 
(level 1), or more complex flags (level 2 and 3). (You can also find a 
good and short introduction at: 
http://www.dilithiumnetworks.com/news/Media%20Coverage/IEEE_Multimedia_04July.pdf)

Immediately after establishing the B-channel, the 2 clients have to 
agree on a H.223 mobile level. Therefore they are consecutively sending 
the flags to indicate their mobile level capabillities. Simultaneously 
the clients are analyzing the received flags to identify the mobile 
level of the remote client. If the mobile levels differ, the clients 
have to fall back to a mobile level supported by both clients.

And now my questions/problems.
- Where should I implement this functionality? Should I write an 
application which does H.324 or should I modify the zaptel channel?

- Up to now I wrote s small application which uses f=ast_read(chan); to 
read a frame from the B-channel and later dumps the data to a file (for 
analyzing the received bit stream). Is there a better way to retrieve 
the unmodified stream from the B-channel? Is the order of bytes/bits in 
f->data the same as received on the B-channel? (I'm currently having 
some byte sex and byte order problems).

I'm willing to put effort in this gateway, but somehow I'm lost in the 
source code and help by some experts will help me to focus on the real 
problems. Btw: Is there a developer guide which describes the design of 
asterisk and the usage of zaptel?

Any help is greatly appreciated.
regards,
Klaus


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