Re: [SR-Users] Problem with IPv4-IPv6 media bridging using RTPengine

[Richard Fuchs]

On 19/07/17 08:31 AM, Ismir Saljic wrote:

Hello,

I've issue with bridging media between IPv4 and IPv6 clients. 
IPv4-IPv4 and IPv6-IPv6 calls are working without issues.
I'm using kamailio 4.4.2 and configuration according to: 
http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6 



SIP signalling is working without issues,but media addresses in SDP 
are not rewritten correctly.


The server is on amazon AWS and both kamailio and RTPengine are on the 
same server.

RTPengine is running using these options:

/usr/sbin/rtpengine   --interface=privateIPv4!publicIPv4
 --interface=GlobalIPv6
   --listen-udp=127.0.0.1:2 
   --tos=184
--pidfile=/var/run/rtpengine.pid
   --log-level=6
   --log-facility=daemon


I would suggest to use Kamailio's rtpengine module instead of rtpproxy, 
together with --listen-ng instead of --listen-udp.


The UDP protocol of the rtpproxy module should work with rtpengine, but 
not many people are using it, so it's always possible that some bugs 
creep in. I'll look into it anyway, but in the long run, it's much 
preferable to switch to the rtpengine module.


Cheers
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] xavp questions (variables in root/branch)

[Vasiliy Ganchev]

Hi, community!

I have a question regarding xavp usage.

according to docs, xavp has format:
$xavp(root=>branch)="value";

I want to use "root" and "branch" - variables. (as it is implemented with
AVPs - the id there, can be variable)
e.g.:

...
$var(root_key) = "root_1";
$var(branch_key1) = "key_value1";
...
$xavp($var(root_key)[0]=>$var(branch_key1)) = "some_value";
... 

Playing around with the script - I found that it is currently impossible
(tested with 4.2.5 and 5.2.0 versions).
Kamailio interprets variables in "root" and "branch" as static strings.


Walking through the mailing list history, I have an impression that xavp are
originally designed to operate only with constant keys.

The question is: is it planned to add functionality with variables as "root"
and "branch" components?

Thanks in advance for the answers!

Best regards



--
View this message in context: 
http://sip-router.1086192.n5.nabble.com/xavp-questions-variables-in-root-branch-tp160357.html
Sent from the Users mailing list archive at Nabble.com.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Problem with IPv4-IPv6 media bridging using RTPengine

[Ismir Saljic]

Hello,

I've issue with bridging media between IPv4 and IPv6 clients. IPv4-IPv4 and
IPv6-IPv6 calls are working without issues.
I'm using kamailio 4.4.2 and configuration according to:
http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6

SIP signalling is working without issues,but media addresses in SDP are not
rewritten correctly.

The server is on amazon AWS and both kamailio and RTPengine are on the same
server.
RTPengine is running using these options:

/usr/sbin/rtpengine   --interface=privateIPv4!publicIPv4
 --interface=GlobalIPv6
 --listen-udp=127.0.0.1:2
 --tos=184
 --pidfile=/var/run/rtpengine.pid
 --log-level=6
 --log-facility=daemon


