gmane.comp.telephony.yate

Re: Javascript delete.

Ioana Stanciu — 2013-06-18T12:50:33

Hi,

Please look at the answers inline.

Ioana Stanciu

On Jun 18, 2013, at 3:11 PM, Francisco Olarte wrote:


As far as I am aware, no, there is no reference at the moment.


At this time, indeed, the msgTime() from a message cannot be accessed., but I will put in the request.

Re: T.38 Transcoding

Jakub Galus — 2013-06-18T12:37:09

Sorry for shameless advertisement (I'm an AudioCodes employee), but you can
do T.38<->G.711 on pretty much every AudioCodes E-SBC (without E1 loopbacks
etc.) starting from 5 concurrent calls ending with few thousands. And it
works well with YATE :)

BR,
Jakub


2013/6/6 ZZ Wave <zzwave-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: Javascript delete.

Ioana Stanciu — 2013-06-18T11:46:56

Hi,

Implementation of the delete operator is present in YATE since SVN revision 5397.
It is not present in YATE 4.3.0, so if want support for it, you should use the SVN version.

Regards,
Ioana Stanciu

On Jun 18, 2013, at 2:38 PM, Francisco Olarte wrote:

Javascript delete.

Francisco Olarte — 2013-06-18T11:38:47

Hello everybody.

I'm trying to make a javascript handler for a message and I've noticed
Yate's implementation does not seem to support the delete operator.

 With this test script:

var o = { a: 1, b: 2};
delete o.a;

I get the error :

20130618113234.226320 <JsCode:WARN> Evaluator error: Operator or separator
expected in line 2 at: o.a;
20130618113234.226329 <javascript:WARN> Failed to parse 'test' script:
test.js

And the lack of output from  [ fgrep -r '"delete"' yscript ] ( which finds
all the other keywords I throw at it ) seems to confirm this.

Can someone confirm if this is true and, if unsupported, if it's going to
be supported in a foreseeable future?

Francisco Olarte.

PS: I've found embeded javascript is a great tool, I'm using it for message
prefiltering before dispatching to an extmod billing backend, and needed
this to use an object for housekeeping.

SS7/SIGTRAN components for mobile operators - SCCP, TCAP, MAP and CAMEL

Abdul Hakeem — 2013-06-16T03:45:33

Hello,
Where can I get reading materials about Yate's support for SIGTRAN, MAP & CAMEL
?
Many thanks,
Abdul Hakeem

dtmf ysigchan ss7

2013-06-14T09:50:13

Hello

Is there a way to debug DTMF from Cisco SLT configuration ?
Does change from "dtmfinband=yes" to "dtmfinband=no" ysigchan.conf   
can be done by reload ? Or Restart is needed ?

How to check if "dtmfinband=no" or "dtmfinband=yes" work in system ?

Greetings
Andrzej

Important change in command line option

Paul Chitescu — 2013-06-13T09:34:46

Hi all!

Just committed SVN Rev. 5541 brings a change in the command line options that 
could affect your operation if upgrading.

The -Dd command line option now enables the global mutex and lock attempt 
counting instead of disabling them. The default is now to have them disabled 
to get better performance.

If you previously used -Dd in your server startup scripts to get better 
performance you will now need to remove that option.

Regards,

Paul

Re: Communication between H323 Clients not working

Jonatan Zint — 2013-06-11T12:11:39

Thank you for your reply!

As i don't have a network monitoring device it's difficult for me to
capture the Traffic between gatekeeper and phones. I did capture a much
more verbose log. Unfortunately it doesn't say anything understandable
for me. I attached it... The part where a call is done is when this
message is looping:

  1:25.787              GkSrv Monitor        gkserver.cxx(4159)   
RAS    Aging registered endpoints
  1:25.793              GkSrv Monitor        safecoll.cxx(126)   
SafeColl    Increment reference count to 2 for H323RegisteredEndPoint
0xaf498
  1:25.806              GkSrv Monitor        safecoll.cxx(136)   
