Re: [OpenSIPS-Users] t_relay

[johan]

yeah you are right.

I changed my script to go to sems.  Caller is tls, sems is udp. Hence I 
need to use udp socket.


The problem was that I forgot to call rewriteuri. Below is the 
solution.  Maybe it helps for somebody in the future.



    rewriteuri("5556@x.y.z.t:5060");
    subst_uri('/transport=tls/transport=udp/i');
    subst_uri('/transport=TLS/transport=udp/i');
    t_relay(,"udp:x.y.z.t:5060");


On 8/09/2020 19:23, Bogdan-Andrei Iancu wrote:

Hi Johan,

The socket used for receiving the REGISTER is stored in the OpenSIPS 
registration. And used/forced when doing the lookup(). So, if the 
REGISTER was received via TLS, the TLS interface should be forced 
after the lookup.


So how comes that opensips tries TLS (TLS Registration??) while the 
user is on UDP ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2020 online
  https://www.opensips.org/events/Summit-2020Distributed/

On 9/7/20 3:45 PM, johan wrote:

Hi,

when a user is not reachable, I want to reroute my call to sems.

the user is on tls, but sems is on udp.

as I use rtpengine after doing lookup(location), I need to re relay 
the original message on the tls connection. However this fails.


how can I do t_relay to tls socket ?

Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
callid=onsLR0MAH9Bae6f8XJTgug..: Branch_route[per_branch_ops]: new 
branch at sip:5556@x.y.z.t:5061;transport=TLS
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:tls_conn_init: no TLS client domain found
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:core:tcp_conn_new: failed to do proto 3 specific init for conn 
0x7fa91e354ff0
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:tls_sync_connect: tcp_conn_create failed, closing the 
socket
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:proto_tls_send: connect failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:msg_send: send() to x.y.z.t:5061 for proto tls/3 failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:t_forward_nonack: sending request failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:w_t_relay: t_forward_nonack failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
callid=onsLR0MAH9Bae6f8XJTgug..: failure_route[missed_call]: t_relay 
doesn't work.
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15774]: 
ERROR:proto_tls:tls_accept: New TLS connection from x.y.z.t :53369 
failed to accept


Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15774]: 
ERROR:proto_tls:tls_read_req: failed to do pre-tls reading


if this is not possible, then how do I need to re relay the original 
message ?



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay

[Bogdan-Andrei Iancu]

Hi Johan,

The socket used for receiving the REGISTER is stored in the OpenSIPS 
registration. And used/forced when doing the lookup(). So, if the 
REGISTER was received via TLS, the TLS interface should be forced after 
the lookup.


So how comes that opensips tries TLS (TLS Registration??) while the user 
is on UDP ?


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2020 online
  https://www.opensips.org/events/Summit-2020Distributed/

On 9/7/20 3:45 PM, johan wrote:

Hi,

when a user is not reachable, I want to reroute my call to sems.

the user is on tls, but sems is on udp.

as I use rtpengine after doing lookup(location), I need to re relay 
the original message on the tls connection. However this fails.


how can I do t_relay to tls socket ?

Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
callid=onsLR0MAH9Bae6f8XJTgug..: Branch_route[per_branch_ops]: new 
branch at sip:5556@46.105.105.119:5061;transport=TLS
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:tls_conn_init: no TLS client domain found
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:core:tcp_conn_new: failed to do proto 3 specific init for conn 
0x7fa91e354ff0
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:tls_sync_connect: tcp_conn_create failed, closing the 
socket
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:proto_tls_send: connect failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:msg_send: send() to 46.105.105.119:5061 for proto tls/3 failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:t_forward_nonack: sending request failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:w_t_relay: t_forward_nonack failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
callid=onsLR0MAH9Bae6f8XJTgug..: failure_route[missed_call]: t_relay 
doesn't work.
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15774]: 
ERROR:proto_tls:tls_accept: New TLS connection from 
46.105.105.119:53369 failed to accept


Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15774]: 
ERROR:proto_tls:tls_read_req: failed to do pre-tls reading


if this is not possible, then how do I need to re relay the original 
message ?



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay

[johan]

Hi,

when a user is not reachable, I want to reroute my call to sems.

the user is on tls, but sems is on udp.

as I use rtpengine after doing lookup(location), I need to re relay the 
original message on the tls connection. However this fails.


how can I do t_relay to tls socket ?

Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
callid=onsLR0MAH9Bae6f8XJTgug..: Branch_route[per_branch_ops]: new 
branch at sip:5556@46.105.105.119:5061;transport=TLS
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:tls_conn_init: no TLS client domain found
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:core:tcp_conn_new: failed to do proto 3 specific init for conn 
0x7fa91e354ff0
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:tls_sync_connect: tcp_conn_create failed, closing the socket
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:proto_tls:proto_tls_send: connect failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:msg_send: send() to 46.105.105.119:5061 for proto tls/3 failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:t_forward_nonack: sending request failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
ERROR:tm:w_t_relay: t_forward_nonack failed
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15772]: 
callid=onsLR0MAH9Bae6f8XJTgug..: failure_route[missed_call]: t_relay 
doesn't work.
Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15774]: 
ERROR:proto_tls:tls_accept: New TLS connection from 46.105.105.119:53369 
failed to accept


Sep  7 12:40:09 ns36 /data/opensips/sbin/opensips[15774]: 
ERROR:proto_tls:tls_read_req: failed to do pre-tls reading


if this is not possible, then how do I need to re relay the original 
message ?



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay and forward accepts only literals

[Daniel Moreira Yokoyama]

Thanks Liviu.

To be precise it only worked when I changed both $ru and $du. I'm not sure
if this is a good use.

