sr-users June 2007

sr-users@lists.kamailio.org

191 participants
314 discussions

[Serusers] loose_route behaviour, detecting single Route with myself

by JF

Hi all, When SER receives an INVITE with a single Route header pointing to itself, it's supposed to delete it and process the message as if no Route header was there in the first place. This is what RFC3261 mandates, right? But currently the loose_route function returns true to the script in this case, just like when more Route headers are present. So I have some routing logic for when no Route headers are present, and if I want to apply the same routing logic to the case when there is a single Route header pointing to myself (naturally, as it's the same as if no Route header was present), I currently have to replicate the same routing logic inside the if (loose_route())... Or is there an other way? Do I have to develop my own module function or use some regexp search from the script to detect if there are more Routes besides myself before I call loose_route? The best would be to change loose_route to return false and just remove the Route header pointing to myself when there are no more Route headers in the message... what do you think? JF

16 years, 9 months

[Users] openser 1.1.1 available for several embedded platforms

by Ovidiu Sas

Hi, openser 1.1.1 is now available in binary format for several embedded patforms: - Linksys NSLU - Synology DS-101(g+) - Iomega NAS 100d - Freecom FSG-3 - Qnap TurboStation ... and all routers supported by the oleg or dd-wrt distributions. Check out http://www.nslu2-linux.org Regards, Ovidiu Sas

16 years, 10 months

[Users] statefull handling of 6xx responses

by Christian Schlatter

RFC 3261 defines that upon reception of a 6xx response, a proxy SHOULD cancel all forked dialogs and send back the 6xx as the final response to the upstream UA. --- rfc 3261, section 16.7 ------- Under the new rules, upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from all outstanding client transactions, and then at that point the 6xx is forwarded upstream. ---------------------------------- Some call forking experiments have shown that openser 1.2 does not follow these rules, instead it seems to disregard any 6xx response and continue with normal processing of existing forked dialogs. E.g. if a call forks to five phones and one of them sends back a 603 Declined response, the other four phones continue to ring until fr_inv_timer fires and failure_route is called with a status of 408 Timeout. Is it possible to make openser more SIP RFC compliant through configuration or does this need a code change? thanks, Christian

16 years, 10 months

[Serusers] t_relay_to_tcp/udp/tls

by Zappasodi Daniele

Hello, Is it possible to choose the protocol, without specifying the destination as we do with the t_relay()? With the t_relay_to_[tcp|udp|tls] I can choose the protocol but I must specify a destination address in the config file. Thanks ********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message inerror. **********************************************************************

16 years, 10 months

[Users] Query in the openser.cfg file

by sreekanth

Hi, What is the use of the config item children in the openser.cfg file. How is it related to command line options (-n process-no / -N tcp process-no). Rgds, Sreekanth

16 years, 10 months

Re: [Users] Many crashes on Openser system

by Klaus Darilion