In case of IPv4-IPv6 call, INVITE message contains correct IPv4 address but
200 OK response to the caller still contains IPv6 address of the callee in
SDP body instead of IPv4 address of the server/RTPengine.
This is the log during generation of the 200 OK response. Seems that
RTPengine failed to parse IPv4 address from SDP body.

Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:618]: parse_msg(): SIP Reply  (status):
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:620]: parse_msg():  version: 
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:622]: parse_msg():  status:  <200>
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:624]: parse_msg():  reason:  
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:1254]: parse_via_param(): Found param type 232,
 = ; state=6
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:1254]: parse_via_param(): Found param type 234,
 = ; state=6
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:1254]: parse_via_param(): Found param type 236,  =
<8>; state=16
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:2642]: parse_via(): end of header reached, state=5
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found,
flags=2
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the
first via
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[receive.c:178]: receive_msg(): After parse_msg...
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: tm
[t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=143 global
id=142 T start=0x
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:1254]: parse_via_param(): Found param type 234,
 = <178.165.130.177>; state=6
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:1254]: parse_via_param(): Found param type 232,
 = ; state=6
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:1254]: parse_via_param(): Found param type 235, 
= <2066>; state=16
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_via.c:2642]: parse_via(): end of header reached, state=5
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found,
flags=62
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:509]: parse_headers(): parse_headers: this is the
second via
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param:
tag=2996330c
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached,
state=29
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: 
[59]; uri=[sip:u...@domain.com]
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body ["user"<
sip:u...@domain.com>]
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: 
[parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq :
<21> 
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: tm
[t_lookup.c:888]: t_reply_matching(): DEBUG: t_reply_matching: hash 61349
label 0 branch 0
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: tm
[t_lookup.c:943]: t_reply_matching(): DEBUG: t_reply_matching: reply
matched (T=0x7f7f95c19a10)!
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: tm [t_hooks.c:266]:
run_trans_callbacks_internal(): DBG: trans=0x7f7f95c19a10, callback type 2,
id 0 entered
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: acc
[acc_logic.c:644]: tmcb_func(): acc callback called for t(0x7f7f95c19a10)
event type 2, reply code 200
Jul 19 08:02:42  /usr/local/sbin/kamailio[1691]: DEBUG: tm

Re: [SR-Users] dns failover and branches

[Joel Serrano]

Thanks for the info!


On Wed, Jul 19, 2017 at 8:15 AM, Juha Heinanen  wrote:

> Joel Serrano writes:
>
> > Just curious, in what version of Kamailio would this patch be
> implemented?
> > is the backport to previous versions automatic or do we have to manually
> > apply and build?
>
> I think backports are usually done on per need basis.  So if you need
> this patch in some version earlier that 5.0, you can backport it.
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Juha Heinanen]

Joel Serrano writes:

> Just curious, in what version of Kamailio would this patch be implemented?
> is the backport to previous versions automatic or do we have to manually
> apply and build?

I think backports are usually done on per need basis.  So if you need
this patch in some version earlier that 5.0, you can backport it.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Joel Serrano]

Just curious, in what version of Kamailio would this patch be implemented?
is the backport to previous versions automatic or do we have to manually
apply and build?

Cheers,
Joel.

On Wed, Jul 19, 2017 at 3:26 AM, Juha Heinanen  wrote:

> Daniel,
>
> After your patch, branch flags are now preserved to the second SRV
> destination.   Thanks,
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Juha Heinanen]

Daniel,

After your patch, branch flags are now preserved to the second SRV
destination.   Thanks,

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Juha Heinanen]

Daniel-Constantin Mierla writes:

> Sounded rather simple, so I did a quick search in the code and just
> pushed a patch for it -- very small, but hopefully it fixes this. If all
> tests are fine for you, then you can backport as needed to stable branches.

Thanks, will test and backport.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Daniel-Constantin Mierla]

On 19.07.17 11:00, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> OK, so it is creating a new branch structure. That could explain why the
>> branch flags from previous INVITE are not there. If it is only the
>> branch flags missing (and the headers changes are already propagated), I
>> expect to be an easy patch. I will look into it very soon if nobody else
>> does it meanwhile.
> I did more checking and looks like only branch flags are gone.  In
> addition to adding headers and setting branch flags, branch route adds
> record-route params using add_rr_param calls and also those params are
> preserved in the second INVITE.
>
Sounded rather simple, so I did a quick search in the code and just
pushed a patch for it -- very small, but hopefully it fixes this. If all
tests are fine for you, then you can backport as needed to stable branches.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Juha Heinanen]

Daniel-Constantin Mierla writes:

> OK, so it is creating a new branch structure. That could explain why the
> branch flags from previous INVITE are not there. If it is only the
> branch flags missing (and the headers changes are already propagated), I
> expect to be an easy patch. I will look into it very soon if nobody else
> does it meanwhile.

I did more checking and looks like only branch flags are gone.  In
addition to adding headers and setting branch flags, branch route adds
record-route params using add_rr_param calls and also those params are
preserved in the second INVITE.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Daniel-Constantin Mierla]

