sr-users February 2003

sr-users@lists.kamailio.org

45 participants
91 discussions

by Geetha Shree

Hi, I am new to SIP. I have installed the SER server and my REGISTER method is working ok. But when I send the INVITE method I am getting the following error from SER server. The invite packet which has been sent by me is: INVITE sip:anuradha@there.com SIP/2.0 From: <sip:LittleGuy@there.com>;tag=1044365919410 To: <sip:anuradha@there.com > Via: SIP/2.0/UDP 192.168.1.9:5060;branch=z9hG4bK1159de0c6cca18f9131c8ff342527668 CSeq: 1 INVITE Call-Id: a1371c790546f9a2df76be1f59f6a7dc(a)192.168.1.9 Contact: <sip:192.168.1.9:5060;transport=UDP> Content-Length: 0 192.168.1.9 is my SER server's address The response got from the SER server is: SIP/2.0 500 I'm terribly sorry, server error occured (1/SL) From: <sip:LittleGuy@there.com>;tag=1044365919410 To: <sip:anuradha@there.com>;tag=d907c037823644515dfe0ede38ca9976.3592 Via: SIP/2.0/UDP 192.168.1.9:5060;branch=z9hG4bK1159de0c6cca18f9131c8ff342527668;received=192.168.1.21 CSeq: 1 INVITE Call-Id: a1371c790546f9a2df76be1f59f6a7dc(a)192.168.1.9 Server: Sip EXpress router (0.8.10 (i386/linux)) Content-Length: 0 Warning: 392 192.168.1.9:5060 "Noisy feedback tells: pid=1587 req_src_ip=192.168.1.21 in_uri=sip:LittleGuy@there.com out_uri=sip:LittleGuy@there.com via_cnt==1" Can you help on this please Thanks in advance Geetha

21 years, 2 months

[Serusers] kernel: Out of Memory: Killed process 3780 (ser).

by jaime.gill＠orange.co.uk

Hi, We have had a strange crash in the SER server we use. The load was not that big - around 10 users being served at that time. All of a sudden, the server stops responding and reports the following error in /var/log/messages: Feb 4 14:41:35 sip kernel: Out of Memory: Killed process 3780 (ser). Feb 4 14:54:52 sip kernel: Out of Memory: Killed process 3857 (ser). Feb 4 14:58:08 sip last message repeated 10 times Feb 4 15:02:17 sip kernel: Out of Memory: Killed process 3860 (ser). Feb 4 15:13:32 sip last message repeated 66 times [continues.....] Has someone else met this before? Jaime ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

21 years, 2 months

RE: [Serusers] ser crashes

by Klaus Darilion