looks like (not sure) process 1546 received a reply, does the tm matching, and then forwards the reply. The last entry Jun 7 10:42:04 marge openser[1546]: DBG: trans=0xb577a938, callback type 128, id 0 entered references a callback. Maybe the tm module calls a registered callback function and this function crashes. Do you use any self-written modules? Which modules are you using which uses callbacks (e.g. acc, dialog ...)? Try to disable these modules. regards klaus Antonio Higuera wrote: > Thanks for your reply. > > You have attached a file with the logs. Be aware that the coredump > backtrace > i sent in my previous mail maybe is not the same crash you can see in the > log. > > Thanks again for your help. > > > Jun 7 10:42:04 marge openser[1546]: SIP Reply (status): > > Jun 7 10:42:04 marge openser[1546]: version: <SIP/2.0> > > Jun 7 10:42:04 marge openser[1546]: status: <407> > > Jun 7 10:42:04 marge openser[1546]: reason: <Proxy Authentication Required> > > Jun 7 10:42:04 marge openser[1546]: parse_headers: flags=2 > > Jun 7 10:42:04 marge openser[1546]: Found param type 232, <branch> = < > z9hG4bK6202.244bec76.0>; state=6 > > Jun 7 10:42:04 marge openser[1546]: Found param type 234, <received> = < > 192.168.1.129>; state=16 > > Jun 7 10:42:04 marge openser[1546]: end of header reached, state=5 > > Jun 7 10:42:04 marge openser[1546]: parse_headers: Via found, flags=2 > > Jun 7 10:42:04 marge openser[1546]: parse_headers: this is the first via > > Jun 7 10:42:04 marge openser[1546]: After parse_msg... > > Jun 7 10:42:04 marge openser[1546]: DEBUG:forward_reply: found module tm, > passing reply to it > > Jun 7 10:42:04 marge openser[1546]: DEBUG: t_check: start=0xffffffff > > Jun 7 10:42:04 marge openser[1546]: parse_headers: flags=22 > > Jun 7 10:42:04 marge openser[1546]: Found param type 232, <branch> = > <z9hG4bKcc503ea3c48d6b766>; state=16 > > Jun 7 10:42:04 marge openser[1546]: end of header reached, state=5 > > Jun 7 10:42:04 marge openser[1546]: parse_headers: Via found, flags=22 > > Jun 7 10:42:04 marge openser[1546]: parse_headers: this is the second via > > Jun 7 10:42:04 marge openser[1546]: DEBUG: add_param: tag=as4b55784e > > Jun 7 10:42:04 marge openser[1546]: DEBUG:parse_to:end of header reached, > state=29 > > Jun 7 10:42:04 marge openser[1546]: DBUG:parse_to: display={21104}, ruri={ > sip:21104@barik.com} > > Jun 7 10:42:04 marge openser[1546]: DEBUG: get_hdr_field: <To> [44]; uri=[ > sip:21104@barik.com] > > Jun 7 10:42:04 marge openser[1546]: DEBUG: to body [21104 < > sip:21104@barik.com>] > > Jun 7 10:42:04 marge openser[1546]: get_hdr_field: cseq <CSeq>: <30425> > <INVITE> > > Jun 7 10:42:04 marge openser[1546]: parse_headers: flags=8 > > Jun 7 10:42:04 marge openser[1546]: DEBUG: t_reply_matching: hash 8230 > label > 1741599810 branch 0 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:REF_UNSAFE: after is 1 > > Jun 7 10:42:04 marge openser[1546]: DEBUG: t_reply_matching: reply matched > (T=0xb577a938)! > > Jun 7 10:42:04 marge openser[1546]: DBG: trans=0xb577a938, callback type 2, > id 0 entered > > Jun 7 10:42:04 marge openser[1546]: parse_headers: flags=8 > > Jun 7 10:42:04 marge openser[1546]: DEBUG: t_check: end=0xb577a938 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:reply_received: org. status > uas=100, uac[0]=0 local=0 is_invite=1) > > Jun 7 10:42:04 marge openser[1546]: parse_headers: flags=8 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:build_local: using FROM=<From: > Arturo <sip:104@barik.com>;tag=73529158ed >, TO=<To: 21104 < > sip:21104@barik.com>;tag=as4b55784e >, CSEQ_N=<CSeq: 30425> > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:t_should_relay_response: > T_code=100, new_code=407 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:t_pick_branch: picked > branch 0, > code 407 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:t_should_relay_response: > dns-failover test: branch=0, last_recv=407, flags=2 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:relay_reply: branch=0, save=0, > relay=0 > > Jun 7 10:42:04 marge openser[1546]: old size: 533, new size: 448 > > Jun 7 10:42:04 marge openser[1546]: build_res_from_sip_res: copied size: > orig:128, new: 43, rest: 405 msg= SIP/2.0 407 Proxy Authentication Required > Via: SIP/2.0/UDP 192.168.1.64:5060;branch=z9hG4bKcc503ea3c48d6b766 From: > Arturo <sip:104@barik.com>;tag=73529158ed To: 21104 > <sip:21104@barik.com>;tag=as4b55784e > Call-ID: f35b076f65bee9c5 CSeq: 30425 INVITE User-Agent: Asterisk PBX > Allow: > INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", > nonce="6f707e3f" > Content-Length: 0 > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:set_timer: relative timeout is > 500000 > > Jun 7 10:42:04 marge openser[1546]: DEBUG: add_to_tail_of_timer[4]: > 0xb577aa00 (52180600000) > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:set_timer: relative timeout is > 10 > > Jun 7 10:42:04 marge openser[1546]: DEBUG: add_to_tail_of_timer[0]: > 0xb577aa1c (52190) > > Jun 7 10:42:04 marge openser[1546]: DEBUG:tm:relay_reply: sent > buf=0x819cce8: SIP/2.0 4..., shmem=0xb5778158: SIP/2.0 4 > > Jun 7 10:42:04 marge openser[1546]: DBG: trans=0xb577a938, callback type > 128, id 0 entered > > > > 2007/6/20, Klaus Darilion <klaus.mailinglists(a)pernau.at>: >> >> > The following lines are the log generated: >> > >> > Jun 7 10:42:04 marge openser[1545]: receive_msg: cleaning up >> > >> > Jun 7 10:42:04 marge openser[1565]: ERROR: receive_fd: EOF on 8 >> > >> > Jun 7 10:42:04 marge openser[1565]: DBG: handle_ser_child: dead >> child 2, >> > pid >> > 1546 (shutting down?) >> > >> > Jun 7 10:42:04 marge openser[1565]: DBG: io_watch_del (0x812d720, 8, >> -1, >> > 0x0) fd_no=23 called >> > >> > Jun 7 10:42:04 marge openser[1544]: child process 1546 exited by a >> > signal 11 >> >> Could you also post the last log lines of process 1546 ? >> >> >> regards >> klaus >>