Also, because of that, now, when it comes from the other endpoint I have to
force it to do the opposite (force to use UDP), what wasn't necessary
before.

Does it make any sense to you? Am I doing something that should not be
necessary to achieve this behavior?

I still have to make the stress test to see how much impact it does
comparing to the regular scenario. But I finally could make it work thanks
to you. Now I'll be able to give my customer some numbers.

Thank you very much.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko

TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br


2016-03-23 13:03 GMT-03:00 Liviu Chircu :

> That's because I just copy-pasted your example and adapted it without
> thinking. It should be:
>
> force_send_socket(sctp:10.12.8.108:5060)
> $ru = "sip:" + $od + ":" + $op + ";transport=sctp";
> forward();
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 23.03.2016 15:36, Daniel Moreira Yokoyama wrote:
>
> Hi Liviu.
>
> I did the change and Opensips started up ok. But when I run my tests, no
> message get to the UAS.
>
> When I check the dump there's a lot of Destination Unreachable error for
> messages in UDP. It didn't change the transport protocol.
>
> Thanks anyway.
>
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.
> @dmyoko
> http://twitter.com/dmyoko
>
> TrafficTalks
> Um podcast sobre cinema feito a partir de conversas de trânsito.
> http://traffictalks.com.br
>
>
> 2016-03-23 6:57 GMT-03:00 Liviu Chircu :
>
>> Hi Daniel,
>>
>> It's not a limitation, but rather a performance optimization which kills
>> some of the user experience :)
>>
>> You can still do stateless forwarding to various destinations by setting
>> the Request-URI ahead:
>>
>> force_send_socket(sctp:10.12.8.108:5060)
>> $ru = "sctp:" + $od + ":" + $op;
>> forward();
>>
>> Liviu Chircu
>> OpenSIPS Developerhttp://www.opensips-solutions.com
>>
>> On 22.03.2016 22:23, Daniel Moreira Yokoyama wrote:
>>
>> Hi everyone.
>>
>> I'm still trying to undestand why I can't use t_relay(dest) or
>> forward(dest) passing a variable instead of a literal.
>>
>> In my scenario, all I have to do is to receive a UDP message from a
>> client and relay it on SCTP to the remote endpoint.
>>
>> The way I'm trying to achieve this is by:
>>
>>  force_send_socket(sctp:10.12.8.108:5060);
>>  forward("sctp:$od:$op");
>>
>>
>> But Opensips doesn't even start up, complaining that the domain and the
>> port are invalid.
>>
>> I only works in my tests when I put the literal value  (e.g: "sctp:
>> 10.0.8.104:5060").
>>
>> I don't get it. Why would it restrict something like this?
>>
>> Anyone can give me any guidance?
>>
>> Thanks a lot.
>>
>>
>> Atenciosamente,
>>
>> Daniel Moreira Yokoyama.
>> @dmyoko
>> http://twitter.com/dmyoko
>>
>> TrafficTalks
>> Um podcast sobre cinema feito a partir de conversas de trânsito.
>> http://traffictalks.com.br
>>
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay and forward accepts only literals

[Liviu Chircu]

That's because I just copy-pasted your example and adapted it without 
thinking. It should be:


force_send_socket(sctp:10.12.8.108:5060 )
$ru = "sip:" + $od + ":" + $op + ";transport=sctp";
forward();

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 23.03.2016 15:36, Daniel Moreira Yokoyama wrote:

Hi Liviu.

I did the change and Opensips started up ok. But when I run my tests, 
no message get to the UAS.


When I check the dump there's a lot of Destination Unreachable error 
for messages in UDP. It didn't change the transport protocol.


Thanks anyway.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko
TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br


2016-03-23 6:57 GMT-03:00 Liviu Chircu >:


Hi Daniel,

It's not a limitation, but rather a performance optimization which
kills some of the user experience :)

You can still do stateless forwarding to various destinations by
setting the Request-URI ahead:

force_send_socket(sctp:10.12.8.108:5060 )
$ru = "sctp:" + $od + ":" + $op;
forward();

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 22.03.2016 22:23, Daniel Moreira Yokoyama wrote:

Hi everyone.

I'm still trying to undestand why I can't use t_relay(dest) or
forward(dest) passing a variable instead of a literal.

In my scenario, all I have to do is to receive a UDP message from
a client and relay it on SCTP to the remote endpoint.

The way I'm trying to achieve this is by:

 force_send_socket(sctp:10.12.8.108:5060 );
 forward("sctp:$od:$op");


But Opensips doesn't even start up, complaining that the domain
and the port are invalid.

I only works in my tests when I put the literal value  (e.g:
"sctp:10.0.8.104:5060 ").

I don't get it. Why would it restrict something like this?

Anyone can give me any guidance?

Thanks a lot.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko
TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br



___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay and forward accepts only literals

[Daniel Moreira Yokoyama]

Hi Liviu.

I did the change and Opensips started up ok. But when I run my tests, no
message get to the UAS.

When I check the dump there's a lot of Destination Unreachable error for
messages in UDP. It didn't change the transport protocol.

Thanks anyway.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko

TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br


2016-03-23 6:57 GMT-03:00 Liviu Chircu :