Hi! > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > could you, please, generate a core dump ? Use ulimit -c > 1000000 to enable core generation and reproduce the crash. Sorry, but I'm not familiar with core dump, ulimit .... Could you please give me more detailed instructions? Where can I find the core dump? > Then compress the compiled sources along with the core dump > and send it to me. I don't use sources compiled sources, I use the rpms. regards, klaus > > thanks, Jan. > > On 05-02 12:13, Klaus Darilion wrote: > > Hello! > > > > During playing around with route headers I discovered that > ser crashes > > reproduceable when I send the following request to it with > sipsak, I > > think the invite is a valid request with strict routing. > > > > sipsak.exe -f invite3.txt -s sip:obelix.ict.tuwien.ac.at -vvv > > > > invite3.txt: > > INVITE sip:obelix.ict.tuwien.ac.at SIP/2.0 > > Via: SIP/2.0/UDP 128.131.80.191:5070;branch=z9hG4bK2024693217 > > Route: <sip:iptel.org> > > Route: <sip:klaus3000@klausix.ict.tuwien.ac.at> > > From: <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618 > > To: <sip:klaus3000@iptel.org> > > Call-ID: 744056460(a)128.131.80.191 > > CSeq: 20 INVITE > > Contact: <sip:brutus@128.131.80.191:5070> > > max-forwards: 10 > > user-agent: oSIP/Linphone-0.9.1 > > Content-Type: application/sdp > > Content-Length: 335 > > > > .. > > sdp > > .. > > > > > > then ser stops to respond: > > > > >[root@obelix darilion]# /etc/init.d/ser status > > >ser dead but subsys locked > > > > and in /var/log/messages > > Feb 5 11:57:21 obelix ser: Listening on > > Feb 5 11:57:21 obelix ser: 128.131.80.136 > > [128.131.80.136]::5060 > > Feb 5 11:57:21 obelix ser: Aliases: obelix.ict.tuwien.ac.at:5060 > > Feb 5 11:57:21 obelix ser: ser startup succeeded > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: mod_init(): Database > > connection opened successfuly > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: INFO: > udp_init: SO_RCVBUF > > is initially 65535 > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: INFO: > udp_init: SO_RCVBUF > > is finally 131070 > > Feb 5 11:57:21 obelix /usr/sbin/ser[21432]: INFO: fifo process > > starting: 21432 > > Feb 5 11:57:21 obelix /usr/sbin/ser[21432]: SER: > open_uac_fifo: fifo > > server up at /tmp/ser_fifo... > > > > ..up to here everything works fine, than I send the request: > > > > Feb 5 11:57:30 obelix /usr/sbin/ser[21428]: BUG: qm_*: fragm. > > 0x422b9ad0 end overwritten(35322e64, 39306665)! Feb 5 > 11:57:30 obelix > > /usr/sbin/ser[21426]: child process 21428 exited by a signal 11 > > Feb 5 11:57:30 obelix /usr/sbin/ser[21426]: core was not generated > > Feb 5 11:57:30 obelix /usr/sbin/ser[21426]: INFO: > terminating due to > > SIGCHLD > > > > Here is the ngrep output: > > > > U 128.131.80.101:1558 -> 128.131.80.136:5060 > > INVITE sip:obelix.ict.tuwien.ac.at SIP/2.0..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > 128.131.80.191:5070;branch=z9hG4bK2024693217..Route: <sip:iptel. > > org>..Route: <sip:klaus3000@klausix.ict.tuwien.ac.at>..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>..Call-ID: 744056460(a)128.131.80 > > .191..CSeq: 20 INVITE..Contact: > > <sip:brutus@128.131.80.191:5070>..max-forwards: 10..user-agent: > > oSIP/Linphone-0.9.1..Content-Type: application/sdp..Content-Length: > > 335 .... > > v=0..o=brutus 123456 654321 IN IP4 128.131.80.191..s=A > > c..onversation..c=IN IP4 128.131.80.191..t=0 0..m=audio > 7078 RTP/AVP 3 > > 115 8 110 111 101..a=rtpmap:3 gsm/8000/1..a=rtp > > map:115 lpc10-1.5/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:110 > > speex-4/8000/1..a=rtpmap:111 speex_lbr-4/8000/1..a=rtpmap:101 > > telephone-event/8000..a=fmtp:101 0-11.. > > # > > U 128.131.80.136:5060 -> 128.131.80.101:1557 > > SIP/2.0 100 trying -- your call is important to us..Via: > SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > 128.131.80.191:5070;branch=z9hG4bK2024693217..From: <sip > > :brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>..Call-ID: > 744056460@128.131.80.191..CSeq: 20 > > INVITE..Server: Sip EXpress router (0.8.10 (i386/l > > inux))..Content-Length: 0..Warning: 392 > 128.131.80.136:5060 "Noisy > > feedback tells: pid=21552 req_src_ip=128.131.80.101 > > in_uri=sip:obelix.ict.tuwien.ac.at out_uri=sip:iptel.o > > rg via_cnt==2".... > > > > # > > U 128.131.80.136:5060 -> 195.37.77.101:5060 > > INVITE sip:iptel.org SIP/2.0..Via: SIP/2.0/UDP > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP 128.131.80.191: > > 5070;branch=z9hG4bK2024693217..Route: > > <sip:klaus3000@klausix.ict.tuwien.ac.at>..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>..Call > > -ID: 744056460@128.131.80.191..CSeq: 20 INVITE..Contact: > > <sip:brutus@128.131.80.191:5070>..max-forwards: 9 ..user-agent: > > oSIP/Linphone-0.9.1..Content-Type: application/sdp.. > > Content-Length: 335 ....v=0..o=brutus 123456 654321 IN IP4 > > 128.131.80.191..s=A c..onversation..c=IN IP4 128.131.80.191..t=0 > > 0..m=audio 7078 RTP/AVP 3 115 8 110 111 101..a=r > > tpmap:3 gsm/8000/1..a=rtpmap:115 lpc10-1.5/8000/1..a=rtpmap:8 > > PCMA/8000/1..a=rtpmap:110 speex-4/8000/1..a=rtpmap:111 > > speex_lbr-4/8000/1..a=rtpmap:101 telephone-event/8000..a > > =fmtp:101 0-11.. > > > > # > > U 195.37.77.101:5060 -> 128.131.80.136:5060 > > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP 12 > > 8.131.80.191:5070;branch=z9hG4bK2024693217..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07.3f3c > > ..Call-ID: 744056460@128.131.80.191..CSeq: 20 > > INVITE..Proxy-Authenticate: Digest realm="iptel.org", > > nonce="3e40f29900000000d6e1790446755f1b4b96f5f5bd97b283", > > algorithm=MD5.. > > Server: Sip EXpress router (0.8.9 (i386/linux))..Content-Length: > > 0..Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=7651 > > req_src_ip=128.131.80.136 in_uri=sip:ipte > > l.org out_uri=sip:klaus3000@klausix.ict.tuwien.ac.at > via_cnt==3".... > > > > # > > U 128.131.80.136:5060 -> 128.131.80.101:1557 > > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > 128.131.80.191:5070;branch=z9hG4bK2024693217..From: <sip:brutus@o > > belix.ict.tuwien.ac.at>;tag=262992618..To: > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07.3f3c..C > > al > > l-ID: 744056460@128.131.80.191..CSeq: 20 INVITE..Proxy-Aut > > henticate: Digest realm="iptel.org", > > nonce="3e40f29900000000d6e1790446755f1b4b96f5f5bd97b283", > > algorithm=MD5..Server: Sip EXpress router (0.8.9 > > (i386/linux))..Content-Length > > : 0..Warning: 392 195.37.77.101:5060 "Noisy feedback > tells: pid=7651 > > req_src_ip=128.131.80.136 in_uri=sip:iptel.org > > out_uri=sip:klaus3000@klausix.ict.tuwien.ac.at via_cnt==3 > > ".... > > > > # > > U 128.131.80.136:5060 -> 195.37.77.101:5060 > > ACK sip:iptel.org SIP/2.0..Via: SIP/2.0/UDP > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..Call-ID: > > 744056460(a)128.13 > > 1.80.191..To: > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07 > .3f3c..CSe > > q: 20 ACK.. > > > > > > > > If you need more details please let me know. > > > > regards, > > Klaus > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > >

21 years, 2 months

RE: [Serusers] Routing with ser / Problems with linphone

by Klaus Darilion

I just read the "ser status update" from jiri and he wrote in the "new features" section: - 3261-alignment: support for TCP and loose-routing So I think this will be fixed in the next release? Klaus > -----Original Message----- > From: Klaus Darilion > Sent: Wednesday, February 05, 2003 11:19 AM > To: serusers(a)lists.iptel.org > Cc: Aymeric Moizard > Subject: [Serusers] Routing with ser / Problems with linphone > > > Hello! > > I've installed ser (sip:obelix.ict.tuwien.ac.at) und want'ed > to use it with linphone, so I configured linphone to use ser > as outbound proxy and registrar. The registration works fine > but not the INVITEs. ser answers to an INVITE from linphone > with a 404 Not Found and I found out that the problem is the > "Route" header in the INVITE from linphone. > > Route: <sip:obelix.ict.tuwien.ac.at;lr> > > When I remove the header from the invite and send it manually > (sipsak) the ser proxy accepts the invite and forwards it. I > think ser reacts wrong because if an RFC3261 proxy gets an > request with a route header which points to itself it should > remove the header and forward the request. > > Than I tried the same with an different proxy in the route header: > > Route: <sip:iptel.org;lr> > > Now, my ser proxy (sip:obelix.ict.tuwien.ac.at) accepts the > request and forwards it to iptel.org, but it rewrites the > invite to: INVITE sip:iptel.org;lr SIP/2.0 > > Thats what an RFC2543 proxy would do, but not an RFC3261 > proxy, which only is allowed to do that if the route header > has no "lr" parameter or if he is responsible for the domain > in the request URI. If there is an "lr" parameter the proxy > must not change the request URI. > > If I'm wrong please let me know. > > I use ser 0.8.10 with the standard config file and linphone > 0.9.1 & 0.10.0 > > Regards, > Klaus > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > >

21 years, 2 months

[Serusers] Routing with ser / Problems with linphone

by Klaus Darilion