16 years, 10 months

[OpenSER-Users] No NOTIFY after presence unsubscription

by Michel de Boer

Hi, I am currently experimenting with the presence module (openser v1.2.1). It seems to work really fine. I only encountered a small problem. When my client unsubscribes from the presence event by sending a SUBSCRIBE request with expires=0, then openser responds with a 200 OK. After the 200 OK, I expect to receive a NOTIFY message, but openser never sends this NOTIFY. It is this NOTIFY that should terminate the subscription dialog through its Subscription-State header set to "terminated". RFC 3856 states this: The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state. This behavior is based on the general requirements for event handling as defined in RFC 3265. Is this a bug or is there some configuration stuff that enables/disables the NOTIFY for a SUBSCRIBE with epxpires=0. A SUBSCRIBE with expires=0 can also arrive as the initial and final SUBSCRIBE for a subscription. In that case it will be fetching the presence information only once. Without the NOTIFY, a fetch does not work. Cheers, Michel -- Michel de Boer www.twinklephone.com

16 years, 10 months

[Serusers] XLITEPHONE PROBLEM

by Adeyeye Michael

Kindly help me check this: root@micadeyeye:/usr/src# cd xten-xlite/ root@micadeyeye:/usr/src/xten-xlite# ls README xtensoftphone root@micadeyeye:/usr/src/xten-xlite# ./xtensoftphone I/O warning : failed to load external entity "/root/.Xscrc" Warning: /dev/dsp appears to be a valid audio device, but I cannot open it. Please ensure that no other applications are using the audio device (perhaps by trying ``lsof /dev/dsp''). -- Mike

16 years, 10 months

[OpenSER-Users] Wrong CSeq in NOTIFY after presence subscription refresh

by Michel de Boer

I perform the following scenario (openser v1.2.1): 1) Send a SUBCRIBE to openser for the presence event with expires = 3600 2) The subscription is established. Openser sends a NOTIFY with PIDF body. The sequence number in the CSeq header is 516. 3) 1 hour later I send an in-dialog SUBSCRIBE to extend the subscription for another hour. 4) openser sends a NOTIFY having sequence number 516 in the CSeq header. The sequence number of the NOTIFY should have been higher (517) as the sequence numbers of in-dialog messages should increase. I think this is a bug. Regards, Michel -- Michel de Boer www.twinklephone.com

16 years, 10 months

Re: [OpenSER-Users] The Via Header of CANCEL Message

by fancy

Hi Klaus: RFC 3665 page 54 line 4: A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. and RFC 3665 at page 53: CANCEL is referred to as a "hop-by-hop" request, since it is responded to at each stateful proxy hop. and RFC 3665 at page 21: Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients. So, for my opinion, the role of proxy in this case of RFC 3665 section 3.8 is a client when it sends CANCEL message to Bob. If I misunderstand any RFC meanings, please correct me. Thank you very much. Best Regards, Fangyu Ling > fancy wrote: >> According to RFC 3665 section 3.8 and RFC 3261 section 9, >> there is only one via header in CANCEL message >> (message F11, F13 at page 72 of RFC 3665). > > Hi! > > I could find it in RFC 3665, but not in 3261. Where exactly in RFC 3261 > is mentioned that the CANCEL has only 1 Via header? > > Further, the example has only one Via header - but I could not find any > definition if this is a MUST or not. > >> How can I remove the 2nd via header? > > You would have to modify tm module and change the code which generates > the CANCEL message. > > regards > klaus >

16 years, 10 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 June 2007