sr-users April 2003

sr-users@lists.kamailio.org

69 participants
115 discussions

Re: [Serusers] problem with cisco 2600 to pstn
by Yang Xiang 25 Apr '03

25 Apr '03

Hi Jiri, it works! Thank you very much! The voice-port block is the key: ------------------------------- voice-port 1/0/0 compand-type a-law cptone DE bearer-cap Speech ------------------------------ yang ----- Original Message ----- From: "Jiri Kuthan" <jiri(a)iptel.org> To: "Yang Xiang" <yang.xiang(a)iitb.fraunhofer.de> Sent: Friday, April 25, 2003 5:21 PM Subject: Re: [Serusers] problem with cisco 2600 to pstn > try to look at our config at http://www.iptel.org/~jiri/etc/cisco/ios_2003.txt > if it helps you. I think we had the same problem, changed some settings and it > worked then. I unfornantely don't remember what it was. > > -Jiri > > At 04:54 PM 4/25/2003, you wrote: > >Hi all, > > > >I am expericing problem with the cisco 2600, which should function as the > >sip2pstn gateway. If I try to complete a call from a sip phone to pstn, the > >router says: > >------------------------------------------------------------------------ > > 00:15:49: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x03 > >00:15:49: Bearer Capability i = 0x8090A2 > > ^^^^^^ > >00:15:49: Channel ID i = 0x83 > >00:15:49: Progress Ind i = 0x8181 - Call not end-to-end ISDN, may > >have in-band info > >00:15:49: Calling Party Number i = 0x80, 'yang2', Plan:Unknown, > >Type:Unknown > >00:15:49: Called Party Number i = 0xC9, '6091574', Plan:Private, > >Type:Subscriber(local) > >00:15:49: ISDN BR1/0: RX <- SETUP_ACK pd = 8 callref = 0x83 > >00:15:49: Channel ID i = 0x89 > >00:15:49: Progress Ind i = 0x8188 - In-band info or appropriate now > >available > >00:15:49: ISDN BR1/0: RX <- DISCONNECT pd = 8 callref = 0x83 > >00:15:49: Cause i = 0x80C1 - Bearer capability not implemented > > > >^^^^^^^^^^^^^^^^^^^^^^^^^^ > >00:15:49: Progress Ind i = 0x8188 - In-band info or appropriate now > >available > >--------------------------------------------------------------------------- - > >------------ > > > >Please notice the line "Bearer Capability i = 0x8090A2", the digits "80" > >mean that this is a ITU voice call, "90" mean circuit mode, 64 kbps and "A2" > >is for G.711 u-law. > > > >So if I call the router from a normal telephone, the debugging looks as > >follows: > >--------------------------------------------------------------------------- - > >---- > >01:01:58: ISDN BR1/0: RX <- SETUP pd = 8 callref = 0x01 > >01:01:58: Bearer Capability i = 0x8090A3 > > ^^^ > >01:01:58: Channel ID i = 0x89 > >01:01:58: Calling Party Number i = 0x0181, '609157', Plan:ISDN, > >Type:Unknown > >01:01:58: Called Party Number i = 0xC1, '20', Plan:ISDN, > >Type:Subscriber(local) > >01:01:58: High Layer Compat i = 0x9181 > >01:01:58: ISDN BR1/0: Event: Received a VOICE call from 609157 on B1 at 64 > >Kb/s > >--------------------------------------------------------------------------- - > >--------- > > > >whereat the bearer capability is "0x8090A3". It means that the ISDN-switch > >of German Telekom uses G.711 a-law. > > > >I am afraid that is the reason why the sip-call doesn't go through. But I > >can't find any way to configure this. > > > >Has anybody in this mailinglist the same experience? > > > >Any hints would be very appreciated. > > > >Thanks > > > >yang > > > > > > > > > > > > > >_______________________________________________ > >Serusers mailing list > >serusers(a)lists.iptel.org > >http://lists.iptel.org/mailman/listinfo/serusers > > -- > Jiri Kuthan http://iptel.org/~jiri/ > >

1 0

[Serusers] SERAdmin program in development to benefit all SER administrators
by Xten India 25 Apr '03

25 Apr '03