SafeColl    Decrement reference count to 1 for H323RegisteredEndPoint
0xaf498
  1:25.826              GkSrv Monitor        safecoll.cxx(126)   
SafeColl    Increment reference count to 2 for H323RegisteredEndPoint
0xb1e90
  1:25.841              GkSrv Monitor        safecoll.cxx(136)   
SafeColl    Decrement reference count to 1 for H323RegisteredEndPoint
0xb1e90
  1:26.865              GkSrv Monitor        gkserver.cxx(4159)   
RAS    Aging registered endpoints

This happens for 10 seconds - then busy tone....

I hope you can help me with this information...

And thanks again, you might rescue me ;)



Am 11.06.2013 10:56, schrieb Marian Podgoreanu:

Re: Communication between H323 Clients not working

Marian Podgoreanu — 2013-06-11T08:56:21

Hi,

Can you attach a wireshark capture of the call?

Or set debug=10 in 'general' section of h323chan.conf, restart yate, 
make a call and attach the log.

Marian

On 6/10/2013 6:12 PM, Jonatan Zint wrote:

Communication between H323 Clients not working

Jonatan Zint — 2013-06-10T15:12:33

Hello,

i'm kind of desperate... Since hours i'm trying to get our H323 Phones
to work... Yate should serve as Gatekeeper an later as gateway to the
world of SIP.... But i'm hangig on communicating between the h323
phones. They're registering properly, but when i attempt to call one of
them Yate is giving me negative feedback and a log output i don't
understand.... I really hope someone could help me out here:

<RegFile:INFO> Routed '314' via 'h323/314-Q0ErXNX1RuZww3PfpbIDCw< at >public.gmane.org:1720'
  5:37.803           Transactor:8c890        gkserver.cxx(1435)   
B-Exit    <========= H323GatekeeperCall::OnAdmission
  5:37.842           Transactor:8c890        gkserver.cxx(3742)   
B-Exit    <(3742)    B-Exit    <========= H323GatekeeperServer::OnAdmission
  5:37.882                Transactor:8c890            
gkserver.cxx(2869)     gkserver.cxx(2869)    B-Exit    <==== 
H323GatekeeperListener::OnAdmission
  5:37.919           Transactor:8c890        gkserver.cxx(664)   
B-Entry    =)    B-Entry    ====> H323GatekeeperRequest::WritePDU
  5:37.962           Transactor:8c890        gkserver.cxx(664)    )   
B-Exit    <==== H323GatekeeperRequest::WritePDU
  5:38.014           Transactor:8c890        gkserver.cxx(2911)   
B-Exit    <== H323GatekeeperListener::OnReceiveAdmissionRequest
  5:53.062           Transactor:8c890        gkserver.cxx(2995)   
B-Entry    ==> H323GatekeeperListener::OnReceiveDisengageRequest
  5:53.110           Transactor:8c890        gkserver.cxx(2977)   
B-Entry    ====> H323GatekeeperListener::OnDisengage
  5:53.154           Transactor:8c890        gkserver.cxx(3812)   
B-Entry    ======> H323GatekeeperServer::OnDisengage
  5:53.194           Transactor:8c890               
gkserver.cxx(1708)    B-Entry    ========>
H323GatekeeperCall::OnDisengageH323GatekeeperCall::OnDisengage
  5:53.236           Transactor:8c890       Transactor:8c890       
gkserver.cxx(1708)    B-Exit    <===B-Exit    <=========
H323GatekeeperCall::OnDisengage
  5:53.286           Transactor:8c890        gkserver.cxx(3812)   
