sr-users November 2005

sr-users@lists.kamailio.org

245 participants
570 discussions

by Rehan Ahmed

Hello All, Is there a SER Business Mailing list for commerical only emails on ? Rehan www.supertec.com <http://www.supertec.com> www.didxchange.com <http://www.didxchange.com>

19 years

[Users] exec_dset syntax error

by Iqbal

Hi can anyone see what wrong with exec_dset("/path/to/program.php") unless of course exec_dset only likes shell scripts Iqbal

19 years

[Users] exec-msg

by Iqbal

Hi Anyoe got shell script to parse all the parameters sent, from my understanding the entire sip message is sent, into the script, I just want to pull the username out from From: iqbal

19 years

[Users] A tutorial on the OSP peering module is now available

by Dmitry Isakbayev

Dear Users and Developers, A tutorial on the OSP peering module is now available at http://openser.org/docs/osp/Multi-Lateral_Peering_with_OpenSER_1_0_0.pdf. The module enables secure, multi-lateral peering with SIP devices that support OSP (i.e. OpenSER 1.1.x, OpenSER 1.0.x, (Open)SER 0.9.x, Asterisk 1.2). Open source OSP servers are available at www.sipfoundry.org/OSP. Regards, Dmitry

19 years

[Serusers] Dropping 200-ok?

by Ricardo Poppi

Hi list. I want to make an analisis at a 200-ok response from an INVITE. I implemented at ser 0.9.4 an "on_reply_route" to check if the 200-ok contains the SDP address of the gateway I want to connect. It its true, I let the 200-ok flows. If it´s not, I want to drop this and terminate the call (SIP ERROR or whatever). Here is the example ============= ------------- "A" =======> | "SER" | =========> "B" ------------- 1) "A" INVITEs "B" through SER 2) "B" says that its trying and ringing to "A" 3) User at "B" picks-up 4) I check the 200-ok at SER. If it´s ok, let it flow to "A". If it´s not, I want to drop it and terminate the call establishment. DO ANYBODY DID THAT OR CAN HELP ME WITH ANY CLUE/STARTING POINT? best regards to all. Ricardo Poppi.

19 years

[Users] obscufucation...spelt that wrong ;-)

by Iqbal

Hi Any chance in next versions of openser, of having a module if activated that it would be able to read/create a unreadable config file, but would be readable by ser itself. Or is there already a way of doing this iqbal

19 years

[Users] in dialog request when openser listens on multiple ports

by Klaus Darilion

Hi! I've configure openser to listen also on port udp:6060. The INVITE comes in to 6060, forwarded to other client on port 5060. Responses and ACK will be handled correctly - on call leg uses port 6060, the other call leg 5050. If now the callee sends a BYE (Cisco, strict router) the BYE will be forwarded from port 5060 instead of 6060. I didn't find a problem in the BYE request sent to the openser. Is openser behaving wrong here? Or do I have to configure special routing for this scenario? thanks klaus BYE from callee (5060) to proxy U 2005/11/09 16:47:48.254756 83.136.33.19:5060 -> 83.136.32.83:5060 BYE sip:83.136.32.83:5060;r2=on;ftag=a613b273;nat=yes;lr=on SIP/2.0. Via: SIP/2.0/UDP 83.136.33.19:5060;branch=z9hG4bK3dc73e84. From: <sip:01505641636@enum.at>;tag=000dedfb04cc011e597bda33-277ea073. To: klaus enum.at<sip:klaus@enum.at>;tag=a613b273. Call-ID: 7f49f21ed451bb7a. Date: Wed, 09 Nov 2005 15:47:47 GMT. CSeq: 101 BYE. User-Agent: CSCO/6. Content-Length: 0. RTP-RxStat: Dur=??,Pkt=??,Oct=??,LatePkt=??,LostPkt=??,AvgJit=??. RTP-TxStat: Dur=??,Pkt=??,Oct=??. Route: <sip:83.136.32.83:6060;r2=on;ftag=a613b273;nat=yes;lr=on>, <sip:klaus@84.20.167.143:7404>. . BYE from proxy to caller: is sent from 5060 althouth it should be sent from 6060. # U 2005/11/09 16:47:48.264940 83.136.32.83:5060 -> 84.20.167.143:7404 BYE sip:klaus@84.20.167.143:7404 SIP/2.0. Max-Forwards: 10. Record-Route: <sip:83.136.32.83;ftag=000dedfb04cc011e597bda33-277ea073;nat=yes;lr=on>. Via: SIP/2.0/UDP 83.136.32.83;branch=z9hG4bKaf5b.fbc8b274.0. Via: SIP/2.0/UDP 83.136.33.19:5060;branch=z9hG4bK3dc73e84. From: <sip:01505641636@enum.at>;tag=000dedfb04cc011e597bda33-277ea073. To: klaus enum.at<sip:klaus@enum.at>;tag=a613b273. Call-ID: 7f49f21ed451bb7a. Date: Wed, 09 Nov 2005 15:47:47 GMT. CSeq: 101 BYE. User-Agent: CSCO/6. Content-Length: 0. RTP-RxStat: Dur=??,Pkt=??,Oct=??,LatePkt=??,LostPkt=??,AvgJit=??. RTP-TxStat: Dur=??,Pkt=??,Oct=??. .