Hi , Xten Networks, Inc. (www.xten.com) is pleased to announce it is making a contribution to the SER project. The Xten SER Team is comprised of 2 senior engineers and 1 project manager who are committed full-time to the development of SERAdmin.SERAdmin is a GUI interface between SIP Express Router (SER) and the SER administrator. Project location (http://developer.berlios.de/projects/seradmin/) SERAdmin provides control over many SER tasks such as: start, stop, pause, re-start, monitor, add user, edit user, etc. SERAdmin has an intuitive look and feel.SERAdmin is open source, is being developed to benefit all SER administrators, and the feature set of SERAdmin will be determined by the iptel.org SER users' group.So please communicate with the Xten SER Team, post your comments in the public forums, and make use of the Xten SER Team as they are working for the SER community. About Xten (www.xten.com) Xten Networks, Inc. is a leading provider of high-quality SIP Voice over Internet Protocol (VoIP) software. Xten provides IP Telephony products directly to end users, the Enterprise market, Next-Gen Service Providers (ITSPs & Tier 2), Wireless Internet Service Providers (WISPs), Telephone Companies (TELCOs), and Original Equipment Manufacturers (OEMs). Regards,Xten Team --------------------------------- Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo.

3 2

[Serusers] problem with cisco 2600 to pstn
by Yang Xiang 25 Apr '03

25 Apr '03

Hi all, I am expericing problem with the cisco 2600, which should function as the sip2pstn gateway. If I try to complete a call from a sip phone to pstn, the router says: ------------------------------------------------------------------------ 00:15:49: ISDN BR1/0: TX -> SETUP pd = 8 callref = 0x03 00:15:49: Bearer Capability i = 0x8090A2 ^^^^^^ 00:15:49: Channel ID i = 0x83 00:15:49: Progress Ind i = 0x8181 - Call not end-to-end ISDN, may have in-band info 00:15:49: Calling Party Number i = 0x80, 'yang2', Plan:Unknown, Type:Unknown 00:15:49: Called Party Number i = 0xC9, '6091574', Plan:Private, Type:Subscriber(local) 00:15:49: ISDN BR1/0: RX <- SETUP_ACK pd = 8 callref = 0x83 00:15:49: Channel ID i = 0x89 00:15:49: Progress Ind i = 0x8188 - In-band info or appropriate now available 00:15:49: ISDN BR1/0: RX <- DISCONNECT pd = 8 callref = 0x83 00:15:49: Cause i = 0x80C1 - Bearer capability not implemented ^^^^^^^^^^^^^^^^^^^^^^^^^^ 00:15:49: Progress Ind i = 0x8188 - In-band info or appropriate now available ---------------------------------------------------------------------------- ------------ Please notice the line "Bearer Capability i = 0x8090A2", the digits "80" mean that this is a ITU voice call, "90" mean circuit mode, 64 kbps and "A2" is for G.711 u-law. So if I call the router from a normal telephone, the debugging looks as follows: ---------------------------------------------------------------------------- ---- 01:01:58: ISDN BR1/0: RX <- SETUP pd = 8 callref = 0x01 01:01:58: Bearer Capability i = 0x8090A3 ^^^ 01:01:58: Channel ID i = 0x89 01:01:58: Calling Party Number i = 0x0181, '609157', Plan:ISDN, Type:Unknown 01:01:58: Called Party Number i = 0xC1, '20', Plan:ISDN, Type:Subscriber(local) 01:01:58: High Layer Compat i = 0x9181 01:01:58: ISDN BR1/0: Event: Received a VOICE call from 609157 on B1 at 64 Kb/s ---------------------------------------------------------------------------- --------- whereat the bearer capability is "0x8090A3". It means that the ISDN-switch of German Telekom uses G.711 a-law. I am afraid that is the reason why the sip-call doesn't go through. But I can't find any way to configure this. Has anybody in this mailinglist the same experience? Any hints would be very appreciated. Thanks yang

1 0

[Serusers] msg's not reaching all the way
by magnus melin 25 Apr '03

25 Apr '03

hey all! We´re struggeling with a problem since some time now. We hade set up an SER - jabber environment, the applications are running on differnt servers. SIP-client -------(sip (udp) ) --------> SER-server -----------> Jabber-server ------(xml (tcp) ) -------> Jabber-client <------------------------------ <---------- <---- <------- Now to the problem. There is no problem with registration on either sides, and one can send a msg from the SIP- client to jabber-client, but when responding from jabber to SIP, the SER sends two MESSAGE to the sip-client and get two 400 BAD REQUEST (frame 11 & 12 ) back from the client, and then the jabber-client goes "away" (frame 19) (losses the tcp-handle ?) In short: a message is sent from the sipclient to the jabberclient, the response from the jabberclient wont display on the sip-client. Though it looks like in etherreal that the msg reaches all the way to the sip-client. We have both loose_route() and record_route() (see ser.cfg_jabber attached). Thank's Best Reg Anna & Magnus Frame 7 (520 on wire, 520 captured) Frame Number: 7 Linux cooked capture Packet type: Unicast to us (0) Source: <MISSING> Protocol: IP (0x0800) Internet Protocol, Src Addr: dhcp164-devel (172.18.3.164), Dst Addr: dhcp164-devel (172.18.3.164) Version: 4 Total Length: 504 Time to live: 64 Protocol: UDP (0x11) Source: dhcp164-devel (172.18.3.164) Destination: dhcp164-devel (172.18.3.164) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 484 Checksum: 0xb971 (correct) Session Initiation Protocol Request line: MESSAGE sip:x@e-horizon.se SIP/2.0 Message Header Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKa858.b1ed4bd6.0 To: sip:x@e-horizon.se From: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se>;tag=949cc72a86e24d5dcb2bf51338531b31-4809 CSeq: 10 MESSAGE Call-ID: 38231eab-9474(a)172.18.3.164 Content-Length: 20 User-Agent: Sip EXpress router(0.8.11pre13 (i386/linux)) Content-Type: text/plain Contact: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se> Session Description Protocol Invalid line: bbbbbbbbbbbbbbbbbbbb Frame 8 (674 on wire, 674 captured) Linux cooked capture Packet type: Sent by us (4) Link-layer address type: 1 Link-layer address length: 6 Protocol: IP (0x0800) Internet Protocol, Src Addr: dhcp164-devel (172.18.3.164), Dst Addr: shot.e-horizon.se (172.18.1.66) Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xdb50 (correct) Source: dhcp164-devel (172.18.3.164) Destination: shot.e-horizon.se (172.18.1.66) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 7203 (7203) Source port: 5060 (5060) Destination port: 7203 (7203) Length: 638 Checksum: 0x6016 (correct) Session Initiation Protocol Request line: MESSAGE sip:172.18.1.66:7203 SIP/2.0 Message Header Record-Route: <sip:x@172.18.3.164:5060;ftag=949cc72a86e24d5dcb2bf51338531b31-4809;lr> Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bK8984.7c66ebe.0 Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKa858.b1ed4bd6.0 To: sip:x@e-horizon.se From: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se>;tag=949cc72a86e24d5dcb2bf51338531b31-4809 CSeq: 10 MESSAGE Call-ID: 38231eab-9474(a)172.18.3.164 Content-Length: 20 User-Agent: Sip EXpress router(0.8.11pre13 (i386/linux)) Content-Type: text/plain Contact: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se> Session Description Protocol Invalid line: bbbbbbbbbbbbbbbbbbbb Frame 9 (520 on wire, 520 captured) Linux cooked capture Source: <MISSING> Protocol: IP (0x0800) Internet Protocol, Src Addr: dhcp164-devel (172.18.3.164), Dst Addr: dhcp164-devel (172.18.3.164) Protocol: UDP (0x11) Header checksum: 0xd988 (correct) Source: dhcp164-devel (172.18.3.164) Destination: dhcp164-devel (172.18.3.164) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 484 Session Initiation Protocol Request line: MESSAGE sip:x@e-horizon.se SIP/2.0 Message Header Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKa858.b1ed4bd6.0 To: sip:x@e-horizon.se From: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se>;tag=949cc72a86e24d5dcb2bf51338531b31-4809 CSeq: 10 MESSAGE Call-ID: 38231eab-9474(a)172.18.3.164 Content-Length: 20 User-Agent: Sip EXpress router(0.8.11pre13 (i386/linux)) Content-Type: text/plain Contact: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se> Session Description Protocol Invalid line: bbbbbbbbbbbbbbbbbbbb Frame 10 (674 on wire, 674 captured) Arrival Time: Apr 23, 2003 15:28:20.284421000 Linux cooked capture Packet type: Sent by us (4) Link-layer address type: 1 Link-layer address length: 6 Protocol: IP (0x0800) Internet Protocol, Src Addr: dhcp164-devel (172.18.3.164), Dst Addr: shot.e-horizon.se (172.18.1.66) Version: 4 Header length: 20 bytes Protocol: UDP (0x11) Header checksum: 0xdb50 (correct) Source: dhcp164-devel (172.18.3.164) Destination: shot.e-horizon.se (172.18.1.66) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 7203 (7203) Source port: 5060 (5060) Destination port: 7203 (7203) Session Initiation Protocol Request line: MESSAGE sip:172.18.1.66:7203 SIP/2.0 Message Header Record-Route: <sip:x@172.18.3.164:5060;ftag=949cc72a86e24d5dcb2bf51338531b31-4809;lr> Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bK8984.7c66ebe.0 Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKa858.b1ed4bd6.0 To: sip:x@e-horizon.se From: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se>;tag=949cc72a86e24d5dcb2bf51338531b31-4809 CSeq: 10 MESSAGE Call-ID: 38231eab-9474(a)172.18.3.164 Content-Length: 20 User-Agent: Sip EXpress router(0.8.11pre13 (i386/linux)) Content-Type: text/plain Contact: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se> Session Description Protocol Invalid line: bbbbbbbbbbbbbbbbbbbb Frame 11 (474 on wire, 474 captured) Arrival Time: Apr 23, 2003 15:28:20.285190000 Linux cooked capture Packet type: Unicast to us (0) Link-layer address type: 1 Link-layer address length: 6 Source: 00:05:5d:03:03:1e (D-Link_03:03:1e) Protocol: IP (0x0800) Internet Protocol, Src Addr: shot.e-horizon.se (172.18.1.66), Dst Addr: dhcp164-devel (172.18.3.164) Time to live: 127 Protocol: UDP (0x11) Header checksum: 0x765a (correct) Source: shot.e-horizon.se (172.18.1.66) Destination: dhcp164-devel (172.18.3.164) User Datagram Protocol, Src Port: 3173 (3173), Dst Port: 5060 (5060) Source port: 3173 (3173) Destination port: 5060 (5060) Length: 438 Checksum: 0x8c6c (correct) Session Initiation Protocol Status line: SIP/2.0 400 Bad Request Message Header Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bK8984.7c66ebe.0 Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKa858.b1ed4bd6.0 From: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se>;tag=949cc72a86e24d5dcb2bf51338531b31-4809 To: sip:x@e-horizon.se;tag=199332f8-e402-4795-833a-c90969c979b0 Call-ID: 38231eab-9474(a)172.18.3.164 CSeq: 10 MESSAGE User-Agent: Windows RTC/1.0 Content-Length: 0 Frame 12 (409 on wire, 409 captured) Arrival Time: Apr 23, 2003 15:28:20.288277000 Linux cooked capture Packet type: Unicast to us (0) Link-layer address type: 772 Link-layer address length: 0 Source: <MISSING> Protocol: IP (0x0800) Internet Protocol, Src Addr: dhcp164-devel (172.18.3.164), Dst Addr: dhcp164-devel (172.18.3.164) Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xd9f7 (correct) Source: dhcp164-devel (172.18.3.164) Destination: dhcp164-devel (172.18.3.164) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 373 Checksum: 0x4b0e (correct) Session Initiation Protocol Status line: SIP/2.0 400 Bad Request Message Header Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKa858.b1ed4bd6.0 From: <sip:b*storstark.e-horizon.se@jstorstark.e-horizon.se>;tag=949cc72a86e24d5dcb2bf51338531b31-4809 To: sip:x@e-horizon.se;tag=199332f8-e402-4795-833a-c90969c979b0 Call-ID: 38231eab-9474(a)172.18.3.164 CSeq: 10 MESSAGE User-Agent: Windows RTC/1.0 Content-Length: 0 . . . . Frame 19 (530 on wire, 530 captured) Frame Number: 19 Internet Protocol, Src Addr: dhcp164-devel (172.18.3.164), Dst Addr: dhcp164-devel (172.18.3.164) Version: 4 Header length: 20 bytes Time to live: 64 Protocol: UDP (0x11) Source: dhcp164-devel (172.18.3.164) Destination: dhcp164-devel (172.18.3.164) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Session Initiation Protocol Request line: MESSAGE sip:x@e-horizon.se SIP/2.0 Message Header Via: SIP/2.0/UDP 172.18.3.164:5060;branch=z9hG4bKb649.52575b6.0 To: sip:x@e-horizon.se From: <sip:sip_to_jabber_gateway>;tag=949cc72a86e24d5dcb2bf51338531b31-dc30 CSeq: 10 MESSAGE Call-ID: 38231eac-9474(a)172.18.3.164 Content-Length: 85 User-Agent: Sip EXpress router(0.8.11pre13 (i386/linux)) Content-Type: text/plain Contact: <sip:sip_to_jabber_gateway> Session Description Protocol Invalid line: INFO: Your are now offline in Jabber network. Thank you for using SIP-Jabber gateway.

2 2

[Serusers] serweb & usrloc
by kelch 25 Apr '03

25 Apr '03

hi! is serweb intended to just send IM one-way? i configured everything and noticed that i can only send messages from a web-client (via serweb) to a sip softphone, but not the other way around. i noticed that this is due to the fact that when a user logs on to serweb, it does not put anything in the location table in ser db. so if a message was sent intended for that user, the sender receives 404 not found (due to failure in lookup()). what i am thinking as a workaround is to manipulate the php files in serweb to insert the user into the 'location' table via fifo, the method though crude might just work... my problem is, before i could try to do the workaround is whether serweb would accept the message if it indeed received one on port 5060? would it? or should the proxy send the message through another port like 80?

2 1

[Serusers] MOTOROLA T720i ��:229$
by 236553＠delphi.com 25 Apr '03

25 Apr '03

1 0

Re: [Serusers] Testing Concurrent Calls
by Jiri Kuthan 24 Apr '03

24 Apr '03

I'm not aware of an affordable stress tools which covers both media and signaling. -Jiri At 03:50 PM 4/24/2003, Alejandro Olchik wrote: >I would like to start multiple simultaneous calls >(let's say around 30), and keep calls active to >test concurrency. > >Any suggestion how can I do that without requiring >expensive software for that? > >I have enough ports to terminate the calls using >G729 but I don't know what to use for originate them. > >Regards, >Alejandro > > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Jiri Kuthan http://iptel.org/~jiri/