> Hi Daniel,
>
> It's not a limitation, but rather a performance optimization which kills
> some of the user experience :)
>
> You can still do stateless forwarding to various destinations by setting
> the Request-URI ahead:
>
> force_send_socket(sctp:10.12.8.108:5060)
> $ru = "sctp:" + $od + ":" + $op;
> forward();
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 22.03.2016 22:23, Daniel Moreira Yokoyama wrote:
>
> Hi everyone.
>
> I'm still trying to undestand why I can't use t_relay(dest) or
> forward(dest) passing a variable instead of a literal.
>
> In my scenario, all I have to do is to receive a UDP message from a client
> and relay it on SCTP to the remote endpoint.
>
> The way I'm trying to achieve this is by:
>
>  force_send_socket(sctp:10.12.8.108:5060);
>  forward("sctp:$od:$op");
>
>
> But Opensips doesn't even start up, complaining that the domain and the
> port are invalid.
>
> I only works in my tests when I put the literal value  (e.g: "sctp:
> 10.0.8.104:5060").
>
> I don't get it. Why would it restrict something like this?
>
> Anyone can give me any guidance?
>
> Thanks a lot.
>
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.
> @dmyoko
> http://twitter.com/dmyoko
>
> TrafficTalks
> Um podcast sobre cinema feito a partir de conversas de trânsito.
> http://traffictalks.com.br
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay and forward accepts only literals

[Daniel Moreira Yokoyama]

Hi Dimitry.

I tried this as well. I receive a bad config file.

Thanks anyway.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko

TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br


2016-03-23 4:21 GMT-03:00 Nagorny, Dimitry <dimitry.nago...@robot5.de>:

> Daniel,
>
>
>
> I had a similar problem and I was able to solve it by doing string
> concatenation:
>
>
>
> forward(„sctp:“+$od+“:“+$op);
>
>
>
>
>
> Best Regards
>
> *Dimitry Nagorny*
>
> Trainee
>
>
>
> *Von:* users-boun...@lists.opensips.org [mailto:
> users-boun...@lists.opensips.org] *Im Auftrag von *Daniel Moreira Yokoyama
> *Gesendet:* Dienstag, 22. März 2016 21:24
> *An:* OpenSIPS users mailling list <users@lists.opensips.org>
> *Betreff:* [OpenSIPS-Users] t_relay and forward accepts only literals
>
>
>
> Hi everyone.
>
>
>
> I'm still trying to undestand why I can't use t_relay(dest) or
> forward(dest) passing a variable instead of a literal.
>
>
>
> In my scenario, all I have to do is to receive a UDP message from a client
> and relay it on SCTP to the remote endpoint.
>
>
>
> The way I'm trying to achieve this is by:
>
>
>
>  force_send_socket(sctp:10.12.8.108:5060);
>
>  forward("sctp:$od:$op");
>
>
>
>
>
> But Opensips doesn't even start up, complaining that the domain and the
> port are invalid.
>
>
>
> I only works in my tests when I put the literal value  (e.g: "sctp:
> 10.0.8.104:5060").
>
>
>
> I don't get it. Why would it restrict something like this?
>
>
>
> Anyone can give me any guidance?
>
>
>
> Thanks a lot.
>
>
>
>
> Atenciosamente,
>
> Daniel Moreira Yokoyama.
>
> @dmyoko
>
> http://twitter.com/dmyoko
>
>
>
> TrafficTalks
> Um podcast sobre cinema feito a partir de conversas de trânsito.
>
> http://traffictalks.com.br
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay and forward accepts only literals

[Liviu Chircu]

Hi Daniel,

It's not a limitation, but rather a performance optimization which kills 
some of the user experience :)


You can still do stateless forwarding to various destinations by setting 
the Request-URI ahead:


force_send_socket(sctp:10.12.8.108:5060)
$ru = "sctp:" + $od + ":" + $op;
forward();

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 22.03.2016 22:23, Daniel Moreira Yokoyama wrote:

Hi everyone.

I'm still trying to undestand why I can't use t_relay(dest) or 
forward(dest) passing a variable instead of a literal.


In my scenario, all I have to do is to receive a UDP message from a 
client and relay it on SCTP to the remote endpoint.


The way I'm trying to achieve this is by:

 force_send_socket(sctp:10.12.8.108:5060 );
 forward("sctp:$od:$op");


But Opensips doesn't even start up, complaining that the domain and 
the port are invalid.


I only works in my tests when I put the literal value  (e.g: 
"sctp:10.0.8.104:5060 ").


I don't get it. Why would it restrict something like this?

Anyone can give me any guidance?

Thanks a lot.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko
TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay and forward accepts only literals

[Nagorny, Dimitry]

Daniel,

I had a similar problem and I was able to solve it by doing string 
concatenation:

forward(„sctp:“+$od+“:“+$op);


Best Regards
Dimitry Nagorny
Trainee

Von: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] 
Im Auftrag von Daniel Moreira Yokoyama
Gesendet: Dienstag, 22. März 2016 21:24
An: OpenSIPS users mailling list <users@lists.opensips.org>
Betreff: [OpenSIPS-Users] t_relay and forward accepts only literals

Hi everyone.

I'm still trying to undestand why I can't use t_relay(dest) or forward(dest) 
passing a variable instead of a literal.

In my scenario, all I have to do is to receive a UDP message from a client and 
relay it on SCTP to the remote endpoint.

