Re: [SR-Users] Minimal configuration without database support

[Eugene Prokopiev]

> Which module/function need I use to simple forward any
> request/responce to another sip server?

Is forward function enought for me -
http://www.kamailio.org/wiki/cookbooks/4.1.x/core#forward ? I tried to
use:

route {
  $du = "sip:10.10.10.50:5060;transport=udp";
  forward();
}

but I can't see any outgoing sip requests in tcpdump :(

-- 
WBR,
Eugene Prokopiev

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Minimal configuration without database support

[Eugene Prokopiev]

> Is it possible to run kamailio without database support (even dbtext)?

Yes, minimal stub may be looks like:

loadmodule "mi_fifo.so"
loadmodule "kex.so"
loadmodule "sl.so"

modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")

route {
  sl_send_reply("503", "Server is not configured");
}

Which module/function need I use to simple forward any
request/responce to another sip server?

-- 
WBR,
Eugene Prokopiev

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Minimal configuration without database support

[Eugene Prokopiev]

Hi,

Is it possible to run kamailio without database support (even dbtext)?
Where can I find minimal configuration example with minimal modules
set only for forwarding any requests/responses from one ip address to
another one?

-- 
WBR,
Eugene Prokopiev

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

[Alex Balashov]

On 08/25/2014 07:25 PM, Alex Villací­s Lasso wrote:


However, I do not find an equivalent to bridge mode in the rtpengine
command-line parameters.


Bridging mode of this type is not supported by rtpengine.

--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

Please be kind to the English language:

http://www.entrepreneur.com/article/232906

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

[Alex Villací­s Lasso]

I have a rtpproxy configuration that spawns several rtpproxy instances, using 
bridge mode. An example is shown below:

/usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s udp:127.0.0.1 
7723 192.168.2.18/127.0.0.1 -m 1 -M 2

Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .

Now I want to migrate to rtpengine with the rtpproxy-ng module in kamailio. However, I do not find an equivalent to bridge mode in the rtpengine command-line parameters. I see the --ip=IP parameter, but the source code expects a single IP address, and 
cannot be specified more than once. The closest I see is the --advertised-ip=IP parameter, but I am not sure that it will do what I need.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Roadmap to next major release - v4.2.0

[Daniel-Constantin Mierla]

Hello,

during the last devel meeting on IRC, done before the summer, we set the 
4.2.0 release time frame for this autumn.


As planned by that moment, we have to decide the development freezing 
date and more accurate milestones at the end of summer, therefore it is 
about the time.


My proposal is to freeze development by end of September 10, 2014, have 
about one month of testing and release sometime around mid of October.


If anyone has constraints to meet this date, just send here another 
proposal and we can decide together which one fits most of us.


This one gives about 2 weeks and a half for new features development. 
Therefore, if you plan to include a new module (many were announced at 
the IRC devel meeting, hopefully some are ready), hurry up.


It is also a good time to start filling the wiki page with what is new 
in upcoming release:

- http://www.kamailio.org/wiki/features/new-in-devel

Cheers,
Daniel

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to uniquely identify SIP WS / WSS endpoint

[Muhammad Shahzad]

OK, this is interesting. However, i think the received parameter and rport
are added by kamailio, so it can only be checked for outgoing messages,
these will still be unavailable in incoming messages. Is this correct or
they will be available in every incoming messages too (except of course the
the very first incoming messages)?

Looking at RFC7118, it says the WS VIA header domain part will contain
"random string" followed by ".invalid" to make it a correct domain name.
This may provide some uniqueness, though this random string may not
necessarily be unique as well.

Thank you.




On Mon, Aug 25, 2014 at 5:23 PM, Vitaliy Aleksandrov  wrote:

