sr-users

sr-users@lists.kamailio.org

37302 discussions

Re: [Serusers] information about registered users

by Jiri Kuthan

At 12:14 PM 4/30/2003, radan(a)nasty.gda.pl wrote: >Hello all ! >I'm new user of ser :) > >I'd like have a information about registered users in my syslog > > save("location"); > log(3,"REGISTER zarejestrowany uzytkownik $USER"); > sl_send_reply("200", "ok"); ^^^^^^ > break; > }; > > >is some variable to use ? currently not. We are planning it for the future. -Jiri

21 years, 7 months

[Serusers] information about registered users

by radan＠nasty.gda.pl

Hello all ! I'm new user of ser :) I'd like have a information about registered users in my syslog save("location"); log(3,"REGISTER zarejestrowany uzytkownik $USER"); sl_send_reply("200", "ok"); ^^^^^^ break; }; is some variable to use ? Andrzej Radke sip:radan@task.gda.pl

21 years, 7 months

[Serusers] How to calculate new HASH_TABLE_SIZE value when extending parser?

by Maxim Sobolev

Hi, I am currently trying to extend ser's parser to allow it recognize User-Agent headers, but stuck into the magic HASH_TABLE_SIZE value. Is there any algorithm to calculate it when adding support for a new header type? Maybe there is some documentation, apart from comments in the code itself, on extending parser, or at least on its inner details? If so, it would be nice to obtain it if possible. Thanks! -Maxim

21 years, 7 months

[Serusers] Extending usrloc module to allow to save User-Agent values [patch for review]

by Maxim Sobolev

Folks, Attached please find a patch, which extends usrloc/registrar modules to save values from User-Agent field in REGISTER messages into the database. It would be nice to have it included into the next release. Please disregard hackish detection of User-Agent fields, I am currently working on extending parser to recognize that type of field. I'll post updated patch when finished. Also, there is a new unrelated function which can be used to retrieve full list of all currently registered users in all domains. I am using this function in new version of my nathelper modules to do periodical UDP "pinging" of all registered users to keep their NAT bindings alive. I would like to have it reviewed and included into the next release as well. Thanks! -Maxim

21 years, 7 months

Re: [Serusers] Load Balancing

by Jiri Kuthan

At 03:33 PM 4/22/2003, Alejandro Olchik wrote: >I need some help to implement load balance >when sending invites to an external sip >proxy server. > >I would like to be able to balance load >between to IPs (10.0.0.1 and 10.0.0.2) and >use the backup IP when the primary one >fails. > >Below is the routing code I have: > > > if (!lookup("location")) { > rewritehost("10.0.0.1"); > if (!t_relay_to("10.0.0.1","5060")) { > sl_send_reply("404", "Not Found"); > }; > break; > }; > >How can I add this behaviour? That depends on the distribution scheme you would like to use. For example, you can implement a distribution function that splits requests based on some downstream weights. e.g., modparam("distrib", "weights", # ... # rewrite host-part with one of values using the distribution # 20-30-50 distribute("10.0.0.1/20%, 10.0.0.2/30%, 10.0.0.3/50%) t_on_negative("1") t_relay_to(); # ... reply_route[1] { # look at destinations that failed, and update their probabilities # according to some strategy; for example, temporary 0% weight -- # note that this would take shared memory for keeping the weights # and a timer update_weights(); # if coupled to TM, it can look at previous attempts to eliminate # retrying to a previously failed destination distribute("10.0.0.1/20%, 10.0.0.2/30%, 10.0.0.3/50%) } -Jiri

21 years, 7 months

RE: [Serusers] problem with cisco 2600 to pstn

by Dan Austin

On your pots dial-peer set the codec to g711alaw, or configure your SIP clients to use that codec. Dan -----Original Message----- From: Yang Xiang [mailto:yang.xiang@iitb.fraunhofer.de] Sent: Friday, April 25, 2003 7:55 AM To: serusers(a)lists.iptel.org Subject: [Serusers] problem with cisco 2600 to pstn 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

21 years, 7 months

Re: [Serusers] problem with cisco 2600 to pstn

by Yang Xiang

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

21 years, 7 months

[Serusers] SERAdmin program in development to benefit all SER administrators

by Xten India

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.

21 years, 7 months

[Serusers] problem with cisco 2600 to pstn

by Yang Xiang

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

21 years, 7 months

[Serusers] msg's not reaching all the way

by magnus melin

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.

21 years, 7 months

Jump to page:

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