Hi!
TAke a look at this line:
Dec 20 14:47:46 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
destination set: $ds=Contact: sip:02111@xx.87.220.xx:6060,
sip:02111@xx.87.220.xx:6060
The destination set include 2 destinations:
sip:02111@xx.87.220.xx:6060 and
sip:02111@xx.87.220.xx:6060
Thus, openser will fork the call with 2 branches (if you take a look at
the message flow you will see 2 INVITEs from openser to Asterisk which
are nearly identical, only the branch parameter in openser's Via header
will be different.)
Asterisk is buggy and does not recognize that the 2 INVITEs are
different branches but think the second INVITE is a retransmission.
Thus when Asterisk accepts the call (accepting on of the two branches),
openser will cancel the other branch. As the second branch is identical
to the first one, it will send the CANCEL to Asterisk. As Asterisk cann
not handle multiple dialog it wil think this is the recently accepted
call and will hang up.
Conclusion: fix your openser config. Probably in your exec script (or
somewhere in openser.cfg) you create a second branch which will be
filled with the same URI as the first destination.
regards
klaus
PS: please always Cc the mailing list.
Md. Samiul Aftad Chowdhury wrote:
> Sorry for quite a late reply...
>
> but i found same scenario when i am sending the call to an asterisk box.
>
> Here is the log you asked for:
>
> In following scenario:
>
> xx.35.32.xx <- My Openser IP which is running on 5060 port
>
> xx.87.220.xx:6060 <- Asterisk Box where i am forwarding the calls
> which is running on 6060 port
>
> xx.88.13.xx <- ipphone ip
>
> Same thing is happening here just after receiving 200 OK Openser
> generating a CANCEL.
>
> i am using :
>
> ============================================
> exec_dset("/usr/local/route"); # here route is a script which returns
> a desired host port (URI)
> append_branch();
> ============================================
>
> to rewrite the host port.
>
>
> Dec 20 14:47:45 openser[17368]: Invite ->
> [CallerID=sip:707234121839@xx.35.32.xx] and [DialedNo=02111]
> Dec 20 14:47:46 openser[17366]: Invite ->
> [CallerID=sip:707234121839@xx.35.32.xx] and [DialedNo=02111]
>
> Dec 20 14:47:46 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> first branch: $br=sip:02111@xx.87.220.xx:6060
> Dec 20 14:47:46 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> all branches: $bR=sip:02111@xx.87.220.xx:6060
> Dec 20 14:47:46 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> destination set: $ds=Contact: sip:02111@xx.87.220.xx:6060,
> sip:02111@xx.87.220.xx:6060
> Dec 20 14:47:46 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> destination uri: $du=
> Dec 20 14:47:46 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> uri: $ru=sip:02111@xx.87.220.xx:6060
>
> Dec 20 14:48:01 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> first branch: $br=<null>
> Dec 20 14:48:01 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> all branches: $bR=
> Dec 20 14:48:01 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> destination set: $ds=<null>
> Dec 20 14:48:01 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> destination uri: $du=
> Dec 20 14:48:01 openser[17366]: oRnbgCwOGh9EngQ1(a)xx.88.13.xx request's
> uri: $ru=sip:02111@xx.87.220.xx:6060
>
>
>
> On 12/7/06, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
>>
>> Hi!
>>
>> I could not find any suspect messages. I guess there is some parallel
>> forking inside openser, thus, the second branch is cancelled when the
>> first branch picks up.
>>
>> Can you add this just before t_relay():
>>
>> xlog("L_INFO","$ci request's first branch: $$br=$br\n");
>> xlog("L_INFO","$ci request's all branches: $$bR=$bR\n");
>> xlog("L_INFO","$ci request's destination set: $$ds=$ds\n");
>> xlog("L_INFO","$ci request's destination uri: $$du=$du\n");
>> xlog("L_INFO","$ci request's uri: $$ru=$ru\n");
>>
>>
>> regards
>> klaus
>>
--
Klaus Darilion
nic.at
Hello,
it was a year full of achievements and events for OpenSER. We had a
major release in summer (1.1.0), and a continuous increase in features
set and robustness. What was new in 1.1.0 was summarized in release news:
http://www.openser.org/index.php?option=com_content&task=view&id=47&Itemid=…
Since then we went though many milestones. We had the first OpenSER
summit where we were able to meet many folks from the lists, have nice
chats and present interesting VoIP solutions based on OpenSER.
http://www.openser.org/index.php?option=com_content&task=view&id=57&Itemid=…
A very important statistic is the number of new modules and features
introduced in current development version after 1.1.0:
- domainpolicy - policies to connect federations
- imc - instant messaging conferencing
- mi_fifo and mi_xmlrpc - FIFO and XMLRPC transports for the new
management interface (MI)
- perl - embed perl programming in configuration file
- presence - SIMPLE Presence Server implementation
- pua, pua_mi, pua_usrloc - presence user agent client implementations
for user location records and management interface
- seas - connector to SIP Application Server - WeSIP - Java SIP Servlet
Application Server (http://www.wesip.eu)
- snmpstats - SNMP (Simple Network Management Interface) interface to
OpenSER statistics
- sst - SIP session timer support
- xmpp - transparent SIP-XMPP gateway
Documentation and news about all these:
http://www.openser.org/docs/modules/1.2.x/http://www.openser.org/index.php?option=com_content&task=blogsection&id=2&I…
A lot of other significant improvements and addons were included in
existing code (management interface, fetch database support, postgres,
usrloc, dialog, enum, acc modules polishing), openser web administrator
was developed. There is not very long time to the next release, along
with few pending new features, the next period will be allocated to
core components like timers, dns and configuration file flexibility. By
end of January we should approach a new testing phase.
This year the OpenSER community collaboration exploded, dokuwiki has lot
of content, many tutorials were submitted, new developers and many
modules sponsored by companies, mailing lists and web forum are places
to get reliable information about OpenSER...
We want to thank to all of you (developers, contributors with patches,
tools and documentation, testers and OpenSER users) for supporting the
project. 2006 was a very good year for OpenSER and 2007 looks very
challenging.
We wish you Merry Christmas and a very Happy New Year!
Hi All,
I am trying presence snapshot SER. I am getting
0(4189) Empty service!
0(4189) ERROR: rls_handler.c:484: XCAP query problems
0(4189) XCAP query failed
error for SUBSCRIBE request. I am following presence handbook. Whats worng i
am doing????? Can anyone help me??
Thanks in advance
Venkat
Hi Elias,
(also fwd. to "users" to let everybody know)
thanks for the contribution. I think that the new SEAS and PERL modules
will give a lot more options when comes to integrate OpenSER with other
application and what is more important , they will allow non-C
extensions :) !!
I will generate the docs and place them on the web also. BTW, are some
default application that I can give a fast try? I would like to test
some real-case apps to get the feeling.
Regards and Merry Christmas,
Bogdan
Elias Baixas wrote:
> Hello everybody,
>
> I just submitted a new module, called SEAS (which stands for Sip
> Express Application Server).
> This module allows a third party to create an Application Server and
> connect it to OpenSER to interoperate seamlessly.
> This permits the Application Server to trigger actions on OpenSER,
> such as sending out a request, or replying a UAS transaction, in some
> way similarly to what can be achieved using fifo, or MI commands
> "t_uac_dlg" and "t_reply", but SEAS provides a much richer API to this
> kind of tasks.
> The module also allows OpenSER to notify the Application Server when
> requests/responses come in, and then transfer the control over the
> incoming request entirely to the Application Server.
> Furthermore, the module implements a binary protocol that transfers
> the SIP message along with information abouth the structure of the
> message's headers (ie. where each header starts, and how long it is),
> so the Application Server doesn't need to reparse the entire SIP
> message, thus improving Application Server's performance very much.
> The SEAS protocol also carries information about the transaction being
> processed at OpenSER for every message, so that the Application Server
> doesn't need to implement all the SIP-transaction machinery, thus
> actually profitting from the highly optimized TM module at OpenSER.
>
> The Application Server can be programmed in any language, because the
> SEAS module comunicates with it through a TCP socket.
>
> At the moment, SEAS module has been written to work with an
> Application Server developed by VozTelecom. It is called WeSIP and can
> be downloaded freely from http://www.wesip.eu . WeSIP is an
> implementation of the SipServlet and HttpServlet standards, so it
> allows a programmer to easily implement Web-Sip converged applications
> (such as Click2call).
> WeSIP is programmed entirely in Java, so you have all the tools and
> facilities from Java and J2EE available to program SIP applications,
> while already using OpenSER to process the SIP messages and
> transactions at the low level, thus profitting both from the high
> performance of OpenSER, and the high-level SIP-Application programming
> framework which is SipServlet and the JAVA languaje.
>
> I hope this module will help create new usage scenarios for OpenSER,
> allowing it to provide high-level Telephony Applications to users.
>
> The module is still in a alpha stage, but should be able for
> production shortly.
>
>
> best regards,
>
> Elias Baixas
>
> VozTelecom, Sistemas
> http://www.wesip.eu
> http://www.voztele.com
>
> _______________________________________________
> Devel mailing list
> Devel(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
Scenario:
I have two test phones setup to a SER server. The two phones are
192.168.2.133 and 192.168.2.101. My server is 192.168.2.1. I can call from
.101 to .133 fine. When I try to place a call from .133 this is what I get.
0(2734) SIP Request:
0(2734) method: <INVITE>
0(2734) uri: <sip:1001@192.168.2.1>
0(2734) version: <SIP/2.0>
0(2734) parse_headers: flags=1
0(2734) Found param type 232, <branch> = <z9hG4bK7e2902f2a>; state=16
0(2734) end of header reached, state=5
0(2734) parse_headers: Via found, flags=1
0(2734) parse_headers: this is the first via
0(2734) After parse_msg...
0(2734) preparing to run routing scripts...
0(2734) parse_headers: flags=128
0(2734) DEBUG:maxfwd:is_maxfwd_present: value = 70
0(2734) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16
0(2734) parse_headers: flags=8
0(2734) DEBUG: get_hdr_body : content_length=586
0(2734) end of header reached, state=9
0(2734) DEBUG: get_hdr_field: <To> [29]; uri=[sip:1001@192.168.2.1]
0(2734) DEBUG: to body [1001 <sip:1001@192.168.2.1>
]
0(2734) DEBUG: add_param: tag=4d4e374f5ebe6ab
0(2734) end of header reached, state=29
0(2734) parse_headers: flags=256
0(2734) get_hdr_field: cseq <CSeq>: <1338505295> <INVITE>
0(2734) is_preloaded: Yes
0(2734) grep_sock_info - checking if host==us: 13==13 && [192.168.2.136]
== [192.168.2.136]
0(2734) grep_sock_info - checking if port 5060 matches port 5060
0(2734) after_loose: Topmost route URI: 'sip:192.168.2.136:5060;lr' is me
0(2734) parse_headers: flags=256
0(2734) found end of header
0(2734) find_next_route: No next Route HF found
0(2734) after_loose: No next URI found
0(2734) grep_sock_info - checking if host==us: 11==13 && [192.168.2.1] ==
[192.168.2.136]
0(2734) grep_sock_info - checking if port 5060 matches port 5060
0(2734) grep_sock_info - checking if host==us: 11==13 && [192.168.2.1] ==
[192.168.2.136]
0(2734) grep_sock_info - checking if port 5060 matches port 5060
0(2734) check_self: host != me
0(2734) DEBUG: t_newtran: msg id=45 , global msg id=43 , T on
entrance=0xffffffff
0(2734) parse_headers: flags=-1
0(2734) parse_headers: flags=60
0(2734) t_lookup_request: start searching: hash=15747, isACK=0
0(2734) DEBUG: RFC3261 transaction matching failed
0(2734) DEBUG: t_lookup_request: no transaction found
0(2734) SER: new INVITE
0(2734) parse_headers: flags=-1
0(2734) check_via_address(192.168.2.133, 192.168.2.133, 0)
0(2734) WARNING:vqm_resize: resize(0) called
0(2734) DEBUG: reply sent out. buf=0x8104e98: SIP/2.0 1...,
shmem=0xb6145728: SIP/2.0 1
0(2734) DEBUG: _reply_light: finished
0(2734) DEBUG: mk_proxy: doing DNS lookup...
0(2734) check_via_address(192.168.2.133, 192.168.2.133, 0)
0(2734) DEBUG: add_to_tail_of_timer[4]: 0xb6143eb8
0(2734) DEBUG: add_to_tail_of_timer[0]: 0xb6143ec8
0(2734) SER: new transaction fwd'ed
0(2734) DEBUG:destroy_avp_list: destroying list (nil)
0(2734) receive_msg: cleaning up
1(2737) DEBUG: timer routine:4,tl=0xb6143eb8 next=(nil)
1(2737) DEBUG: retransmission_handler : request resending (t=0xb6143da0,
INVITE si ... )
1(2737) DEBUG: add_to_tail_of_timer[5]: 0xb6143eb8
1(2737) DEBUG: retransmission_handler : done
0(2734) SIP Request:
0(2734) method: <CANCEL>
0(2734) uri: <sip:1001@192.168.2.1>
0(2734) version: <SIP/2.0>
0(2734) parse_headers: flags=1
0(2734) Found param type 232, <branch> = <z9hG4bK7e2902f2a>; state=16
0(2734) end of header reached, state=5
0(2734) parse_headers: Via found, flags=1
0(2734) parse_headers: this is the first via
0(2734) After parse_msg...
0(2734) preparing to run routing scripts...
0(2734) parse_headers: flags=128
0(2734) DEBUG:maxfwd:is_maxfwd_present: value = 70
0(2734) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16
0(2734) parse_headers: flags=8
0(2734) DEBUG: get_hdr_body : content_length=0
0(2734) end of header reached, state=9
0(2734) DEBUG: get_hdr_field: <To> [29]; uri=[sip:1001@192.168.2.1]
0(2734) DEBUG: to body [1001 <sip:1001@192.168.2.1>
]
0(2734) DEBUG: add_param: tag=4d4e374f5ebe6ab
0(2734) end of header reached, state=29
0(2734) parse_headers: flags=256
0(2734) get_hdr_field: cseq <CSeq>: <1338505295> <CANCEL>
0(2734) is_preloaded: Yes
0(2734) grep_sock_info - checking if host==us: 13==13 && [192.168.2.136]
== [192.168.2.136]
0(2734) grep_sock_info - checking if port 5060 matches port 5060
0(2734) after_loose: Topmost route URI: 'sip:192.168.2.136:5060;lr' is me
0(2734) parse_headers: flags=256
0(2734) found end of header
0(2734) find_next_route: No next Route HF found
0(2734) after_loose: No next URI found
0(2734) grep_sock_info - checking if host==us: 11==13 && [192.168.2.1] ==
[192.168.2.136]
0(2734) grep_sock_info - checking if port 5060 matches port 5060
0(2734) grep_sock_info - checking if host==us: 11==13 && [192.168.2.1] ==
[192.168.2.136]
0(2734) grep_sock_info - checking if port 5060 matches port 5060
0(2734) check_self: host != me
0(2734) DEBUG: t_newtran: msg id=46 , global msg id=45 , T on
entrance=0xffffffff
Bill Hissong
Hi there,
I saw all of you discussed about the postgres and I do have a question which somewhat related to postgres as well (please refer to the end of this email for detail).
My question is that I have Caller ID (regular phone number) mapping to a SIP account stored in postgres, when I call from SIP device to a PSTN phone, telco carrier does not accept the SIP From field and requested to use regular phone number. I use exec_msg to call the external C program which read the Caller ID mapping to SIP account. However, I do not know how to pass this Caller ID into uac_replace_from.
Were the postgres version work for this purpose ? Please advise if you have any suggestion. Thanks in advance,
Don
------------------------------
Message: 5
Date: Thu, 21 Dec 2006 12:20:47 +0200
From: Daniel-Constantin Mierla <daniel(a)voice-system.ro>
Subject: Re: [Users] postgres
To: Klaus Darilion <klaus.mailinglists(a)pernau.at>
Cc: users(a)openser.org
Message-ID: <458A5FFF.4060003(a)voice-system.ro>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello Klaus,
On 12/21/06 12:05, Klaus Darilion wrote:
> Hi Daniel!
>
> I've checked the postgres script: rel_1_1_0 works fine, but there is
a
> problem in unstable: The domain for the default admin user is asked
> not for serweb tables but for the plain openser tables as well. Also
> the subscriber table includes all the serweb columns even if serweb
> tables are not installed.
I think a merge with mysql version, with an option to say the
underlaying DB engine is the right solution, to be easy to maintain --
same as we did with openserctl. I will have that in mind, but the best
will be to register it to tracker.
Cheers,
Daniel
>
> regards
> klaus
>
>
> Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 12/20/06 19:36, Mark Price wrote:
>>>
>>>
>>> On 12/20/06, *Klaus Darilion* < klaus.mailinglists(a)pernau.at
>>> <mailto:klaus.mailinglists@pernau.at>> wrote:
>>>
>>> Hi Mark!
>>>
>>> Postgres should work well - I use it since ser 0.8. Just make
sure
>>> that
>>> the hard disk does not get full, because this breaks the index
>>> inside
>>> postgres and postgres is getting real slow (re-create the index
>>> if it
>>> happens).
>>>
>>> Last time I tested openser_postgres.sh it worked fine. If you
find
>>> a bug
>>> please let us know.
>>>
>>> Please check to use the latest versions from CVS (for 1.1 use
CVS
>>> rel_1_1_0)
>>>
>>>
>>> The latest version from cvs doesn't work out of the box with
openser
>>> build from the release tarball, because the release tarball doesn't
>>> included /usr/sbin/openser_gen_ha1 (although I could get past this
>>> by replacing it with the md5sum equivelant).
>>>
>>> However, the release tarball doesn't work because of this bug:
>>>
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1518732&group_…
>>>
<https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1518732&group_…>
>>>
>>>
>>> So, 1. is the cvs version of rel_1_1_0 considered safe for
>>> production use?
>>
>> yes, it is the most recommended version to use -- several issues
were
>> found and fixed since 1.1.0 release.
>>
>>> 2. if so and there are important fixes such as this in CVS,
>>> would openser.org <http://openser.org> consider
>>> releasing a point release containing such changes?
>> It is an option, and perhaps should be taken in consideration, as
>> patch release with not so much packaging.
>>
>> This may help some which want to maintain platforms updated, it is
>> exampled with 1.0.x, bust just replace the version with 1.1.0 in the
>> document and should work (rel_1_0_0 => rel_1_1_0)
>> http://openser.org/dokuwiki/doku.php/install:openser-from-cvs
>>
>> Cheers,
>> Daniel
>>
>>
>>> Thanks,
>>>
>>> Mark Price
don lin <don12lin(a)yahoo.com> wrote: Hi there,
We have a Postgres Database to store the users' informations before we use Openser. To integrate between Postgres and Openser, we write external C programs and call them from Openser with exec_dset function.
The issue we have now is with the Caller ID. When the user makes a call to PSTN number from SIP devices (soft phone or hard phone), the telco carrier requests us to send a numerical Caller ID, not the SIP format (such as john.dow(a)abc.com). What I am doing is to add the Caller ID field into the Postgres for each user and write a C program to query the Caller ID field, then Openser calls it with exec_dset functioin.
However, I did not find a way to define a variable in Openser to store this Caller ID and pass it to uac_replace_from function.
Appreciate for any suggestions.
Jeff,
You mentioned that you replaced the From Header, may I ask how you do it ?
Thanks and Regards,
Don
------------------------------
<Message: 4
<Date: Tue, 19 Dec 2006 11:11:09 +0900
<From: Jeff Williams <jeffw(a)globaldial.com>
<Subject: [Users] (PR)ACK problem with uac_replace_from
<To: users(a)openser.org
<Message-ID: <45874A3D.5070206(a)globaldial.com>
<Content-Type: text/plain; charset="iso-8859-1"
<I seem to have an issue with uac_replace_from.
<I am using openser as a media proxy. For invites I replace the numbers
<with leading 0's with 61 for Australia and forward the call to our LCR
<box which then forwards the call to the correct voice to pstn gateway.
<I am trying to use uac_replace_from to set the from address so the
<callerid appears correct on the outgoing calls.
<This seems to work fine for the INVITE request, but on subsequent PRACKs
<and ACKs (which just get loose routed), something strange happens to
<the from address.
<On invite, the From get re-written:
<From: Jeff <sip:610089001@proxy.sipone.com;user=phone>;tag=1790577941
<to
<From: Jeff <sip:0892209080@sipone.com>;tag=1790577941
<For the PRACKs and ACKs, this happens:
<From: Jeff <sip:610089001@proxy.sipone.com;user=phone>;tag=1790577941
<to
<From: Jeff
<<\032\317\352S\232\222B\230\234K\231*BV\300\030\303\332\ah\303\306i\365\005\016\200\250\000\000\230\016\200\252j\200\002`\000\000\016>;tag=1790577
<941
<There shouldn't be anything happening to the From address on the
<(PR)ACKs at all.
<Anyone have any ideas?
<I have attached a ethereal dump of the call setup.
<Jeff __________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi,
I've got a few questions:
1. where can I find out what all the variables like uri, myself, etc., mean?
2. how come is_domain_local($ruri) has a different result than uri==myself?
In particular, I have my external IP address defined as an alias. I.e.:
alias=4.2.2.2
When I say if( ! is_domain_local($ruri) ) when $ruri = user(a)4.2.2.2, the
check succeeds.
When I say if( ! uri==myself ), the check fails (correctly, I think).
Thanks,
Mark Price
I am tring to use Ottendorf. I have db tables for
0.9.6 on the machine, so I decide to drop the old
tables and create new tables using ser_mysql.sh for
Ottendorf, but the script keeps on giving me errors.
Do I have to delete the entire old version of SER
(0.9.6)?
thanks,
Joy
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com