The way I'm trying to achieve this is by:

 force_send_socket(sctp:10.12.8.108:5060<http://10.12.8.108:5060>);
 forward("sctp:$od:$op");


But Opensips doesn't even start up, complaining that the domain and the port 
are invalid.

I only works in my tests when I put the literal value  (e.g: 
"sctp:10.0.8.104:5060<http://10.0.8.104:5060>").

I don't get it. Why would it restrict something like this?

Anyone can give me any guidance?

Thanks a lot.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko

TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay and forward accepts only literals

[Daniel Moreira Yokoyama]

Hi everyone.

I'm still trying to undestand why I can't use t_relay(dest) or
forward(dest) passing a variable instead of a literal.

In my scenario, all I have to do is to receive a UDP message from a client
and relay it on SCTP to the remote endpoint.

The way I'm trying to achieve this is by:

 force_send_socket(sctp:10.12.8.108:5060);
 forward("sctp:$od:$op");


But Opensips doesn't even start up, complaining that the domain and the
port are invalid.

I only works in my tests when I put the literal value  (e.g: "sctp:
10.0.8.104:5060").

I don't get it. Why would it restrict something like this?

Anyone can give me any guidance?

Thanks a lot.


Atenciosamente,

Daniel Moreira Yokoyama.
@dmyoko
http://twitter.com/dmyoko

TrafficTalks
Um podcast sobre cinema feito a partir de conversas de trânsito.
http://traffictalks.com.br
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] T_Relay Re-Invite

[Dave Lechasseur]

Hi everyone,

I have a problem with t_relay.

When the session is established (last 200 OK) the phone receive a in-dialog 
invite from the PBX directly and since there every packet don’t go thought 
OpenSIPS but goes directly to the PBX meaning that I have no way to do anything 
on the active channel and I don’t receive the BYE message on OpenSIPS, it go 
directly between the phone and the PBX.

Is there a way to not have this ?

Thank you for your help !

Dave L.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] T_Relay Re-Invite

[Dave Lechasseur]

Hi Eric,

Thank you for the quick answer.
With record_route it go thought the proxy but every in-session messages aren’t 
sent to the PBX or to the phone from the PBX.