>  When kamailio processes a request script writer can check if there any
> Route header or valid  R-URI or R-URI alias parameter to determine the
> destination. You can check it manually maybe reusing kamailio sip parser.
>
> As you've already said to find a destination where kamailio is going to
> send a reply you can parse via header or its "received" and "rport"
> parameters. Even when via doesn't have valid destination (ws/wss transport)
> it has correct "received" and "rport" parameters which kamailio adds during
> a request processing.
>
> "Via" header in INVITE received from WSS client and forwarded to a
> destination looks like this:
> "Via: SIP/2.0/WSS
> df7jal23ls0d.invalid;received=1.2.3.4;branch=z9hG4bKTp9lzCApgHsdbRUrFcZ4XTCI49EZbbDf;rport=37213"
>
>
>Not really, the main context of this question is in reference to this
> thread,
>
> https://www.mail-archive.com/sr-users@lists.sip-router.org/msg19962.html
>
>  A patched to allow network IO intercept in kamailio corex module was add
> to trunk as discussed in this thread,
>
> https://www.mail-archive.com/sr-users@lists.sip-router.org/msg20183.html
>
>  Currently i am able to compress / decompress entire sip message coming
> from or going to remote endpoint in kamailio server. It works fine. Now i
> want to try ITV encryption algorithm for this on-wire data.
>
> https://github.com/mshary/itv
>
>  For this i need to keep track of remote endpoint. At this low level, i
> only have raw data received from or being transmitted to remote UA, without
> even the remote socket address, so i have no choice but to look at this raw
> data to determine the identity of remote endpoint. For non-WS transport, i
> can easily  look at topmost VIA and extract network address to use as
> "unique identification" of endpoint who sent the data or would receive the
> data. However, for WS transport this topmost VIA is useless static constant
> string. So VIA checking is pointless (all remote endpoints will or may have
> same top most VIA).
>
> So i was thinking if there is another way to do it? I thought of using
> GRUU, but it is not always present, especially in SIP replies.
>
>  Thank you.
>
>
>
>
> On Mon, Aug 25, 2014 at 3:24 PM, Vitaliy Aleksandrov <
> vitalik.v...@gmail.com> wrote:
>
>>  On 22.08.14 03:26, Muhammad Shahzad wrote:
>>
>>> Sorry for putting this question on both dev and user mailing lists, as
>>> it is a rather theoretical question and i hope some SIP guru on either mail
>>> list will answer.
>>>
>>> For non-WS endpoints which use TCP or UDP for SIP transport, each
>>> upstream request has top most VIA header pointing to the previous hop which
>>> forwarded the request to current hop while each downstream request has top
>>> most VIA header pointing to next hop to which it will be forwarded from
>>> current hop.
>>>
>>> But for WS endpoints, the top most VIA has dummy static value, so there
>>> is no way to identify who sent this request or to whom the reply is going
>>> to.
>>>
>>> Please note that i am not specifically interested in network address of
>>> remote endpoint (though VIA header is suppose to provide it), i only need
>>> to match requests and responses from / to a specific device using SIP v2.0
>>> standard.
>>>
>>> Any help is highly appreciated.
>>>
>>> Thank you.
>>>
>>>
>>  Can you provide an example of scenario you want to create ?
>> Do you want to understand how transaction and dialog matching works in
>> SIP ?
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-u

Re: [SR-Users] How to uniquely identify SIP WS / WSS endpoint

[Vitaliy Aleksandrov]

When kamailio processes a request script writer can check if there any 
Route header or valid  R-URI or R-URI alias parameter to determine the 
destination. You can check it manually maybe reusing kamailio sip parser.


As you've already said to find a destination where kamailio is going to 
send a reply you can parse via header or its "received" and "rport" 
parameters. Even when via doesn't have valid destination (ws/wss 
transport) it has correct "received" and "rport" parameters which 
kamailio adds during a request processing.


"Via" header in INVITE received from WSS client and forwarded to a 
destination looks like this:
"Via: SIP/2.0/WSS 
df7jal23ls0d.invalid;received=1.2.3.4;branch=z9hG4bKTp9lzCApgHsdbRUrFcZ4XTCI49EZbbDf;rport=37213"



Not really, the main context of this question is in reference to this 
thread,


https://www.mail-archive.com/sr-users@lists.sip-router.org/msg19962.html

A patched to allow network IO intercept in kamailio corex module was 
add to trunk as discussed in this thread,


https://www.mail-archive.com/sr-users@lists.sip-router.org/msg20183.html

Currently i am able to compress / decompress entire sip message coming 
from or going to remote endpoint in kamailio server. It works fine. 
Now i want to try ITV encryption algorithm for this on-wire data.


https://github.com/mshary/itv

For this i need to keep track of remote endpoint. At this low level, i 
only have raw data received from or being transmitted to remote UA, 
without even the remote socket address, so i have no choice but to 
look at this raw data to determine the identity of remote endpoint. 
For non-WS transport, i can easily  look at topmost VIA and extract 
network address to use as "unique identification" of endpoint who sent 
the data or would receive the data. However, for WS transport this 
topmost VIA is useless static constant string. So VIA checking is 
pointless (all remote endpoints will or may have same top most VIA).


So i was thinking if there is another way to do it? I thought of using 
GRUU, but it is not always present, especially in SIP replies.


Thank you.




On Mon, Aug 25, 2014 at 3:24 PM, Vitaliy Aleksandrov 
mailto:vitalik.v...@gmail.com>> wrote:


On 22.08.14 03:26, Muhammad Shahzad wrote:

Sorry for putting this question on both dev and user mailing
lists, as it is a rather theoretical question and i hope some
SIP guru on either mail list will answer.

For non-WS endpoints which use TCP or UDP for SIP transport,
each upstream request has top most VIA header pointing to the
previous hop which forwarded the request to current hop while
each downstream request has top most VIA header pointing to
next hop to which it will be forwarded from current hop.

