Hi,
yes I can agree now, linphone is working well, qjsimple has some problem..but
maybe just want more testing. Bria 3.0 also does not support IPv6
palo
> -Original Message-
> From: sr-users-boun...@lists.sip-router.org [mailto:sr-users-
> boun...@lists.sip-router.org] On Behalf Of Schu
Hey,
On 20.04.2011 08:48, Daniel-Constantin Mierla wrote:
>> On 12.04.2011 12:57, Daniel-Constantin Mierla wrote:
>>> soon we should sketch the roadmap for the next major release 3.2. There
>>> are some private git branches with lot of work on it, so we need to
>>> synchronize a bit and decide ab
looks like core stats counts xmlrpc requests served by
route [xmlrpc_requests]
as unsupported_methods.
is there anything a user can do about it or is it a bug that should be
fixed?
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-user
Am 20.04.2011 11:01, schrieb Pavel Segeč:
> Hi,
>
> yes I can agree now, linphone is working well, qjsimple has some problem
If you find some problems (except that it does not work over TCL/TLS:
http://trac.pjsip.org/repos/ticket/1127) please let me know.
klaus
___
On 19 April 2011 13:12, Roman Yeryomin wrote:
>
> ok, here is the backtrace:
>
> # gdb kamailio core
> ...
> Reading symbols from /usr/local/lib/kamailio/modules_k/perlvdb.so...done.
> Loaded symbols for /usr/local/lib/kamailio/modules_k/perlvdb.so
> ...
> Core was generated by `kamailio -'.
>
On 4/20/11 1:54 PM, Roman Yeryomin wrote:
On 19 April 2011 13:12, Roman Yeryomin wrote:
ok, here is the backtrace:
# gdb kamailio core
...
Reading symbols from /usr/local/lib/kamailio/modules_k/perlvdb.so...done.
Loaded symbols for /usr/local/lib/kamailio/modules_k/perlvdb.so
...
Core was ge
Hi,
When kamailio-3.1 sends OPTIONS for natping, the Via branch is wrong, e.g:
OPTIONS sip:192.168.51.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0.
Route:
Should be branch=z9hG4bK instead of branch=0, right? When a
reply comes back, like this...
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
On 04/20/2011 04:47 PM, Andreas Granig wrote:
Hi,
When kamailio-3.1 sends OPTIONS for natping, the Via branch is wrong, e.g:
OPTIONS sip:192.168.51.1:5060 SIP/2.0.
Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0.
Route:
Hello
Check the syn_branch global parameter... must be 1 i think so that it
marius zbihlei writes:
> Check the syn_branch global parameter... must be 1 i think so that it
> creates a SIP 2.0 compliant branch. The default is imho bad and I will
> change it soon.
marius,
for rfc3261 compliance, it needs to be 0. see 'about syn_branch'
sr-users thread.
-- juha
___
Hi, I have implemented kamailio with asterisk, I want to enable BLF using
kamailio instead of asterisk. I would appreciate any kind of help, below I'm
pasting my configuration.
*I'm testing with an Aastra phone, when phone sends the subscription
kamailio answers with:*
U 192.168.15.22:5060 -> 19
Hi,
On 04/20/2011 04:05 PM, Juha Heinanen wrote:
> for rfc3261 compliance, it needs to be 0. see 'about syn_branch'
> sr-users thread.
That's my understanding now also, however it doesn't fix the (cosmetical
- at least for me) branch=0 issue with locally generated OPTIONS
requests in the nathelp
Lucas,
It's not possible to answer your question without at least a
corresponding SUBSCRIBE message from Aastra.
On 20.04.2011 17:17, Lucas Alvarez wrote:
Hi, I have implemented kamailio with asterisk, I want to enable BLF
using kamailio instead of asterisk. I would appreciate any kind of help
Andreas Granig writes:
> That's my understanding now also, however it doesn't fix the (cosmetical
> - at least for me) branch=0 issue with locally generated OPTIONS
> requests in the nathelper module:
>
> OPTIONS sip:192.168.51.1:5060 SIP/2.0
> Via: SIP/2.0/UDP 127.0.0.1:5062;branch=0
ok, i have
Thank you Andrew for your quick answer.
*This is the subscribe message:*
U 192.168.15.108:5060 -> 192.168.15.22:5060
SUBSCRIBE sip:1104@192.168.15.22:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.15.108;branch=z9hG4bKa54a155ad67706dca.
Proxy-Authorization: Digest
username="1104",realm="192.168.15.22",no
Lucas,
It seems the Aastra is not configured for BLF, the SUBSCRIBE below is
for "message-summary", not dialog info.
Kamailio is sending the list of supported events in Allow-Events:
presence.winfo, presence, dialog
On 20.04.2011 17:45, Lucas Alvarez wrote:
Thank you Andrew for your quick ans
Hi,
your client is not subscribing to BLF, but to "Event:
message-summary." (e.g. Mailbox lamp on your phone).
Carsten
2011/4/20 Lucas Alvarez :
> Thank you Andrew for your quick answer.
> This is the subscribe message:
> U 192.168.15.108:5060 -> 192.168.15.22:5060
> SUBSCRIBE sip:1104@192.168.1
On 20 April 2011 15:24, Daniel-Constantin Mierla wrote:
> On 4/20/11 1:54 PM, Roman Yeryomin wrote:
>>
>> On 19 April 2011 13:12, Roman Yeryomin wrote:
>>>
>>> ok, here is the backtrace:
>>>
>>> # gdb kamailio core
>>> ...
>>> Reading symbols from /usr/local/lib/kamailio/modules_k/perlvdb.so...do
Am 20.04.2011 16:41, schrieb Juha Heinanen:
> Andreas Granig writes:
>
>> That's my understanding now also, however it doesn't fix the (cosmetical
>> - at least for me) branch=0 issue with locally generated OPTIONS
>> requests in the nathelper module:
>>
>> OPTIONS sip:192.168.51.1:5060 SIP/2.0
Klaus Darilion writes:
> I think a constant branch wouldn't be RFC 3261 compliant.
perhaps not, but at least it is harder to detect non-compliant than 0
when use of 0 has been justified by need to save cpu cycles.
in my opinion, default should be rfc3261 compliant branch value.
-- juha
___
Juha Heinanen writes:
> looks like core stats counts xmlrpc requests served by
>
> route [xmlrpc_requests]
>
> as unsupported_methods.
>
> is there anything a user can do about it or is it a bug that should be
> fixed?
this gets more and more confusing. file core_stats.h does not list
unsuppo
On 4/20/11 7:51 PM, Juha Heinanen wrote:
Juha Heinanen writes:
looks like core stats counts xmlrpc requests served by
route [xmlrpc_requests]
as unsupported_methods.
is there anything a user can do about it or is it a bug that should be
fixed?
this gets more and more confusing. file core
Daniel-Constantin Mierla writes:
> Of course a filter can be done in the
> kex module to skip http request types, but does it give any benefits
> overall?
the stat becomes meaningless when proper supported messages (GET) get
counted as unsupported. they should only be counted as unsupported if
On 4/21/11 6:39 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Of course a filter can be done in the
kex module to skip http request types, but does it give any benefits
overall?
the stat becomes meaningless when proper supported messages (GET) get
counted as unsupported. they sh
23 matches
Mail list logo
