Hello,
On 1/24/13 8:27 PM, Andreas Granig wrote:
Hi,
On 01/24/2013 06:35 PM, Daniel-Constantin Mierla wrote:
What cool extensions would that be? I guess the sems guys would be
happy to fix it, if it breaks something unexpectedly.
well, see, you just hit your (business) head! Why I should sha
Hi,
On 01/24/2013 06:35 PM, Daniel-Constantin Mierla wrote:
What cool extensions would that be? I guess the sems guys would be
happy to fix it, if it breaks something unexpectedly.
well, see, you just hit your (business) head! Why I should share with
the sems guy the ideas about my cool featur
I am not using this module and I don't know what are supposed to be the
right default values for flags. But it should be like it was in the
past. If you used with an older version 3.x, apart of renaming, nothing
was touched in the code for 4.x.
Cheers,
Daniel
On 1/24/13 4:27 PM, Philippe Sult
Hello,
On 1/24/13 5:25 PM, Andreas Granig wrote:
Hi,
On 01/24/2013 04:49 PM, Daniel-Constantin Mierla wrote:
there is no need for an sbc and break the call in two legs and drop my
cool extensions I have in my softphone.
What cool extensions would that be? I guess the sems guys would be
happ
>
> Maybe Kamailio could report an error in the logs when the unrecognised
> transport type is submitted?
That could be handy. I am not sure how/where to put something like this
though.
> Interesting, I had those routing problems initially, so I added the
> add_contact_alias() to my script b
Hi,
On 01/24/2013 04:49 PM, Daniel-Constantin Mierla wrote:
there is no need for an sbc and break the call in two legs and drop my
cool extensions I have in my softphone.
What cool extensions would that be? I guess the sems guys would be happy
to fix it, if it breaks something unexpectedly.
On 24 January 2013 16:05, Peter Dunkley wrote:
> **
> OK. It looks like you have a bug in the client SIP over WebSocket stack.
>
> ;transport=wss (as you have on the R-URI) is not correct. It should be
> ;transport=ws whether it is WS or WSS. The R-URI in the NOTIFY will be the
> contact that t
Hi,
while trying to use sipcapture together with PostgreSQL I've found that it
stores the "\r\n" in SIP messages as "\015\012", though not without a lot
of noise in the PostgreSQL log files.
For every line inserted in PostgreSQL I get:
[0] WARNING: nonstandard use of \\ in a string literal at
OK. It looks like you have a bug in the client SIP over WebSocket
stack.
;transport=wss (as you have on the R-URI) is not correct. It should
be ;transport=ws whether it is WS or WSS. The R-URI in the NOTIFY will
be the contact that the client stack put into the SUBSCRIBE - so this
wss is probab
Hello,
On 1/24/13 4:34 PM, Andreas Granig wrote:
Hi Daniel,
On 01/24/2013 03:55 PM, Daniel-Constantin Mierla wrote:
The latest version has support for using dialog to store the From/To
values, so no masking within rr param. It should work fine in your case,
I guess.
For earlier version, you c
This is the ruri:
NOTIFY sips:pete@10.15.20.113:55536;rtcweb-breaker=no;transport=wss
SIP/2.0\r\n
There is only one Via header:
Via: SIP/2.0/TLS 10.15.20.170:443;branch=z9hG4bK8455.12ffc4c6.0\r\n
And the Contact:
Contact: \r\n
Contact looks suspicious as ws instead of wss?
Does Kamailio use the
OK. This sounds like the NOTIFY is not being routed through the
WebSocket module then. Instead it is coming out as a raw SIP message.
This would explain a lot. This could well be caused by the routing
within Kamailio not being quite right. For example, if
the ;transport=ws parameter is missing
Hi Daniel,
On 01/24/2013 03:55 PM, Daniel-Constantin Mierla wrote:
The latest version has support for using dialog to store the From/To
values, so no masking within rr param. It should work fine in your case,
I guess.
For earlier version, you can achieve more or less the same by storing
from/to
Hi Peter, thanks for that info.
It looks like all the packets marked Websocket in Wireshark are coming
across OK from Kamailio. The first nibble is always 1000 as expected.
However I notice now that whenever a NOTIFY is sent out from Kamailio the
packet is *not* a Websocket packet, it's identifie
Thank you Daniel, your answer helped a lot.
With :
#!KAMAILIO
loadmodule "pv.so"
$avp(fd.did)
Everything works fine, but only if I turn off caching with :
modparam("uid_domain", "db_mode", 0)
Otherwise, avps are not loaded from the db. Digging into
modules/uid_domain/domain.c, I figured out that
Hello,
I got in a similar situation quite recently. I checked the code and the
way it was designed, leads to this behavior (because the inital value
and the new one are XOR'ed, iirc). If it is changing the domain part, is
not much to do. In my case was adding a useless uri parameter and I
tho
The RSV1 bit (which is the compressed bit) should be the second bit from the
left in the WebSocket frame. The first bit is the FIN (should always be one
here), then you have RSV1, RSV2, and RSV3, and the last nibble of the first
byte will be the opcode.
Regards,
Peter
On 24 Jan 2013, at 14:4
Chrome 26, 24 and Firefox nightly all exhibit the same behaviour.
I've decrypted the packets in wireshark, could you point me at what I am
looking for to see the compressed bit?
Wireshark reports (on what seems to be the problematic frame) "This frame
ACKs a segment we have not seen"
On 24 Janu
Hi,
This is a question for kamailio 3.0.x and I'm still trying to reproduce
this issue somehow for latest stable, but maybe it was a known issue
anyways which got fixed in newer versions, so I don't have to dig deeper
into this:
There is an INVITE "A -> kamailio -> B", and kamailio does
uac
Have you checked to see if there are any known bugs in the browser you
are using?
As the WebSocket message compression stuff is still draft the browser
implementation probably won't be complete or fully tested yet.
As I said, the Kamailio WebSocket implementation does not support any
extensions a
Hi Peter
I can confirm it works correctly for WS and not WSS, and it appears to be
only the NOTIFY request in the direction of Kamailio > UAC. INVITE requests
in the direction of Kamailio > UAC are fine.
I've tried it with the tls tls_disable_compression flag set to both 0 and 1
Pete
On 24 Jan
Sorry had wrong branch here it is ff22a1cbc2b817d63611b3da967d8245e11cb84c.
On 24 January 2013 12:55, Gareth Rylance wrote:
> I cant see the patch in master. Can you?
>
>
> On 21 January 2013 20:13, Richard Brady wrote:
>
>> Patch attached.
>>
>> Should this be cross posted to [sr-dev] if it
I cant see the patch in master. Can you?
On 21 January 2013 20:13, Richard Brady wrote:
> Patch attached.
>
> Should this be cross posted to [sr-dev] if it contains a patch?
>
> Richard
>
>
> On 7 January 2013 01:10, Richard Brady wrote:
>
>> Agreed, doesn't make sense to me either.
>>
>> The
Hello,
A while ago I came across the siptrace and sipcapture modules and thought this
would be a good way to generate logging out of all the SIP messages that are
passed through Kamailio and stored in the siptrace/sipcapture table.
My idea was to extract certain values from SIP messages and stor
The sript compatibility was set to kamailio strict mode, throwing error
if $xy was not a pv. You can fetch latest master and should work like if
no pv found as $xy, then is set as avp.
Even if with your version, adding #!SER as first line should make it
work with $fd.did...
Cheers,
Daniel
O
Hi Philippe,
On 1/23/13 11:54 PM, Philippe Sultan wrote:
Hey Daniel,
Thanks a lot for your help.
do you have #!SER as first line? This part should be the same ...
if pv not found, then it should be considered avp. I will try to
see what is the issue.
I don't have #!SER
it shoul
Hi,
I've done some checking online and in the code. The compressed bit is
defined in draft-ietf-hybi-permessage-compression and uses the RSV1 bit
from the WebSocket frame header. As per RFC 6455 the Kamailio WebSocket
implementation is careful to leave RSV1, RSV2, and RSV3 with values of
0.
As
Just fyi, tls compression is disabled by default in the tls module:
-
http://kamailio.org/docs/modules/stable/modules/tls.html#tls_disable_compression
But you can try with it set and see what happens.
Cheers,
Daniel
On 1/24/13 10:09 AM, Peter Dunkley wrote:
I shod also add that the Kamailio W
I shod also add that the Kamailio WebSocket implementation does not support any
extensions. So unless the deflate frame extension is implicit for TLS it will
not be negotiated. Further, the implementation does not set any compressed
bits and all unused flags etc should be zeroed automatically
I am not sure how to investigate this. It sounds like it might be a TLS
related problem (or a WebSocket/TLS interworking problem in Kamailio). I don't
know anything about the Kamailio TLS implementation - I just drop WebSocket
frames into it as required.
I did do (a little) WSS testing and sa
Hi olle
You are my preferrerd guru :-)
My idea is kamailio on frontend and the pbx behind, so i will test and i will
inform you.
About ipv6 the computer say yes :) and in the half of this year ;-)
BlackBerry de movistar, allí donde estés está tu oficin@
-Original Message-
From: "Olle
23 jan 2013 kl. 22:37 skrev andrea mucci :
> Hi Gurus,
>
> i have a basic question.
>
> i have a SIP PBX server that don't have the Multi Tenant Feature or Multi
> Company Feature.
> i now that Kamailio support this feature, so
>
> is possible to use the kamailio as registrar server and redi
Hi Gurus,
i have a basic question.
i have a SIP PBX server that don't have the Multi Tenant Feature or Multi
Company Feature.
i now that Kamailio support this feature, so
is possible to use the kamailio as registrar server and redirect all the
services, SUBSCRIBE, NOTIFY, and RTP to the SIP P
33 matches
Mail list logo