But for WS endpoints, the top most VIA has dummy static value,
so there is no way to identify who sent this request or to
whom the reply is going to.

Please note that i am not specifically interested in network
address of remote endpoint (though VIA header is suppose to
provide it), i only need to match requests and responses from
/ to a specific device using SIP v2.0 standard.

Any help is highly appreciated.

Thank you.


Can you provide an example of scenario you want to create ?
Do you want to understand how transaction and dialog matching
works in SIP ?

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users@lists.sip-router.org 
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles

[Alex Hermann]

On Monday 25 August 2014, Daniel-Constantin Mierla wrote:
> Are these patches on top of latest version of dialog module (the ones
> with unique id per profile)?

They're against a1b6093aaee, which includes some commits mentioning a unique 
id for profiles. I don't know if they interfere during runtime, because i 
only compile-tested it before pushing.

-- 
Alex.

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to uniquely identify SIP WS / WSS endpoint

[Muhammad Shahzad]

Not really, the main context of this question is in reference to this
thread,

https://www.mail-archive.com/sr-users@lists.sip-router.org/msg19962.html

A patched to allow network IO intercept in kamailio corex module was add to
trunk as discussed in this thread,

https://www.mail-archive.com/sr-users@lists.sip-router.org/msg20183.html

Currently i am able to compress / decompress entire sip message coming from
or going to remote endpoint in kamailio server. It works fine. Now i want
to try ITV encryption algorithm for this on-wire data.

https://github.com/mshary/itv

For this i need to keep track of remote endpoint. At this low level, i only
have raw data received from or being transmitted to remote UA, without even
the remote socket address, so i have no choice but to look at this raw data
to determine the identity of remote endpoint. For non-WS transport, i can
easily  look at topmost VIA and extract network address to use as "unique
identification" of endpoint who sent the data or would receive the data.
However, for WS transport this topmost VIA is useless static constant
string. So VIA checking is pointless (all remote endpoints will or may have
same top most VIA).

So i was thinking if there is another way to do it? I thought of using
GRUU, but it is not always present, especially in SIP replies.

Thank you.




On Mon, Aug 25, 2014 at 3:24 PM, Vitaliy Aleksandrov  wrote:

> On 22.08.14 03:26, Muhammad Shahzad wrote:
>
>> Sorry for putting this question on both dev and user mailing lists, as it
>> is a rather theoretical question and i hope some SIP guru on either mail
>> list will answer.
>>
>> For non-WS endpoints which use TCP or UDP for SIP transport, each
>> upstream request has top most VIA header pointing to the previous hop which
>> forwarded the request to current hop while each downstream request has top
>> most VIA header pointing to next hop to which it will be forwarded from
>> current hop.
>>
>> But for WS endpoints, the top most VIA has dummy static value, so there
>> is no way to identify who sent this request or to whom the reply is going
>> to.
>>
>> Please note that i am not specifically interested in network address of
>> remote endpoint (though VIA header is suppose to provide it), i only need
>> to match requests and responses from / to a specific device using SIP v2.0
>> standard.
>>
>> Any help is highly appreciated.
>>
>> Thank you.
>>
>>
> Can you provide an example of scenario you want to create ?
> Do you want to understand how transaction and dialog matching works in SIP
> ?
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles

[Daniel-Constantin Mierla]

Are these patches on top of latest version of dialog module (the ones 
with unique id per profile)?


Daniel

On 25/08/14 11:11, Alex Hermann wrote:

On Friday 22 August 2014, Charles Chance wrote:

On 22 August 2014 16:46, Alex Hermann  wrote:

Last week, i just built profile synchronisation in the dialog module,
based on
dmq. It took quite a bit of debugging time because of the state dmq was
in.

Can you expand a little on "the state dmq was in"?

I was hoping to use it as-is, but i encountered issues which had to be
resolved before i could even use the module:

- As soon as i enabled the dmq module, i experienced segfaults.
- It had bad interaction with the maxfwd module
- Status updates between hosts were largely ignored.
- The configured server_address wasn't used to send messages.




It still has some rough edges, but i'll try to push a branch (shortly
after)
this weekend for review.

Looking forward to seeing it - may save me the time :)

I pushed my WIP to the branch alexh/dialog-sync-wip which also contains
dialog and dmq fixes and cleanups.

It's WIP, so it might still change. This branch is only compile-tested so
far, because i normally develop against 3.2. I just cherry-picked most of my
patches to master.

Known issues:
  - Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.

Still on the TODO list:
  - Delete 'disabled'  dmq hosts
  - Cope better with out-of-order sync messages
  - Sync initial state
  - Clean shutdown of DMQ, free all memory
  - More efficient protocol instead of JSON. Probably just write raw data in
