sr-users June 2012

sr-users@lists.kamailio.org

78 participants
108 discussions

Re: [SR-Users] : Capturing a users call (SIP+RTP+T.38)
by Anton Kvashenkin 06 Jun '12

06 Jun '12

You can try homer sip capture server, just google it. 06.06.2012 15:08 пользователь "Klaus Darilion" <klaus.mailinglists(a)pernau.at> написал: > Hi all! > > Do you know any comfortable tools to filter out a certain users call? e.g. > searching in SIP packets for the user pattern, get the media port out of > SDP and capture also RTP+T.38 > > I found pcapsipdump but have not tried it yet. > > Any suggestions or do I have to write my own tool? > > thanks > Klaus > > ______________________________**_________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**users<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> >

1 0

Kamailio and Netann
by patrice.bodeven＠orange.com 05 Jun '12

05 Jun '12

Hello, I'am working on Kamailio version 3.2.2. I'm doing some test in interaction with Application server and media server. The applicationServer sends a INVITE sip to Media Server via the Kamailio. The R-URI has the format sip:annc@cl1.oms.ser.v0.pftest.net;play=http://1xx.1xx.1xx.1xx:8080/errfile/err.wav;repeat=forever But the parsing done by Kamailio of $ru is trunked to sip:annc@cl1.oms.ser.v0.pftest.net;play=http 1) Could you confirm if Kamailio supports Netann protocol ? 2) If not, how to route the INVITE with the correct R-URI format ? Thanks in advance. PatriceB _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.

3 3

Test SIP Servers for Simultaneous calls
by Vineet Menon 05 Jun '12

05 Jun '12

Hi, I want to test kamailio or any other server for it's simultaneous call rates, form which I mean how much calls it can support simultaneously?? I know about SIPp, but that won't fulfill my purpose, because SIPp doesn't offer simultaneity; rather it issues calls serially. BTW, is it possible to do multiple calls from same machine, since ports are consumed in the previous call?? I think the answer is negative.... I think, to do this kind of testing, we need multiple PCs..which call simultaneously... Any light on this?? Regards, Vineet Menon

3 4

Single-quoted vs double-quoted params in Path/Route
by Andreas Granig 04 Jun '12

04 Jun '12

Hi guys, When I implemented the Path module 6 years ago, I chose to enclose the received-URI in double-quotes, like this: Path: <sip:1.2.3.4:5060;received="sip:1.2.3.5:1234;transport=tcp"> This Path value is stored in usrloc by registrar module, and is converted to a Route in a subsequent request. This worked fine so far, because there's the logic in parser/parse_param.c to handle double-quoted parameters. Now while doing some interop tests with another platform, it turned out that double-quotes are not allowed in URI params (see https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019335.ht…, and in the grammar the allowed chars in the "unreserved" definition are "alphanum" and "mark", where "mark" is only "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" ). Anyways, to fully comply with RFC3261, I'd like to push a bugfix to path module to use single-quotes instead, however it also needs a change in the parser to use parse_quoted_param() also in case of single-quoted params (which hasn't been handled at all until now). My question now is if there are any concerns on your side with handling single-quoted URI params the way we handle double-quoted ones? If we were strict, we'd actually need to remove the handling for double-quoted ones, but for backwards-compatibility I'd rather keep it there. Comments? Andreas

2 2

FS#213 - pua_reginfo: registration state may be incorrect when unregistering single contact
by Gnaneshwar Gatla 01 Jun '12

01 Jun '12

I'm working with pua_reginfo module, I thought everything was working fine. But FS#213, is not resolved yet. @@ -118,9 +111,10 @@ str* build_reginfo_full(urecord_t * record, str uri, ucontact_t* c, int type) { xmlNewProp(contact_node, BAD_CAST "id", BAD_CAST buf); /* Check, if this is the modified contact: */ if (ptr == c) { - if ((type & UL_CONTACT_INSERT) || (type & UL_CONTACT_UPDATE)) + if ((type & UL_CONTACT_INSERT) || (type & UL_CONTACT_UPDATE)) { + reg_active = 1; xmlNewProp(contact_node, BAD_CAST "state", BAD_CAST "active"); - else + } else xmlNewProp(contact_node, BAD_CAST "state", BAD_CAST "terminated"); if (type & UL_CONTACT_INSERT) xmlNewProp(contact_node, BAD_CAST "event", BAD_CAST "created"); else if (type & UL_CONTACT_UPDATE) xmlNewProp(contact_node, BAD_CAST "event", BAD_CAST "refreshed"); from the above code in pua_reginfo_fix_registration_state.patch If(ptr == c) returns false and the server keeps the state to "active" and the reg_info is never set to refreshed/terminated. I was wondering if I could use the following instead. If(strcmp(ptr->c, c->c)), which would compare the contact string, if equal the reg_info is update in the presentity. Regards Gnaneshwar Gatla | InTouch Health | Software Developer 6330 Hollister Ave. Goleta CA, 93117 | P: 805.562.8686 ext: 199

1 0

Re: [SR-Users] SIP Client for iphone
by Daniel-Constantin Mierla 01 Jun '12

01 Jun '12

Please keep the mailing list cc-ed -- private messages from mailing list are going to be ignored. If you go to jitsi.org, in the download page there are references to the mac os x builds. Cheers, Daniel On 6/1/12 9:38 AM, Vijay Thakur wrote: > Thanks for prompt reply. > Please suggest me the link from where i can download jitsi for Mac OS X. > > On Friday 01 June 2012 01:06 PM, Daniel-Constantin Mierla wrote: >> Hello, >> >> On 6/1/12 9:06 AM, Vijay Thakur wrote: >>> Dear All, >>> >>> Kindly suggest me the compatible client for iphone and Mac OS Leopard. >>> I have found that Jisti is working very fine for all features on >>> Linux and MS Windows. >>> >> I use jitsi for Mac OS X, iirc, it worked fine on Leopard, now I >> upgraded the OS. For iPhone and even the other OSes, check Linphone. >> >> Cheers, >> Daniel >> > > -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

1 0

multiple t_on_branch[]
by Vitaliy Aleksandrov 01 Jun '12

01 Jun '12

Hi all, Does kamailio allow to configure more than one branch_route for an initial INVITE ? I have tried to add: t_on_branch(branch_r1); t_on_branch(branch_r2); before t_relay(). Mentioned branch routes write debug to the kamailio.log and it looks like that only the last branch_route[branch_r2] works.

2 1

SIP Client for iphone
by Vijay Thakur 01 Jun '12

01 Jun '12

Dear All, Kindly suggest me the compatible client for iphone and Mac OS Leopard. I have found that Jisti is working very fine for all features on Linux and MS Windows. -- Best Regards, Vijay Thakur (Assistant Manager - Networks) Mobile : +91 8744018065 Mail : vijay.thakur(a)loopmethods.com Loop IT Methods Private Limited 1st Floor, B-10, Sector-7, Noida, (U.P) India Ph: +91 120 305 3481,82 (INDIA), +1 347 468 8631 (USA), +61 390 011 178 (AUS) Fax: +91 971 728 330 Web: www.loopmethods.com LOOP Disclaimer ------------------------------------------------------------------------------------------------- This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. -----------------------------------------------------------------------------------------------------------------

4 6

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 June 2012