19 years

Re: [Serusers] Re: [Serdev] ACK before INVITE on re-INVITE causes CiscoAS's to return a 500 error

by Evan Borgström

Hey Ettore, Yes, both INVITEs contain valid and correct SDP info. We have a maintenance scheduled to upgrade IOS on the Cisco devices so hopefully that will help it. -Evan Ettore Benedetti wrote: > Hallo Evan, > > I reckon Nils is right on the matter. The ACK of the dialog-forming INVITE is actually > the first in-dialog request and, as a matter of fact, it is a separate transaction. As far > as the UAS is concerned, the dialog is established as soon as the 200 response is sent. > The Cisco GW just misbehaves provided the first INVITE from Asterisk did contain > an SDP offer (didn't it?). > > > Ettore Benedetti > > THALES COMMUNICATIONS B.V. > Bestevaer 46, 1271 ZA Huizen > The Netherlands > > Unclassified > > >>>> Evan Borgstrom <evan.borgstrom(a)ca.mci.com> 11/16/05 5:27:52 PM >>> > Hey Nils, > > You are correct that each message is handled by a different process, as > it to be expected, and I know that SER is not call statefull so my > concern lies around the fact that SER is delivering an INVITE which > requires FAR more processing and at least 2 database hits before a > loosely routed ACK which requires little to none for processing. > > I'm going to differ with you, and my self from last night, on the views > about the RFC as it does indeed cover the problem (I was just looking at > it the wrong way before). A re-INVITE cannot modify a dialog that does > not exist, and without the ACK being delivered in response to the 200 OK > the dialog is not yet created which is why the Cisco is returning a > CheckRequest failure since there's no dialog to map the re-INVITE to. > So, the device is correct in returning an error. > > When the Cisco returns the 500 error it's only for the re-INVITE so the > initial call stays established and a BYE is still required to tear it > down. The problem is that Asterisk is expecting that to work and has > already re-INVITED to the client so there's no audio and to the caller > the call failed. > > -Evan > > Nils Ohlmeier wrote: >> Evan, >> >> I would not invest the time to look into the SER side of your problem. Because >> this is a general problem. Instead of SER any other network element (router, >> switch, etc.) could change the order of the packets. >> BTW I guess this problem occurs on your SER because the ACK and the INVITE are >> handled by different SER processes. And as SER is not call-statefull there is >> no parameter to solve this situation. >> >> I fear you are right that this problem is not covered by any RFC, but the >> solutions seems logical to me: >> if this a generic problem, then either the UAC is not allowed to send a >> re-INVITE until the first INVITE is completed, or the UAS has to accept a >> re-INVITE after sending the 200 OK. But how does the the UAC know that the >> ACK reached the UAS so that it can send the re-INVITE now? It cant know that, >> so it would have to wait for a timer before it could send the re-INVITE. >> On the other side the INVITE transaction is completed for the UAS by sending >> the 200 OK (the ACK is a new transaction, according to the branch). >> Thus I think the UAS (the Cisco gateway) should accept the re-INVITE without >> complaining. >> >> Just for curiosity: is the call established or does the Cisco gateway drop the >> call after sending the 500? >> >> Regards >> Nils >> >> On Wednesday 16 November 2005 07:51, Greger V. Teigre wrote: >>> Evan, >>> I'm not able to match your text with the messages you show. The message >>> timestamped 16:51:51.559657, does it go to Cisco? It is shown to go to >>> Asterisk and it doesn't make sense. >>> However, until the Cisco gw receives the ACK from Asterisk, no call has >>> been established and the reINVITE cannot be matched. IMO, this is not a >>> Cisco bug. It seems very strange indeed that ser should send a reINVITE >>> before the ACK in the same call. Even without FIFO, an INVITE is likely to >>> take more time to process than a loose routed ACK. I would try to log more >>> thoroughly in SER to see what happens in processing the ACK and the >>> reINVITE. It could be a problem in your ser.cfg, but it seems strange >>> indeed. >>> g-) >>> >>> ----- Original Message ----- >>> From: "Evan Borgstrom" <evan.borgstrom(a)ca.mci.com> >>> To: <serusers(a)lists.iptel.org>; <serdev(a)lists.iptel.org> >>> Sent: Wednesday, November 16, 2005 12:05 AM >>> Subject: [Serdev] ACK before INVITE on re-INVITE causes Cisco AS's to >>> return a 500 error >>> >>>> Hey all, >>>> >>>> This has more to do with Asterisk & Cisco AS's IMO but I thought it >>>> would be interesting to get some responses from this group before I >>>> begin the battle with Cisco to get a bug report underway. >>>> >>>> We have an Asterisk box acting as a PBX sending calls to our SER >>>> instances. The asterisk box has "reinvite=yes" in the sip.conf file >>>> which causes Asterisk to send a re-INVITE for the call once it receives >>>> the 200 OK. This re-INVITE has it's SDP changed to that of the IP Phone >>>> behind the Asterisk box so that all media doesn't need to traverse it. >>>> This works fine except in certain instances where messages get out of >>>> order and it causes our Cisco GW's to error the call with a generic 500 >>>> message. When the messages are in the correct order the 500 error does >>>> not appear. >>>> >>>> So here's the situation, user behind the asterisk box picks up the >>>> phone and dials a PSTN destination. Asterisk fires off the initial >>>> invite and everything proceeds as normal and we eventually receive the >>>> 200 OK message to which the Asterisk box replies with ACK and a new >>>> INVITE that come in this order (X = Asterisk, Y = SER, Z = Cisco): >>>> >>>> U 2005/11/15 16:51:51.557322 X.X.X.X:5060 -> Y.Y.Y.Y:5060 >>>> ACK >>>> >>>> # >>>> U 2005/11/15 16:51:51.557948 X.X.X.X:5060 -> Y.Y.Y.Y:5060 >>>> INVITE >>>> >>>> SER accordingly processes the two messages and replies 100 Trying to >>>> the new INVITE message. Here's where the problem occurs, SER then sends >>>> these messages out to the PSTN gateway but the order has been reversed: >>>> >>>> # >>>> U 2005/11/15 16:51:51.558937 Y.Y.Y.Y:5060 -> X.X.X.X:5060 >>>> SIP/2.0 100 trying >>>> >>>> # >>>> U 2005/11/15 16:51:51.559000 Y.Y.Y.Y:5060 -> Z.Z.Z.Z:5060 >>>> INVITE >>>> >>>> # >>>> U 2005/11/15 16:51:51.559657 Y.Y.Y.Y:5060 -> X.X.X.X:5060 >>>> ACK >>>> >>>> When this happens the Cisco GW replies with a 500 error message and the >>>> following is sent to the Cisco's logs: >>>> >>>> # >>>> U 2005/11/15 16:51:51.711355 Z.Z.Z.Z:5060 -> Y.Y.Y.Y:5060 >>>> SIP/2.0 500 Server Internal Error. >>>> >>>> >>>> Nov 15 21:51:51.613: HandleUdpSocketReads :Msg enqueued for SPI with >>>> IPaddr: Y.Y.Y.Y:5060 >>>> Nov 15 21:51:51.613: *****CCB found in UAS Request table. ccb=0x653BCD0C >>>> Nov 15 21:51:51.613: CCSIP-SPI-CONTROL: act_sentsucc_new_message >>>> Nov 15 21:51:51.617: CCSIP-SPI-CONTROL: act_sentsucc_new_message_request >>>> Nov 15 21:51:51.617: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE >>>> Nov 15 21:51:51.617: sip_stats_status_code >>>> Nov 15 21:51:51.617: sipSPICheckRequest: CheckRequest fail on method 102 >>>> error code: 2 and status: 500 >>>> >>>> >>>> Is there any parameter that I can set to ensure that message leave SER >>>> in the order they enter? Should the Cisco be able to handle this >>>> condition (I check a number of different sections of the RFC but >>>> couldn't find anything specific for either side)? >>>> >>>> Thanks, >>>> Evan >>>> >>>> _______________________________________________ >>>> Serdev mailing list >>>> serdev(a)lists.iptel.org >>>> http://lists.iptel.org/mailman/listinfo/serdev >>> _______________________________________________ >>> Serdev mailing list >>> serdev(a)lists.iptel.org >>> http://lists.iptel.org/mailman/listinfo/serdev > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers

19 years

[Serusers] mangler module

by harry gaillac

Hello, I try to change the contact field in SIP HF with mangler module if (src_ip == 10.0.0.0/8) encode_contact("enc_prefix","193.175.135.38"); However asterisk receive a bad AOR because of "enc_prefix" . How can I rewrite contact field with public ip without adding this prefix in th user part ? Regards Harry Here is my config : Asterisk as registrar server :public ip:5050 Ser as outbound proxy server :public ip 5060 ---------------- | asterisk pbx | ---------------- || ---------- ---------- | SER |=======|NAT box |======== private network ---------- ---------- ___________________________________________________________________________ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com

19 years

[Serusers] RADIUS/LDAP

by Felipe Louback

I'm putting my SER to authenticate on a LDAP base using RADIUS. But when I try to authenticate any client, I get the following error: auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: Attribute "User-Password" is required for authentication. modcall[authenticate]: module "ldap" returns invalid for request 0 Into my LDAP, the correct field is userPassword and not User-Password, as RADIUS is looking for... I already set in radiusd.conf: password_attribute = userPassword But still the same error.... Any clues? Felipe -- Master Student - Electrical Engineering Department Computer Engineering and Telecommunications Research Group Universidade Federal de Minas Gerais - Brazil "Humanly speaking it is impossible; but with God anything is possible!" Jesus Christ in Matthews 19:26

19 years

← Newer
1
...
27
28
29
30
31
32
33
...
57
Older →

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 November 2005