On 19.07.17 10:44, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Is the branch parameter in the top Via of the second INVITE sent out
>> different than for the first INVITE (last digit incremented by 1 or
>> so)?
> Thanks for your reply.  Yes it is:
>
> In the first INVITE:
>
> Via: SIP/2.0/UDP 
> x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.0;i=1.
>
> In the second INVITE:
>
> Via: SIP/2.0/UDP 
> x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.1;i=1.
>
>
OK, so it is creating a new branch structure. That could explain why the
branch flags from previous INVITE are not there. If it is only the
branch flags missing (and the headers changes are already propagated), I
expect to be an easy patch. I will look into it very soon if nobody else
does it meanwhile.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Juha Heinanen]

Daniel-Constantin Mierla writes:

> Is the branch parameter in the top Via of the second INVITE sent out
> different than for the first INVITE (last digit incremented by 1 or
> so)?

Thanks for your reply.  Yes it is:

In the first INVITE:

Via: SIP/2.0/UDP 
x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.0;i=1.

In the second INVITE:

Via: SIP/2.0/UDP 
x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.1;i=1.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Daniel-Constantin Mierla]

On 19.07.17 10:23, Juha Heinanen wrote:
> I did more some more tests.
>
> The branch route was properly executed before INVITE to the first SRV
> destination was sent.  The branch route set some headers, branch flags,
> etc.  After the first SRV destination failed, INVITE was sent to the
> second SRV destination and the branch route was not re-executed.  In the
> second INVITE, headers that were added in branch route were correctly
> preserved. However, branch flags that were set in the branch route were
> not preserved.  As result, processing of positive reply from the second
> srv destination failed.
>
> This looks like a bug to me.  Also branch flags that were set in the
> branch route before the first INVITE was sent out should have been
> preserved for processing of the second INVITE.
>
>
Is the branch parameter in the top Via of the second INVITE sent out
different than for the first INVITE (last digit incremented by 1 or so)?

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] dns failover and branches

[Juha Heinanen]

I did more some more tests.

The branch route was properly executed before INVITE to the first SRV
destination was sent.  The branch route set some headers, branch flags,
etc.  After the first SRV destination failed, INVITE was sent to the
second SRV destination and the branch route was not re-executed.  In the
second INVITE, headers that were added in branch route were correctly
preserved. However, branch flags that were set in the branch route were
not preserved.  As result, processing of positive reply from the second
srv destination failed.

This looks like a bug to me.  Also branch flags that were set in the
branch route before the first INVITE was sent out should have been
preserved for processing of the second INVITE.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dns failover and branches

[Daniel-Constantin Mierla]

On 19.07.17 09:09, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> If Request-URI hostpart is a domain name with more than one SRV record,
>> it appears that each SRV destination creates its own Kamailio branch.
>> If branch route is set before t_relay(), it is executed only on the
>> first SRV destination.  If the first SRV destination fails, Kamailio
>> tries automatically the second one, but any branch flags set in the
>> branch route are lost.
> Is the above the intended behavior in general?  It seems a bit weird
> that K does automatic serial forking to SRV destinations without
> executing the branch route set before t_relay() for each of them.
>
AFAIK, this was the implementation from the first time of DNS SRV serial
forking.

Btw, is the branch index changed, or is reusing the same branch (is the
branch param in Via chaging for each leg sent out)?

Anyhow, changing the current behaviour would require c coding in tm.
Probably not that much.

Due to poor implementation of DNS SRV in the past and problems with
propagation, I tried to avoid it as much as possible. But I have several
deployments where it works fine, so all should be ok with it, however I
didn't need any customization for related branches.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] dns failover and branches

[Juha Heinanen]

Juha Heinanen writes:

> If Request-URI hostpart is a domain name with more than one SRV record,
> it appears that each SRV destination creates its own Kamailio branch.
> If branch route is set before t_relay(), it is executed only on the
> first SRV destination.  If the first SRV destination fails, Kamailio
> tries automatically the second one, but any branch flags set in the
> branch route are lost.

Is the above the intended behavior in general?  It seems a bit weird
that K does automatic serial forking to SRV destinations without
executing the branch route set before t_relay() for each of them.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users