1 0

[Serusers] how configure ser for pstn?
by Yang Xiang 24 Apr '03

24 Apr '03

Hi all, I put following config in the main routing-block for forwarding INVITE-msg to pstn-gatway: ... route{ ... if (!t_relay()) { sl_reply_error(); }; # forward message to PSTN Gateway if (uri=~"^sip:[0-9]*@"){ log(5, "Forward to pstn \n"); forward("10.20.0.6"); break; }; } However, SER doesn't do it and sends a reply "404 not found" back instead. Is it the correct position to put the function "forward()" there? By the way, ser also doesn't write log message to syslog. Following is my syslog.conf, is anything wrong in the syslog.conf? #ident "@(#)syslog.conf 1.5 98/12/14 SMI" /* SunOS 5.0 */ # # Copyright (c) 1991-1998 by Sun Microsystems, Inc. # All rights reserved. # # syslog configuration file. # # This file is processed by m4 so be careful to quote (`') names # that match m4 reserved words. Also, within ifdef's, arguments # containing commas must be quoted. # *.debug;*.notice;*.info;*.crit;*.alert /var/log/debug *.err;kern.notice;auth.notice /dev/sysmsg *.err;kern.debug;daemon.notice;mail.crit /var/adm/messages *.alert;kern.err;daemon.err operator *.alert root *.emerg * # if a non-loghost machine chooses to have authentication messages # sent to the loghost machine, un-comment out the following line: #auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost) mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost) # # non-loghost machines will use the following lines to cause "user" # log messages to be logged locally. # user.err /dev/sysmsg user.err /var/adm/messages user.alert `root, operator' user.emerg * auth.info /var/adm/messages local6.debug /var/adm/imapd.log auth.debug /var/adm/auth.log Thanks, Yang

2 1

[Serusers] Testing Concurrent Calls
by Alejandro Olchik 24 Apr '03

24 Apr '03

I would like to start multiple simultaneous calls (let's say around 30), and keep calls active to test concurrency. Any suggestion how can I do that without requiring expensive software for that? I have enough ports to terminate the calls using G729 but I don't know what to use for originate them. Regards, Alejandro

1 0

[Serusers] notify
by Kelvin Chua 24 Apr '03

24 Apr '03

how do you send notify? sl_send_reply("200","notify")? i don't think this is correct, i can't seem to find anything about it in the docs?

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users April 2003