the packet, so the receiving side can just use a pointer into the buf
instead of having to copy everything.



--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles

[Charles Chance]

Alex,

Thanks for expanding in such detail. I appreciate you taking the time to
fix the things that I missed. Sometimes I think it may have been easier to
start from scratch ;)

Best regards,

Charles
On 25 Aug 2014 10:11, "Alex Hermann"  wrote:

> On Friday 22 August 2014, Charles Chance wrote:
> > On 22 August 2014 16:46, Alex Hermann  wrote:
> > > Last week, i just built profile synchronisation in the dialog module,
> > > based on
> > > dmq. It took quite a bit of debugging time because of the state dmq was
> > > in.
> >
> > Can you expand a little on "the state dmq was in"?
>
> I was hoping to use it as-is, but i encountered issues which had to be
> resolved before i could even use the module:
>
> - As soon as i enabled the dmq module, i experienced segfaults.
> - It had bad interaction with the maxfwd module
> - Status updates between hosts were largely ignored.
> - The configured server_address wasn't used to send messages.
>
>
>
> > > It still has some rough edges, but i'll try to push a branch (shortly
> > > after)
> > > this weekend for review.
> >
> > Looking forward to seeing it - may save me the time :)
>
> I pushed my WIP to the branch alexh/dialog-sync-wip which also contains
> dialog and dmq fixes and cleanups.
>
> It's WIP, so it might still change. This branch is only compile-tested so
> far, because i normally develop against 3.2. I just cherry-picked most of
> my
> patches to master.
>
> Known issues:
>  - Sync get off under load, cause unknown yet, but probably because of out-
> of-order sync messages.
>
> Still on the TODO list:
>  - Delete 'disabled'  dmq hosts
>  - Cope better with out-of-order sync messages
>  - Sync initial state
>  - Clean shutdown of DMQ, free all memory
>  - More efficient protocol instead of JSON. Probably just write raw data in
> the packet, so the receiving side can just use a pointer into the buf
> instead of having to copy everything.
>
> --
> Alex
>
>
>
> --
> Alex Hermann
>

-- 
www.sipcentric.com

Follow us on twitter @sipcentric 

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, 
Birmingham Science Park, Birmingham B7 4BB.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] How to uniquely identify SIP WS / WSS endpoint

[Vitaliy Aleksandrov]

On 22.08.14 03:26, Muhammad Shahzad wrote:
Sorry for putting this question on both dev and user mailing lists, as 
it is a rather theoretical question and i hope some SIP guru on either 
mail list will answer.


For non-WS endpoints which use TCP or UDP for SIP transport, each 
upstream request has top most VIA header pointing to the previous hop 
which forwarded the request to current hop while each downstream 
request has top most VIA header pointing to next hop to which it will 
be forwarded from current hop.


But for WS endpoints, the top most VIA has dummy static value, so 
there is no way to identify who sent this request or to whom the reply 
is going to.


Please note that i am not specifically interested in network address 
of remote endpoint (though VIA header is suppose to provide it), i 
only need to match requests and responses from / to a specific device 
using SIP v2.0 standard.


Any help is highly appreciated.

Thank you.



Can you provide an example of scenario you want to create ?
Do you want to understand how transaction and dialog matching works in SIP ?

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles

[Alex Hermann]

On Friday 22 August 2014, Charles Chance wrote:
> On 22 August 2014 16:46, Alex Hermann  wrote:
> > Last week, i just built profile synchronisation in the dialog module,
> > based on
> > dmq. It took quite a bit of debugging time because of the state dmq was
> > in.
> 
> Can you expand a little on "the state dmq was in"?

I was hoping to use it as-is, but i encountered issues which had to be 
resolved before i could even use the module:

- As soon as i enabled the dmq module, i experienced segfaults.
- It had bad interaction with the maxfwd module
- Status updates between hosts were largely ignored.
- The configured server_address wasn't used to send messages.



> > It still has some rough edges, but i'll try to push a branch (shortly
> > after)
> > this weekend for review.
> 
> Looking forward to seeing it - may save me the time :)

I pushed my WIP to the branch alexh/dialog-sync-wip which also contains 
dialog and dmq fixes and cleanups.

It's WIP, so it might still change. This branch is only compile-tested so 
far, because i normally develop against 3.2. I just cherry-picked most of my 
patches to master.

Known issues:
 - Sync get off under load, cause unknown yet, but probably because of out-
of-order sync messages.

Still on the TODO list:
 - Delete 'disabled'  dmq hosts
 - Cope better with out-of-order sync messages
 - Sync initial state
 - Clean shutdown of DMQ, free all memory
 - More efficient protocol instead of JSON. Probably just write raw data in 
the packet, so the receiving side can just use a pointer into the buf 
instead of having to copy everything.

-- 
Alex



-- 
Alex Hermann

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users