B-Exit    <====== H323GatekeeperServer::OnDisengage
  5:53.322           Transactor:8c890        gkserver.cxx((2977)   
B-Exit    <==== H323GatekeeperListener::OnDisengage
  5:53.362             Transactor:8c890         gkserver.cxx(664)   
B-Entry    =====> H323GatekeeperRequest::WritePDU
  5:53.421           Transactor:8c890        gkserver.cxx(664)   
B-Exit    <==== H323GatekeeperRequest::WritePDU
  5:53.463           Transactor:8c890        gkserver.cxx(2995)   
B-Exit    <== H323GatekeeperListener::OnReceiveDisengageRequest

After that busy tone in the callers phone, and destination phone didn't
ring at all

best regards,

Jonatan Zint

Re: where to put route_params in xsip.generate message?

Marian Podgoreanu — 2013-06-10T07:28:40

Hi,

When you are generating a message the correct parameter to set is 
'connection_id'.
You should get it from 'user.register' message sent for an incoming 
registration.

'oconnection_id' is used by outgoing calls (it is set on 'route_params' 
to be used when routing a call).

Marian

On 6/9/2013 12:09 PM, Alexey Elfman wrote:

where to put route_params in xsip.generate message?

Alexey Elfman — 2013-06-09T09:09:08

Hello.

I'm playing with tcp connection with my custom backend and next step I
stuck with - generated messages.

Example message dispatched from backend to sip-client:

[Sun, 09 Jun 2013 11:58:56]    DEBUG  Dispatching message
(id:4c4203516bedbc049aa06b49a81aa0a8):
%%>message:4c4203516bedbc049aa06b49a81aa0a8:1370768336:xsip.generate:None:sip_Event=check-sync:method=NOTIFY:uri=sip%z061< at >212.*.*.1%z61155;transport=tcp

This message was sent via UDP, but extension is registered via TCP
with correct route_params data.

I tried to pass route_params in url, but with no success.

Where I need to put route_params in xsip.generate message?
http://yate.null.ro/pmwiki/index.php?n=Main.Xsipgenerate can't help me in it.

I tried to encode params like this

[Sun, 09 Jun 2013 12:07:37]    DEBUG  Dispatching message
(id:3ac61b63a7489be77a4dada2a8bb4522):
%%>message:3ac61b63a7489be77a4dada2a8bb4522:1370768857:xsip.generate:None:sip_Event=check-sync:method=NOTIFY:uri=sip%z061< at >212.*.*.1%z61155;transport=tcp;oconnection_id=tcp%%z178.*.*.21%%z5060-212.*.*.1%%z61155

But this send full oconnection_id in SIP NOTIFY udp packet at all :)
May be I forgot to encode some characters in message?

Re: T.38 Transcoding

ZZ Wave — 2013-06-06T21:24:07