Hello! I've installed ser (sip:obelix.ict.tuwien.ac.at) und want'ed to use it with linphone, so I configured linphone to use ser as outbound proxy and registrar. The registration works fine but not the INVITEs. ser answers to an INVITE from linphone with a 404 Not Found and I found out that the problem is the "Route" header in the INVITE from linphone. Route: <sip:obelix.ict.tuwien.ac.at;lr> When I remove the header from the invite and send it manually (sipsak) the ser proxy accepts the invite and forwards it. I think ser reacts wrong because if an RFC3261 proxy gets an request with a route header which points to itself it should remove the header and forward the request. Than I tried the same with an different proxy in the route header: Route: <sip:iptel.org;lr> Now, my ser proxy (sip:obelix.ict.tuwien.ac.at) accepts the request and forwards it to iptel.org, but it rewrites the invite to: INVITE sip:iptel.org;lr SIP/2.0 Thats what an RFC2543 proxy would do, but not an RFC3261 proxy, which only is allowed to do that if the route header has no "lr" parameter or if he is responsible for the domain in the request URI. If there is an "lr" parameter the proxy must not change the request URI. If I'm wrong please let me know. I use ser 0.8.10 with the standard config file and linphone 0.9.1 & 0.10.0 Regards, Klaus

21 years, 2 months

FW: [Serusers] Initial setup on FreeBSD of ser using Cisco 7960 SIP

by Lenny Tropiano

Nils, Thanks! Setting listen=sip.voiping.com worked. I had listen=192.70.239.1 (which the reverse DNS records resolve to: voiping.com). So, that worked. Thanks for the help and the quick response. Regarding "not forking" it was purely for debugging purposes. It'll work now with fork=yes. Now I have: fork=yes log_stderr=no alias=voiping.com listen=sip.voiping.com Later, L. -----Original Message----- From: Nils Ohlmeier [mailto:nils@ohlmeier.de] Sent: Tuesday, February 04, 2003 1:57 PM To: Lenny Tropiano; serusers(a)lists.iptel.org Cc: 'VoIPing, LLC (IT Consulting)' Subject: Re: [Serusers] Initial setup on FreeBSD of ser using Cisco 7960 SIP Hi, On Tuesday 04 February 2003 19:09, Lenny Tropiano wrote: > I'm "playing" with SER trying to understand how it all works, and to > be completely honest I haven't finished reading all the docs. > Basically I'm using the default ser.cfg (installed in > /usr/local/etc/ser) and I have two 7960s with the latest SIP code. I > know it works, since I can call the other phone with our > user(a)iptel.org extension ... The 2nd line is setup to register to > sip.voiping.com [192.70.239.1]. Immediately the phone gets to trying, > I have ser running to "not fork, debug 3, and log to stderr". Is their any special reason why you not allow to fork? Because from the repsonse packet bellow you can see that your request is going through end (nearly) endless loop. The via_cnt==12 means the request was forwarded 12 times (before it was stoped by the maxfws rule). I guess that ser cant detect that sip.voiping.com is one of its "myself" names. Maybe this is caused by the 'fork=no'. If not you can try to add 'listen=sip.voiping.com' to your configuration or the commandline switch '-l sip.voiping.com'. This should fix your problem. Regards Nils Ohlmeier

21 years, 2 months

[Serusers] Initial setup on FreeBSD of ser using Cisco 7960 SIP

by Lenny Tropiano

I'm "playing" with SER trying to understand how it all works, and to be completely honest I haven't finished reading all the docs. Basically I'm using the default ser.cfg (installed in /usr/local/etc/ser) and I have two 7960s with the latest SIP code. I know it works, since I can call the other phone with our user(a)iptel.org extension ... The 2nd line is setup to register to sip.voiping.com [192.70.239.1]. Immediately the phone gets to trying, I have ser running to "not fork, debug 3, and log to stderr". ngrep indicates the following: U 192.70.239.150:53087 -> 192.70.239.1:5060 REGISTER sip:sip.voiping.com SIP/2.0..Via: SIP/2.0/UDP 192.70.239.150:5060..From: sip:lenny@sip.voiping.com..To: sip:lenny@sip. voiping.com..Call-ID: 00036b54-b62d1fe8-314ef9d4-1cca7f7b@192.70.239.150..Date: Tue, 04 Feb 2003 18:07:32 GMT..CSeq: 101 REGIST ER..User-Agent: CSCO/4..Contact: <sip:lenny@192.70.239.150:5060>..Content-Length: 0..Expires: 3600.... # U 192.70.239.1:5060 -> 192.70.239.150:5060 SIP/2.0 483 Too Many Hops..Via: SIP/2.0/UDP 192.70.239.150:5060..From: sip:lenny@sip.voiping.com..To: sip:lenny@sip.voiping.com ;tag=e755c894a31056969aa313d5267cd575.f7b7..Call-ID: 00036b54-b62d1fe8-314ef9d4-1cca7f7b@192.70.239.150..CSeq: 101 REGISTER..Se rver: Sip EXpress router (0.8.10 (i386/freebsd))..Content-Length: 0..Warning: 392 192.70.239.1:5060 "Noisy feedback tells: pid= 71976 req_src_ip=192.70.239.1 in_uri=sip:sip.voiping.com out_uri=sip:sip.voiping.com via_cnt==12".... I would appreciate any advice in getting this going (btw, I compiled the version of SER 0.8.10 and didn't use the already compiled binaries). Thanks, Lenny --- Lenny Tropiano E-mail: lenny(a)voiping.com Partner, Networking Specialist Pager: pager-lenny(a)voiping.com VoIPing, LLC URL: http://www.voiping.com/ PO Box 867, Cedar Park, TX 78630-0867 Mobile: 512-698-VOIP [8647]

