Dear all,
i'm trying to have call pickup with SER (i use ser 0.9.6), i mean i'd
like to have the capability to pick up a call that is directed to
another user while the other user telephone is ringing.
Is there someone that suceeded in this features?
If it is not possible to get this feature by configuriation of ser (i
mean using already present ser functions), is there someone that can
suggest how to implemente such features? (for istance with external
scripts,or with avpops, or using fifo, or writing a new ser module).
Maybe the use of fifo could help, in particular i saw the ctd.sh example
that is able to iniziate a call for two users using t_uac_dlg fifo
function. I tryed to use t_uac_dlg to send a CANCEL to a transaction in
progress (in the 180 ringing status) (taking by hand parameters like
Call-ID, tag, branch etc.), but it seems that t_uac_dlg is not able to
interact with the transaction in progress because it creates one
different transaction. Is it real, or am i wrong?
This is some log for this attempt:
################################################################
1(17187) INFO: fifo_server: command empty
1(17187) fifo_get_method: method: 'CANCEL'
1(17187) DEBUG: fifo_get_ruri: 'sip:801@x.x.x'
1(17187) DEBUG: fifo_get_nexthop: next hop empty
1(17187) fifo_get_headers: headers: To: <sip:801@x.x.x>
From: Stefano<sip:803@x.x.x>;tag=237abc61
Call-ID: 262a660822777d26
CSeq: 2 CANCEL
1(17187) parse_headers: flags=-1
1(17187) end of header reached, state=9
1(17187) DEBUG: get_hdr_field: <To> [28]; uri=[sip:801@x.x.x]
1(17187) DEBUG: to body [<sip:801@x.x.x>
]
1(17187) get_hdr_field: cseq <CSeq>: <2> <CANCEL>
1(17187) DEBUG: fifo_uac: parse_headers succeeded
1(17187) fifo_get_body: body:
1(17187) DEBUG: add_param: tag=237abc61
1(17187) end of header reached, state=29
1(17187) DEBUG: fifo_uac: EoL -- proceeding to transaction creation
1(17187) DEBUG:tm:t_uac: next_hop=<sip:801@x.x.x>
1(17187) DEBUG: mk_proxy: doing DNS lookup...
1(17187) get_record: lookup(_sip._udp.x.x.x, 33) failed
1(17187) sip_resolvehost: no SRV record found for x.x.x, trying
'normal' lookup...
1(17187) DEBUG:destroy_avp_list: destroying list (nil)
1(17187) DEBUG: dlg2hash: 55633
1(17187) DEBUG: add_to_tail_of_timer[4]: 0xb5ba0ac0
1(17187) DEBUG: add_to_tail_of_timer[0]: 0xb5ba0ad0
1(17187) **** done consume
2(17188) SIP Request:
2(17188) method: <CANCEL>
2(17188) uri: <sip:801@x.x.x>
2(17188) version: <SIP/2.0>
2(17188) parse_headers: flags=1
2(17188) Found param type 232, <branch> = <z9hG4bK159d.9169633.0>; state=16
2(17188) end of header reached, state=5
2(17188) parse_headers: Via found, flags=1
2(17188) parse_headers: this is the first via
2(17188) After parse_msg...
2(17188) preparing to run routing scripts...
2(17188) parse_headers: flags=128
2(17188) end of header reached, state=9
2(17188) DEBUG: get_hdr_field: <To> [28]; uri=[sip:801@x.x.x]
2(17188) DEBUG: to body [<sip:801@x.x.x>
]
2(17188) get_hdr_field: cseq <CSeq>: <2> <CANCEL>
2(17188) DEBUG: get_hdr_body : content_length=0
2(17188) found end of header
2(17188) DEBUG: is_maxfwd_present: max_forwards header not found!
2(17188) DEBUG: add_param: tag=237abc61
2(17188) end of header reached, state=29
2(17188) parse_headers: flags=256
2(17188) find_first_route: No Route headers found
2(17188) loose_route: There is no Route HF
2(17188) is_local(): Realm 'x.x.x' is local
2(17188) DEBUG: t_newtran: msg id=9 , global msg id=8 , T on
entrance=0xffffffff
2(17188) parse_headers: flags=-1
2(17188) parse_headers: flags=60
2(17188) t_lookup_request: start searching: hash=55633, isACK=0
2(17188) DEBUG: RFC3261 transaction matching failed
2(17188) DEBUG: t_lookup_request: no transaction found
2(17188) DBG: trans=0xb5ba1488, callback type 1, id 0 entered
2(17188) parse_headers: flags=44
2(17188) DEBUG: t_lookupOriginalT: searching on hash entry 55633
2(17188) DEBUG: RFC3261 transaction matching failed
2(17188) DEBUG: t_lookupOriginalT: no CANCEL matching found!
2(17188) DEBUG: t_lookupOriginalT completed
2(17188) DEBUG: mk_proxy: doing DNS lookup...
2(17188) get_record: lookup(_sip._udp.x.x.x, 33) failed
2(17188) sip_resolvehost: no SRV record found for x.x.x, trying
'normal' lookup...
2(17188) check_via_address(x.x.x.x, x.x.x.x, 0)
################################################################
Another thing, i saw that t_uac_cancel, instead, is able to interact
with an existing transaction, by sending CANCEL to called and 487 to
caller (using t_lookup_callid function to get transaction from callid
and cseq). Does someone think that it is possible to modify t_uac_cancel
to handle basic pickup functions? (that should be CANCEL for the called
side and redirect for caller towards pickup user)
This is some log for this case:
##################################################################
1(16115) INFO: fifo_server: command empty
1(16115) DEBUG: fifo_uac_cancel: ############### begin ##############
1(16115) DEBUG: fifo_uac_cancel: callid="0b29c5266716aa67"
1(16115) DEBUG: fifo_uac_cancel: cseq="2"
1(16115) created comparable call_id header field: >Call-ID:
0b29c5266716aa67
<
1(16115) created comparable cseq header field: >CSeq: 2 INVITE<
1(16115) just locked hash index 37328, looking for transactions there:
1(16115) we have a match: callid=>>Call-ID: 0b29c5266716aa67
<< cseq=>>CSeq: 2<<
1(16115) DEBUG: t_lookup_callid: transaction found.
1(16115) DEBUG: fifo_uac_cancel: now calling cancel_uacs
1(16115) DEBUG: cancel_branch: sending cancel...
1(16115) DEBUG: add_to_tail_of_timer[4]: 0xb5b763f0
1(16115) DEBUG: add_to_tail_of_timer[0]: 0xb5b76400
1(16115) DEBUG: fifo_uac_cancel: ################ end ##############
##################################################################
Thank you very much for your help
Stefano Blasco
Hi,
I have a DSL router, which has only one port. To connect multiple
computers I have another 4 ports router behind this DSL router. So SER
is behind two routers. How can I configure these two routers so that I
can use SER in this situation?
Thanks,
Hi SER users and devs,
During the past few months we, at Iptego, have been working on a
security and monitoring application for SIP sites, one of the recurring
subjects of the SER user meeting in Prague ;-). To be short, VSP is a
network intrusion detection system, which can sniff the VoIP traffic,
parse SIP messages and create alerts when something seems wrong.
As the project evolved, we have presented our work to the iptel.org
staff and, together with them, decided to make the monitoring extension
of VSP available to all public. So, if you're interested in real time
statistics of the iptel.org SIP site, or in the repartition of
User-Agents, you can create your own graphs here:
http://fly.iptel.org/vsp/
We have already received great feedback from the iptel.org guys and I
hope to get even more from the rest of community.
Disclaimer: The project is BETA for now and the graphs haven't been
verified yet. I wouldn't use them for anything important.
Cheers,
Tudor Golubenco
--
Dipl. Ing. Tudor Golubenco
Software Engineer
iptego GmbH
Am Borsigturm 40,
13507 Berlin, Germany
http://www.iptego.de
Hi!
I've noticed that (at least on my boxes) x-lite uses a different
source-port for the sip-connection than the one that is announced in the
Via-header. (See the example below.)
This behavior results in nat_uac_test(16) always reporting that the
client is behind a NAT.
Can anyone confirm this behavior? Is it a bug in X-Lite or is there any
good reason for it?
Cheers,
--leo
-------------------- 8< --------------------
No. Time Source Destination Protocol
Info
4 0.000808 137.208.90.164 137.208.89.45 SIP
Request: REGISTER sip:wu-wien.ac.at
Frame 4 (640 bytes on wire, 640 bytes captured)
Ethernet II, Src: DellEsgP_85:83:ea (00:0b:db:85:83:ea), Dst:
Cisco_f3:2e:80 (00:0d:29:f3:2e:80)
Internet Protocol, Src: 137.208.90.164 (137.208.90.164), Dst:
137.208.89.45 (137.208.89.45)
Transmission Control Protocol, Src Port: 1831 (1831), Dst Port: 5060
(5060), Seq: 1, Ack: 1, Len: 586
Source port: 1831 (1831)
Destination port: 5060 (5060)
Sequence number: 1 (relative sequence number)
[Next sequence number: 587 (relative sequence number)]
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Window size: 1028096 (scaled)
Checksum: 0x491e [correct]
Session Initiation Protocol
Request-Line: REGISTER sip:wu-wien.ac.at SIP/2.0
Message Header
Via: SIP/2.0/TCP
137.208.90.164:1676;branch=z9hG4bK-d87543-bd24cf102007467f-1--d87543-;rport
Max-Forwards: 70
Contact:
<sip:30001@137.208.90.164:1676;rinstance=7ce462f932219953;transport=TCP>
To: "Alexander Bergolth"<sip:30001@wu-wien.ac.at>
From: "Alexander Bergolth"<sip:30001@wu-wien.ac.at>;tag=b904b134
Call-ID: N2VjNGQxYzZlOWNiYWU5OTMwNzQ4OTZkMWU3NmRkYTE.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY,
MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite release 1006e stamp 34025
Content-Length: 0
-------------------- 8< --------------------
--
e-mail ::: Alexander.Bergolth (at) wu-wien.ac.at
fax ::: +43-1-31336-906050
location ::: Computer Center | Vienna University of Economics | Austria
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello WeSIPer,
I found a little but annoying Error in WeSIP's C2C application. I send
back a 483 reply on a C2C's first caller-INVITE to WeSIP via openser's
sl-send_reply(). I expected that C2C terminates the call function, cause
C2C has an error handling method for 4xx replies, but nothing happens.
openser as wesip's frontend received definately the reply.
By chance I found, that the reason for this was my reply message.
This doesn't work with WeSIP's C2C application:
sl_send_reply("483", "My message\n");
But this works:
sl_send_reply("483", "My message");
It seems, that C2C's or WeSIPs reply parser has some problems with
linefeeds at the end of reply's message text.
I use openser 1.2.0, WeSIP 0.1.4 and click2call-08_11_06
regards
Helmut
PS: Is there already a fix for WeSIP to reconnect to openser's seas
socket, when openser restarts?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGUa8R4tZeNddg3dwRAscvAKDC49yJRkA4ALOCoC5naJzr9gavMwCff7vX
oEc4vGa8tEP5r0IVMhvC+jA=
=dMZ6
-----END PGP SIGNATURE-----
Hi All,
I am new to Openser and propably answer to my question is very simple.. I,ve been trying to run Openser with Mediaroxy behind NAT (they both work on a same machine with a private IP - 192.168.1.x). I am connected to internet through ADSL router (dynamic IP). I ve tried few configurations and I cant get it to work - I have "no audio problem" with nated users who register from outside of my LAN. I ve read that mediaproxy must listen on a public IP address, but first I thought that this is just a matter of port forwarding. And here is my question: Is it possible for this to work with described configuration? (Openser with mediaproxy both behind NAT) I ve used similar solution with Asterisk and Xtunnels and it worked fine. Thanks in advance and sorry for my English:). Best regards, Maciek Kowalski
Spam detection software, running on the system "mail.iptel.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hi. I have a question. I use x_lite do client,and ser
server do route. if user1 is 1001 and user2 is 1002, assumes i used 1001
to dial 999991002, I thinking in the ser.conf, first to remove the
prefix(99999),then route to 1002. if used asterisk the idea is ok but I
don't know ser whether to achieve? [...]
Content analysis details: (9.8 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
4.1 FROM_ILLEGAL_CHARS From: has too many raw illegal characters
-0.0 SPF_PASS SPF: sender matches SPF record
0.5 HTML_40_50 BODY: Message is 40% to 50% HTML
0.0 HTML_MESSAGE BODY: HTML included in message
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.5035]
0.0 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.2 DNS_FROM_RFC_ABUSE RBL: Envelope sender in abuse.rfc-ignorant.org
2.2 RCVD_IN_WHOIS_INVALID RBL: CompleteWhois: sender on invalid IP block
[202.105.45.47 listed in combined-HIB.dnsiplists.completewhois.com]
1.7 DNS_FROM_RFC_POST RBL: Envelope sender in
postmaster.rfc-ignorant.org
1.1 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.
Hi all,
I was testing OpenSER presence functionality using eyebeam and a softphone
developed by my team. The OFFLINE state with eyebeam worked perfectly, but
with my softphone it didn't work. I set force_active = 1. XML sent by
PUBLISH and OpenSER log are below. Can anyone help me?
Thanks, Hildebrando
PIDF XML:
<?xml xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:hildebrando@voip.maritaca">
<presence>
<tuple id="">
<status>
<basic>closed</basic>
</status>
<note>offline</note>
</tuple>
</presence>
The basic difference between my application and eyebeam is that eyebeam uses
RPID XML and I use PIDF XML.
OPENSER LOG:
3(26039) PRESENCE: update_presentity: The presentity status is offline; do
not send notify
Hello Community,
Does anyone know whether it's possible to install the current recommended MYSQL on SUSE Linux. I have a Machine with a SUSE installed on it. I have successfully installed SER 0.9.6 but now I would like to have MYSQL for authentication support. Does the SER's recommended MYSQL work with SUSE?. I only see the talk about Redhat and Debian so unsure if it works with SUSE.
Many thanks for in advance.
Cyprian.
----------
___________________________________________________________
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship.
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
Hi guys,
I'm having a problem about asterisk dropping calls received from OpenSER
The problems was spotted at Asterisk users mailing lists
http://lists.digium.com/pipermail/asterisk-users/2007-April/184875.html
Asterisk complains about an ACK not received and drops the calls.
It expects OpenSER to send an ACK back to its '200 OK' when the call is
set up
Is that a problem OpenSER should solve ???
Tnx in advance
Regards
Edoardo Serra
WeBRainstorm S.r.l.