We use E1 loopback on Mediant2000 to convert fax between 711 bypass and
T.38. I think it can be done on any E1-to-SIP gateway, but this is anyway
pretty expensive :(


I've heard latest Asterisk has some features about G.711<->T.38, but I
don't try it yet.


2013/5/18 Philipp Hoffmann <phoffmann10-mVuRI66OGLPQT0dZR+AlfA< at >public.gmane.org>

Re: Binding problem for outgoing h323 calls

Roman Zhilov — 2013-06-03T13:53:13

Now in packets to the address 4.4.4.4 the address of a source 2.2.2.2 is
specified.

Re: Binding problem for outgoing h323 calls

Roman Zhilov — 2013-06-03T13:48:35

Hi,

My server is OSPF router on the QUAGGA in my network and the address
loopback interface 3.3.3.3 is available from everywhere.

Networks 1.1.1.0/24 and 2.2.2.0/24 are used for management. The network
3.3.3.0/24 is used for voice services on the loopback interfaces or servers
with quagga (ospf).

netstat -anr
Kernel IP routing table
Destination      Gateway         Genmask          Flags   MSS Window  irtt
Iface
3.3.3.1    2.2.2.1  255.255.255.255  UGH       0 0          0 eth1
3.3.3.2   2.2.2.3  255.255.255.255  UGH       0 0          0 eth1
3.3.3.4    2.2.2.4  255.255.255.255  UGH       0 0          0 eth1
3.3.3.5    2.2.2.5  255.255.255.255  UGH       0 0          0 eth1
3.3.3.6   2.2.2.6  255.255.255.255  UGH       0 0          0 eth1
3.3.3.7    2.2.2.7  255.255.255.255  UGH       0 0          0 eth1
3.3.3.8   2.2.2.8  255.255.255.255  UGH       0 0          0 eth1
3.3.3.9    2.2.2.9  255.255.255.255  UGH       0 0          0 eth1
2.2.2.0  0.0.0.0          255.255.255.0  U         0 0          0 eth1
1.1.1.0  0.0.0.0          255.255.255.0  U         0 0          0 eth0
0.0.0.0          2.2.2.254  0.0.0.0          UG        0 0          0 eth1

Thanx!


2013/6/3 Roman Zhilov <r.zhilov-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: T.38 Transcoding

Paul Chitescu — 2013-06-03T13:23:33

Hi!

Sorry it got so long to answer.

There is currently no support for T.38 to G.711 gatewaying. If we add it it 
will definitely not be in the 2.x branch.

Paul


On Friday 17 May 2013 11:12:45 pm Philipp Hoffmann wrote:

Re: Binding problem for outgoing h323 calls

Paul Chitescu — 2013-06-03T13:21:34

Hi!

Your IP configuration is weired. As far as I can tell the 3.3.3.3 address has 
no route anywhere but itself.

What are your IP routes? What source address would have packets going to 
destination 4.4.4.4 ?

Did you set up some special routing rules for that interface?

Paul


On Saturday 01 June 2013 08:49:58 pm Roman Zhilov wrote:

map SS7ISUPCall to peerid/targetid

2013-06-02T09:42:28

Hello,

We've implemented four-wire Continuity Testing with Sangoma cards in Yate,
but are missing a bit of information before we can submit our changes.

We added a `masquerade` function in SigSS7Isup, and we think we are
properly retrieving the matching call:
https://github.com/shimaore/yate/blob/master%2Bshimaore/modules/server/ysigchan.cpp#L3705

However we don't know how to retrieve the `peerid` and `targetid` to
complete the masquerade operation. Any help would be appreciated!
S.

Binding problem for outgoing h323 calls

Roman Zhilov — 2013-06-01T17:49:58

Hi,

My server has some network interfaces:
eth0      Link encap:Ethernet  HWaddr 00:11:09:FC:9F:D6
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0

eth1      Link encap:Ethernet  HWaddr 00:11:09:FC:9F:D7
         inet addr:2.2.2.2  Bcast:2.2.2.255  Mask:255.255.255.0

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0

lo:0      Link encap:Local Loopback
          inet addr:3.3.3.3  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

And the main address for voice services: 3.3.3.3 interface lo:0

I use YATE 4.3.0-1 as SIP-H323 converter.

There is a problem: at proceeding outgoing h323 call of Yate uses the
signaling source address of the 1.1.1.1 or 2.2.2.2 but not the address
3.3.3.3

h323chan.conf:
[general]
external_rtp=yes
passtrough_rtp=enable

[codecs]
default=no
mulaw=yes
alaw=yes
g723=yes
g729=yes

[ep]
ep = true
addr=3.3.3.3
port=1720
alias = yate
ident = yate
faststart=true
h245tunneling=true
gkclient = false

regexroute.conf:
^123456789$=h323/123456789< at >4.4.4.4:1720

I very much would like to use the 3.3.3.3 as the signaling source address
at proceeding outgoing h323 call.

Please help me with it!

Best regards!
Roman Zhilov

Ping!

Paul Chitescu — 2013-05-29T09:30:35

Just ignore this test. Thanks!

T.38 Transcoding

Philipp Hoffmann — 2013-05-17T20:12:45

Hi,

I am trying to realize T.38 transcoding with Yate:

A  (SIP)--> Yate (SIP) --> Carrier (SIP) --> B (ISDN)

A supports T.38 (but no g711), the Carrier does *not* support T.38. That means, that Yate needs to transcode T.38 to g711.

How can I configure this case in Yate?

We use YATE 2.2.0-1 (default debian package).

Regards,
Philipp.