21 years, 2 months

[Serusers] New feature for the tm module [sticky proxy]

by Maxim Sobolev

Folks, We are currently trying to implement owerflow routing with sip and b2bua. Our network setup looks like the following (two GWs here is for simplicity, actually there would be dozens of them): --------- /--|PSTN GW|-\ ---- ----------------- ------- /~~~~~~\/ --------- \ /~~~~~~~~\ |UA|--|PROXY/REGISTRAR|--|B2BUA|--<IP CLOUD> <PSTN CLOUD> ---- ----------------- ------- \______/\ --------- / \________/ \--|PSTN GW|-/ --------- Since potentially each destination in the PSTN could be reached through more than one GW we would like to use that for adding some more robustness to the system, beause from time to time some of gateways might be unavailable for one reason of another (network outage, maintenance, overload etc.). t_on_negative() looks like a pretty suitable feature for the job modulo that we need to add some scheme for distinguishing real failures, such as "number is busy", from transient ones. The problem here is that b2bua is unable to do prefix-based routing, while we can't put b2bua between the UA and PROXY because for accounting reasons we should be able to get from b2bua IP number of the gateway the call was forwarded to. Therefore, we do gateway selection based on prefix in ser (using rewritehostport) and then just forward request to the b2bua using t_relay_to(). To catch failures and perform retries we use t_on_negative() and number of reply_route[] blocks and it is where the problem lies - after appending a new branch ser forwards the request to the host:port specified in the uri directly, but not through the b2bua. Attached patch adds a new variable sticky_relay_to, which if set to non-zero value instructs ser to record proxy address to which transaction was originally forwarded with t_relay_to(). On failure ser forwards request to that address if another branch was appended in reply_route[]. I think that it is generally useful feature and it would be nice to see it integrated into the next release. Thanks! -Maxim

21 years, 2 months

[Serusers] (no subject)

by mko＠cs.stir.ac.uk

Hi, I have installed SER on linux and created a few users. I can register these users from SIP phones and soft-phones and can also establish connections between them. I have also created a user on the iptel.org server. I can ring from a client registered with my domain (cs.stir.ac.uk) the client registered with iptel.org. It works perfectly. However, ringing from the client registered with iptel.org a client registered locally doesn't work. Is this a config problem? How can I fix this? Any help is greatly appreciated! Best regards, Mario Kolberg -- Mario Kolberg phone: +44 (0)1786 46 7440 Lecturer in Computing Science fax : +44 (0)1786 46 4551 email: mko(a)cs.stir.ac.uk Department of Computing Science and Mathematics University of Stirling Stirling FK9 4LA Scotland, UK -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.

21 years, 2 months

[Serusers] Error message I don't understand

by s-ser-maillinglist＠hilft.net

Hello, I'm trying to use the presence agent that is in the CVS version. I added the module and the lines ---- if (method=="SUBSCRIBE") { subscribe("registrar"); break; }; ---- to my ser.cfg file. By changing this I get the following error message when trying to "sign in" with the msn messenger UA: ---- 15(23129) ERROR: t_reply: cannot send a t_reply to a message for which no T-state has been established 15(23129) send_reply(): Error while sending 200 OK ---- What does this mean? I admit I don't know a lot about the details of the SIP protocol, but if you'd give me a hint on where to search, it'd help me a lot. Is the presence agent in CVS already usable at all? If yes, could someone please provide me a working config file? Thanks in advance, Stefan Schmidt

21 years, 2 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 February 2003