Just to make sure I’ve tried adding : xlog("DEBUG : METHOD $rm”);
right after : route {

and I don’t pick any log from it.

Thank you,
Dave L.


From: 
<users-boun...@lists.opensips.org<mailto:users-boun...@lists.opensips.org>> on 
behalf of Eric Tamme <e...@uphreak.com<mailto:e...@uphreak.com>>
Reply-To: OpenSIPS users mailling list 
<users@lists.opensips.org<mailto:users@lists.opensips.org>>
Date: Wednesday, January 13, 2016 at 3:44 PM
To: OpenSIPS users mailling list 
<users@lists.opensips.org<mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] T_Relay Re-Invite

You need to record route the initial request so that your proxy stays in the 
signalling path.  This doesnt have anything to do with the tm module, but 
rather building up the routeset and loose routing.

-Eric

On 01/13/2016 01:42 PM, Dave Lechasseur wrote:
Hi everyone,

I have a problem with t_relay.

When the session is established (last 200 OK) the phone receive a in-dialog 
invite from the PBX directly and since there every packet don’t go thought 
OpenSIPS but goes directly to the PBX meaning that I have no way to do anything 
on the active channel and I don’t receive the BYE message on OpenSIPS, it go 
directly between the phone and the PBX.

Is there a way to not have this ?

Thank you for your help !

Dave L.



___
Users mailing list
Users@lists.opensips.org<mailto:Users@lists.opensips.org>http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay

[Bogdan-Andrei Iancu]

Gary,

Maybe take a look at the 0x02 flag for t_relay() :
http://www.opensips.org/html/docs/modules/1.12.x/tm.html#id294571

by default, t_relay() is internally sending a negative reply if not able 
to send the request out (like DNS failure, bad IP, network error, etc).


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 16.07.2014 10:43, Liviu Chircu wrote:

Hello,

t_relay() will only fail because of internal reasons (e.g. out of 
mem, max number of branches exceeded, transaction has 6XX status...).


It looks like you need to use a *failure_route* [1] for your 
transaction, and perform your error handling when it eventually 
expires, because no replies are being sent back. You can control the 
transaction timeout with the timeout variables from the TM module [2].


[1]: http://www.opensips.org/Documentation/Script-Routes-1-12#toc3
[2]: http://www.opensips.org/html/docs/modules/1.12.x/tm.html#id295701

Best regards,
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 07/15/2014 10:20 PM, Gary Nyquist wrote:

Hi,
Looking for some insight into the t_relay().
I am using the t_relay() to route INVITE to the Callee device (sip 
client running on a mobile device).
I was expecting the t_relay() to fail (returning a -ve number), when 
the sip client is not running on the mobile device.

But I find that t_relay() is not failing in this scenario.
Is this the normal behavior of t_relay()?
Thanks
-Gary


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay

[Gary Nyquist]

Thanks Bogdan  Liviu,



I have implemented the failure_route technique suggested by Liviu.
It is working fine.



Will try with t_relay(0x2) and let this forum know how it works.
I think it should fail and return -6 (- generic send failed), because the transport of the RURI (Callee Device) is TCP.
But not sure if tcp_async=1 affects it... Will try with tcp_async=0 also.



Need little more info on following timeout parameters:
T_fr_timeout
T_fr_inv_timeout

Is there a way to determine (inside the failure_route) which timeout occurred?



Thanks
-Gary






Sent:Wednesday, July 16, 2014 at 8:37 AM
From:Bogdan-Andrei Iancu bog...@opensips.org
To:OpenSIPS users mailling list users@lists.opensips.org, Gary Nyquist g...@gmx.us
Subject:Re: [OpenSIPS-Users] t_relay



Gary,

Maybe take a look at the 0x02 flag for t_relay() :
 http://www.opensips.org/html/docs/modules/1.12.x/tm.html#id294571

by default, t_relay() is internally sending a negative reply if not able to send the request out (like DNS failure, bad IP, network error, etc).

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 16.07.2014 10:43, Liviu Chircu wrote:


Hello,

t_relay() will only fail because of internal reasons (e.g. out of mem, max number of branches exceeded, transaction has 6XX status...).

It looks like you need to use a failure_route [1] for your transaction, and perform your error handling when it eventually expires, because no replies are being sent back. You can control the transaction timeout with the timeout variables from the TM module [2].

[1]: http://www.opensips.org/Documentation/Script-Routes-1-12#toc3
[2]: http://www.opensips.org/html/docs/modules/1.12.x/tm.html#id295701

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 07/15/2014 10:20 PM, Gary Nyquist wrote:






Hi,



Looking for some insight into the t_relay().

I am using the t_relay() to route INVITE to the Callee device (sip client running on a mobile device).


I was expecting thet_relay() to fail (returning a -ve number), when the sip client is not running on the mobile device.

But I find thatt_relay() is not failing in this scenario.

Is this the normal behavior oft_relay()?




Thanks
-Gary









___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users







___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users







___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay

[Gary Nyquist]

Hi,



Looking for some insight into the t_relay().

I am using the t_relay() to route INVITE to the Callee device (sip client running on a mobile device).


I was expecting thet_relay() to fail (returning a -ve number), when the sip client is not running on the mobile device.

But I find thatt_relay() is not failing in this scenario.

Is this the normal behavior oft_relay()?




Thanks
-Gary




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay behavior with 477 send failed

[Amit Sharma]

Bogdan,
I set the flag with t_relay and it resolved the issue. I am able
to handle failure from t_relay now.

Thanks,
Amit

On Mon, Mar 21, 2011 at 10:33 PM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
 Hi Amit,

 have you set the 0x02 flag for t_relay ? See:
      http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id293378

 This flag will prevent the t_relay() function do internally deal with errors
 (by sending back a negative reply).

 Regards,
 Bogdan

 Amit Sharma wrote:

 I tried the fix from the 1.6 branch. The issue I still face is that now
 t_relay returns with a value of 1 even when the relaying has failed.

 How do you figure out if t_relay has failed (!t_relay()) does not work in
 this case? Does a return value 1 also signify an error?
  -Amit

 On Tue, Mar 15, 2011 at 3:51 PM, Bogdan-Andrei Iancu bog...@opensips.org
 mailto:bog...@opensips.org wrote:

    Hi Amit,

    Following your report, Anca did a fix on SVN - see:
      http://lists.opensips.org/pipermail/devel/2011-March/007893.html

    Please update from SVN and try again.

    Regards,
    Bogdan

    Amit Sharma wrote:

        I am facing an issue similiar to the one outlined in the thread

        http://lists.opensips.org/pipermail/users/2010-April/011783.html


         I am using the latest stable version of opensips (1.6.4) and
        tried the solution outlined in the thread above.
        The issue I have observed is that t_relay function doesn't
        return control to the script in case of a send failure (e.g
        inability to establish TCP connection etc)  and I recieve a
        477 send failure on the client.

        This is the relevant and simplified route block that I am using

         route{
                   lookup();
                 serialize_branches(1);
                 next_branches();
                 route(1);
         }

        route[1]{
                xlog(L_ERR, Before t_relay);
                t_relay();
                xlog(L_ERR, After t_relay);

        }

          The log statement after the call to t_relay doesn't get
        printed in case the highest priority contact (TCP)  is
        unreachable.
          In essence any failover logic written on the return value of
        t_relay doesn't execute.

        Thanks,
        Amit



  

        ___
        Users mailing list
        Users@lists.opensips.org mailto:Users@lists.opensips.org
        http://lists.opensips.org/cgi-bin/mailman/listinfo/users



    --     Bogdan-Andrei Iancu
    OpenSIPS eBootcamp - 28th February 2011
    OpenSIPS solutions and know-how


    ___
    Users mailing list
    Users@lists.opensips.org mailto:Users@lists.opensips.org
    http://lists.opensips.org/cgi-bin/mailman/listinfo/users




 --
 Bogdan-Andrei Iancu
 OpenSIPS eBootcamp - 28th February 2011
 OpenSIPS solutions and know-how


 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay behavior with 477 send failed

[Bogdan-Andrei Iancu]

Hi Amit,

have you set the 0x02 flag for t_relay ? See:
  http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id293378

This flag will prevent the t_relay() function do internally deal with 
errors (by sending back a negative reply).


Regards,
Bogdan

Amit Sharma wrote:
I tried the fix from the 1.6 branch. The issue I still face is that 
now t_relay returns with a value of 1 even when the relaying has failed.


How do you figure out if t_relay has failed (!t_relay()) does not work 
in this case? Does a return value 1 also signify an error?
 
-Amit


On Tue, Mar 15, 2011 at 3:51 PM, Bogdan-Andrei Iancu 
bog...@opensips.org mailto:bog...@opensips.org wrote:


Hi Amit,

Following your report, Anca did a fix on SVN - see:
  http://lists.opensips.org/pipermail/devel/2011-March/007893.html

Please update from SVN and try again.

Regards,
Bogdan

Amit Sharma wrote:

I am facing an issue similiar to the one outlined in the thread

http://lists.opensips.org/pipermail/users/2010-April/011783.html


 I am using the latest stable version of opensips (1.6.4) and
tried the solution outlined in the thread above.
The issue I have observed is that t_relay function doesn't
return control to the script in case of a send failure (e.g
inability to establish TCP connection etc)  and I recieve a
477 send failure on the client.

This is the relevant and simplified route block that I am using

 route{
   lookup();
 serialize_branches(1);
 next_branches();
 route(1);
 }

route[1]{
xlog(L_ERR, Before t_relay);
t_relay();
xlog(L_ERR, After t_relay);

}

  The log statement after the call to t_relay doesn't get
printed in case the highest priority contact (TCP)  is
unreachable.
  In essence any failover logic written on the return value of
t_relay doesn't execute.

Thanks,
Amit




___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 




-- 
Bogdan-Andrei Iancu

OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and know-how


___
Users mailing list
Users@lists.opensips.org mailto:Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users





--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and know-how


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay behavior with 477 send failed

[Amit Sharma]

I tried the fix from the 1.6 branch. The issue I still face is that now
t_relay returns with a value of 1 even when the relaying has failed.

How do you figure out if t_relay has failed (!t_relay()) does not work in
this case? Does a return value 1 also signify an error?

-Amit

On Tue, Mar 15, 2011 at 3:51 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote:

 Hi Amit,

 Following your report, Anca did a fix on SVN - see:
   http://lists.opensips.org/pipermail/devel/2011-March/007893.html

 Please update from SVN and try again.

 Regards,
 Bogdan

 Amit Sharma wrote:

 I am facing an issue similiar to the one outlined in the thread

 http://lists.opensips.org/pipermail/users/2010-April/011783.html


  I am using the latest stable version of opensips (1.6.4) and tried the
 solution outlined in the thread above.
 The issue I have observed is that t_relay function doesn't return control
 to the script in case of a send failure (e.g inability to establish TCP
 connection etc)  and I recieve a 477 send failure on the client.

 This is the relevant and simplified route block that I am using

  route{
lookup();
  serialize_branches(1);
  next_branches();
  route(1);
  }

 route[1]{
 xlog(L_ERR, Before t_relay);
 t_relay();
 xlog(L_ERR, After t_relay);

 }

   The log statement after the call to t_relay doesn't get printed in case
 the highest priority contact (TCP)  is unreachable.
   In essence any failover logic written on the return value of t_relay
 doesn't execute.

 Thanks,
 Amit


 

 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users




 --
 Bogdan-Andrei Iancu
 OpenSIPS eBootcamp - 28th February 2011
 OpenSIPS solutions and know-how


 ___
 Users mailing list
 Users@lists.opensips.org
 http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay behavior with 477 send failed

[Bogdan-Andrei Iancu]

Hi Amit,

Following your report, Anca did a fix on SVN - see:
   http://lists.opensips.org/pipermail/devel/2011-March/007893.html

Please update from SVN and try again.

Regards,
Bogdan

Amit Sharma wrote:

I am facing an issue similiar to the one outlined in the thread

http://lists.opensips.org/pipermail/users/2010-April/011783.html


 I am using the latest stable version of opensips (1.6.4) and tried 
the solution outlined in the thread above.
The issue I have observed is that t_relay function doesn't return 
control to the script in case of a send failure (e.g inability to 
establish TCP connection etc)  and I recieve a 477 send failure on the 
client.


This is the relevant and simplified route block that I am using

  route{
  
  lookup();

  serialize_branches(1);
  next_branches();
  route(1);
  }

route[1]{
 xlog(L_ERR, Before t_relay);
 t_relay();
 xlog(L_ERR, After t_relay);

}

   The log statement after the call to t_relay doesn't get printed in 
case the highest priority contact (TCP)  is unreachable.
   In essence any failover logic written on the return value of 
t_relay doesn't execute.


Thanks,
Amit




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
  



--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and know-how


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay behavior with 477 send failed

[Amit Sharma]

I am facing an issue similiar to the one outlined in the thread

http://lists.opensips.org/pipermail/users/2010-April/011783.html


 I am using the latest stable version of opensips (1.6.4) and tried the
solution outlined in the thread above.
The issue I have observed is that t_relay function doesn't return control to
the script in case of a send failure (e.g inability to establish TCP
connection etc)  and I recieve a 477 send failure on the client.

This is the relevant and simplified route block that I am using

  route{

  lookup();
  serialize_branches(1);
  next_branches();
  route(1);
  }

route[1]{
 xlog(L_ERR, Before t_relay);
 t_relay();
 xlog(L_ERR, After t_relay);

}

   The log statement after the call to t_relay doesn't get printed in case
the highest priority contact (TCP)  is unreachable.
   In essence any failover logic written on the return value of t_relay
doesn't execute.

Thanks,
Amit
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay(tcp:)

[Jeff Chua]

t_relay() default to udp. How can force it to tcp without specifying the host?


Thanks,
Jeff

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay(tcp:)

[Jeff Chua]

On Tue, Mar 8, 2011 at 12:23 AM, Dave Singer dave.sin...@wideideas.com wrote:
 Jeff,

 I like using the core rewritable variables to control things. They
 allow you to easily change just one part of the request and many times
 the equivalent function does not accept variables as arguments.

 $rP RURI protocol: http://www.opensips.org/Resources/DocsCoreVar16#toc65
 $fs Forced socket: http://www.opensips.org/Resources/DocsCoreVar16#toc38

 Dave


Dave,

Thanks for pointer. I'll try it out. Still learning. Newbie.


Jeff

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay() not relaying payload

[Bogdan-Andrei Iancu]

Hi Thamer,

actually I see a 408 TIMEOUT for the second re-INVITE - but I see not 
outgoing re-INVITE in the second step (only the inbound message)

Looking at the 2 re-INVITEs, I would say you have a routing issue as the 
first re-INVITE has as RURI a public IP 
(sip:1...@uac.ip.address.here:5060), while the second re-INVITE has a 
private IP (sip:1...@192.168.2.12:5060)
So, maybe the NAT traversal logic for the sequential requests is not 
correct.

Regards,
Bogdan

Thamer Alharbash wrote:
 Hi Bogdan,

 Sorry for not getting back sooner. I've updated my config a bit. I'm  
 including what our reinvite handling looks like and the two reinvites  
 that pass through opensips. The second one as you can see has no  
 payload (ngrep shows ...) I have verified this as well under wireshark.

 if (has_totag()) {

  # sequential request within a dialog should
  # take the path determined by record-routing

  if (loose_route()) {

  if (is_method(BYE)) {
  setflag(1); # do accounting ...
  setflag(3); # ... even if the  
 transaction fails

  } else if (is_method(INVITE)) {
  # even if in most of the cases is  
 useless, do RR for
  # re-INVITEs also, as some buggy  
 clients do change route set
  # during the dialog.
  record_route_preset 
 (proxy.ip.address.here);
  }
  # route it out to whatever destination was  
 set by loose_route()
  # in $du (destination URI).
  route(1);
 ...
 route[1] {
  # for INVITEs enable some additional helper routes
  if (is_method(INVITE)) {
  t_on_branch(1);
  t_on_reply(1);
  t_on_failure(1);
  if(has_body(application/sdp)) {
  rtpproxy_offer(frc,proxy.ip.address.here);
  xlog (Setting rtpproxy_offer);
  }
  if (isbflagset(6)) {
  fix_nated_contact();
  }

  }




 -- FIRST REINVITE

 U carrier.ip.address.here:5060 - our.proxy.ip.address:5060
 INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
 2.0.
 Via: SIP/2.0/UDP carrier.ip.address.here: 
 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
 Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
 From: sip: 
 2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
 +1+ad440023+8233f214.
 To: Thamer Al-Harbash sip: 
 1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
 CSeq: 878247939 INVITE.
 Expires: 180.
 Min-SE: 1800.
 Session-Expires: 1800;refresher=uac.
 Supported: 100rel,timer.
 Max-Forwards: 69.
 Contact: sip:2165928...@our.proxy.ip.address:5060;transport=udp.
 Content-Type: application/sdp.
 Content-Length: 216.
 Route: sip:carrier.ip.address.here;lr=on.
 .
 v=0.
 o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
 s=-.
 c=IN IP4 carrier.ip.address.here.
 t=0 0.
 m=audio 10044 RTP/AVP 0 101.
 a=sendrecv.
 a=ptime:20.
 a=rtpmap:0 PCMU/8000.
 a=rtpmap:101 telephone-event/8000.
 a=fmtp:101 0-15.


 U our.proxy.ip.address:5060 - carrier.ip.address.here:5060
 SIP/2.0 100 Giving a try.
 Via: SIP/2.0/UDP carrier.ip.address.here: 
 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
 Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
 From: sip: 
 2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
 +1+ad440023+8233f214.
 To: Thamer Al-Harbash sip: 
 1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
 CSeq: 878247939 INVITE.
 Server: OpenSIPS (1.6.0-notls (i386/linux)).
 Content-Length: 0.
 .

 U our.proxy.ip.address:5060 - uac.ip.address.here:5060
 INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
 2.0.
 Record-Route: sip:our.proxy.ip.address;lr=on.
 Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0.
 Via: SIP/2.0/UDP carrier.ip.address.here: 
 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
 Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
 From: sip: 
 2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
 +1+ad440023+8233f214.
 To: Thamer Al-Harbash sip: 
 1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
 CSeq: 878247939 INVITE.
 Expires: 180.
 Min-SE: 1800.
 Session-Expires: 1800;refresher=uac.
 Supported: 100rel,timer.
 Max-Forwards: 68.
 Contact: sip:2165928...@carrier.ip.address.here:5060;transport=udp.
 Content-Type: application/sdp.
 Content-Length: 217.
 .
 v=0.
 o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
 s=-.
 c=IN IP4 our.proxy.ip.address.
 t=0 0.
 m=audio 32104 RTP/AVP 0 101.
 a=sendrecv.
 a=ptime:20.
 a=rtpmap:0 PCMU/8000.
 a=rtpmap:101 

Re: [OpenSIPS-Users] t_relay() not relaying payload

[Thamer Alharbash]

Hi Bogdan,

Sorry for not getting back sooner. I've updated my config a bit. I'm  
including what our reinvite handling looks like and the two reinvites  
that pass through opensips. The second one as you can see has no  
payload (ngrep shows ...) I have verified this as well under wireshark.

if (has_totag()) {

 # sequential request within a dialog should
 # take the path determined by record-routing

 if (loose_route()) {

 if (is_method(BYE)) {
 setflag(1); # do accounting ...
 setflag(3); # ... even if the  
transaction fails

 } else if (is_method(INVITE)) {
 # even if in most of the cases is  
useless, do RR for
 # re-INVITEs also, as some buggy  
clients do change route set
 # during the dialog.
 record_route_preset 
(proxy.ip.address.here);
 }
 # route it out to whatever destination was  
set by loose_route()
 # in $du (destination URI).
 route(1);
...
route[1] {
 # for INVITEs enable some additional helper routes
 if (is_method(INVITE)) {
 t_on_branch(1);
 t_on_reply(1);
 t_on_failure(1);
 if(has_body(application/sdp)) {
 rtpproxy_offer(frc,proxy.ip.address.here);
 xlog (Setting rtpproxy_offer);
 }
 if (isbflagset(6)) {
 fix_nated_contact();
 }

 }




-- FIRST REINVITE

U carrier.ip.address.here:5060 - our.proxy.ip.address:5060
INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
2.0.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: sip: 
2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: Thamer Al-Harbash sip: 
1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
CSeq: 878247939 INVITE.
Expires: 180.
Min-SE: 1800.
Session-Expires: 1800;refresher=uac.
Supported: 100rel,timer.
Max-Forwards: 69.
Contact: sip:2165928...@our.proxy.ip.address:5060;transport=udp.
Content-Type: application/sdp.
Content-Length: 216.
Route: sip:carrier.ip.address.here;lr=on.
.
v=0.
o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
s=-.
c=IN IP4 carrier.ip.address.here.
t=0 0.
m=audio 10044 RTP/AVP 0 101.
a=sendrecv.
a=ptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.


U our.proxy.ip.address:5060 - carrier.ip.address.here:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: sip: 
2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: Thamer Al-Harbash sip: 
1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
CSeq: 878247939 INVITE.
Server: OpenSIPS (1.6.0-notls (i386/linux)).
Content-Length: 0.
.

U our.proxy.ip.address:5060 - uac.ip.address.here:5060
INVITE sip:1...@uac.ip.address.here:5060;transport=udp;user=phone SIP/ 
2.0.
Record-Route: sip:our.proxy.ip.address;lr=on.
Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: sip: 
2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: Thamer Al-Harbash sip: 
1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
CSeq: 878247939 INVITE.
Expires: 180.
Min-SE: 1800.
Session-Expires: 1800;refresher=uac.
Supported: 100rel,timer.
Max-Forwards: 68.
Contact: sip:2165928...@carrier.ip.address.here:5060;transport=udp.
Content-Type: application/sdp.
Content-Length: 217.
.
v=0.
o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
s=-.
c=IN IP4 our.proxy.ip.address.
t=0 0.
m=audio 32104 RTP/AVP 0 101.
a=sendrecv.
a=ptime:20.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

-- SECOND REINVITE

U carrier.ip.address.here:5060 - our.proxy.ip.address:5060
INVITE sip:1...@192.168.2.12:5060;transport=udp;user=phone SIP/2.0.
Via: SIP/2.0/UDP carrier.ip.address.here: 
5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1.
Call-ID: 3110d9027c77f4e246f17ef1f5b73...@192.168.2.12.
From: sip: 
2165928...@our.proxy.hostname.here;user=phone;tag=SD1ko0299-324092c7 
+1+ad440023+8233f214.
To: Thamer Al-Harbash sip: 
1...@our.proxy.hostname.here;user=phone;tag=83134be1983195b6.
CSeq: 878247940 INVITE.
Expires: 180.
Min-SE: 1800.
Session-Expires: 1800;refresher=uac.

Re: [OpenSIPS-Users] t_relay() not relaying payload

[Bogdan-Andrei Iancu]

Hi Thamer,

Could you post the first re-INVITE (received and sent) to see what could 
be the problem?

Regards,
Bogdan

Thamer Alharbash wrote:
 We currently have opensips setup to route through another carrier for  
 certain calls. All signaling and media works well except for reinvites.

  if (has_totag()) {

  # sequential request within a dialog should
  # take the path determined by record-routing

  if (loose_route()) {
  if (is_method(BYE)) {
  setflag(1); # do accounting ...
  setflag(3); # ... even if the  
 transaction fails
  } else if (is_method(INVITE)) {
  # even if in most of the cases is  
 useless, do RR for
  # re-INVITEs alos, as some buggy  
 clients do change route set
  # during the dialog.
  record_route_preset(hidden);
  }
   fix_nated_contact();
  t_relay();
 ...

 The first reinvite passes through fine with the nated contact fixed  
 for the contact field. The second reinvite does not get relayed  
 correctly. Instead a udp packet with no SIP payload at all is sent to  
 the UA. We can't find any particular error in the debug log.

 Does anyone have thoughts on this?

   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay() not relaying payload

[Thamer Alharbash]

We currently have opensips setup to route through another carrier for  
certain calls. All signaling and media works well except for reinvites.

 if (has_totag()) {

 # sequential request within a dialog should
 # take the path determined by record-routing

 if (loose_route()) {
 if (is_method(BYE)) {
 setflag(1); # do accounting ...
 setflag(3); # ... even if the  
transaction fails
 } else if (is_method(INVITE)) {
 # even if in most of the cases is  
useless, do RR for
 # re-INVITEs alos, as some buggy  
clients do change route set
 # during the dialog.
 record_route_preset(hidden);
 }
fix_nated_contact();
 t_relay();
...

The first reinvite passes through fine with the nated contact fixed  
for the contact field. The second reinvite does not get relayed  
correctly. Instead a udp packet with no SIP payload at all is sent to  
the UA. We can't find any particular error in the debug log.

Does anyone have thoughts on this?

-- 
Thamer





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] t_relay() for Tel-URI

[David Roberge]

Hi OpenSIPS users,

 

I have a UAC sending OpenSIPS a SIP INVITE with a SIP RURI.  I need OpenSIPS
to rewrite the SIP RURI into a TEL RURI and statefully relay this message to
the UAS.

 

Can I use the t_relay() function to forward the modified INVITE to the UAS?

 

Since the TEL RURI does not contains any domain part, how OpenSIPS will be
able to forward the message to the correct destination?

 

Many thanks.

 

/David

 

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] t_relay() for Tel-URI

[Iñaki Baz Castillo]

2009/6/3 David Roberge drobe...@xittel.net:
 Hi OpenSIPS users,

 I have a UAC sending OpenSIPS a SIP INVITE with a SIP RURI.  I need OpenSIPS
 to rewrite the SIP RURI into a TEL RURI and statefully relay this message to
 the UAS.

 Can I use the t_relay() function to forward the modified INVITE to the UAS?

Yes (see below)


 Since the TEL RURI does not contains any domain part, how OpenSIPS will be
 able to forward the message to the correct destination?

That's the point. A TEL URI has no information about the real
destination of itself. What your proxy must do is:
- Change the RURI (from SIP to TEL).
- Set the $du variable which is the *real* destination of the request.
  Example:  $du = sip:1.2.3.4:5080;
- Do t_relay().

:)


-- 
Iñaki Baz Castillo
i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users