[OpenSIPS-Users] Call Forward
Hi All,
I am trying to call forward when the destination agent is not
registered/available on the proxy.
The relevant routes are below.
On a 486 BUSY it works perfectly !
At the top of my route block I have:
if (!mf_process_maxfwd_header("5")) {
xlog("L_INFO","LOOP [$fd/$fu/$rd/$ru/$si/]\n");
sl_send_reply("483","Unavailable");
exit;
}
so if the UA is not registered to the proxy and it cannot find it, 483 is
returned on the INVITE.
on 483 if I use the same code as on 486:
revert_uri();
prefix("171");
rewritehostport("X.X.X.X:5060");
t_relay();
It seems to endlessly loop, eventually giving header errors.
In both cases the INVITE is called using:
do_routing("1");
lookup("location");
route(1);
exit;
What am I missing? Surely it should act the same in both cases.
route[1] {
xlog("L_INFO","Route1 [$fd/$fu/$rd/$ru/$si/]\n");
if (is_method("INVITE")) {
t_on_branch("1");
t_on_failure("1");
xlog("L_INFO","Route1 INVITE [$fd/$fu/$rd/$ru/$si/]\n");
if(has_body("application/sdp")){
xlog("L_INFO","Route1 INVITE has SDP
[$fd/$fu/$rd/$ru/$si/]\n");
if (rtpproxy_offer()){
xlog("L_INFO","Route1 INVITE Proxy Offered
[$fd/$fu/$rd/$ru/$si/]\n");
t_on_reply("1");
}
else {
t_on_reply("3");
};
} else {
xlog("L_INFO","Route1 INVITE No SDP
[$fd/$fu/$rd/$ru/$si/]\n");
t_on_reply("2");
}
}
if (is_method("ACK") && has_body("application/sdp")){
xlog("L_INFO","Route1 INVITE ACK with SDP Answer Proxy
[$fd/$fu/$rd/$ru/$si/]\n");
rtpproxy_answer();
}
if (is_method("BYE")){
xlog("L_INFO","Route1 BYE [$fd/$fu/$rd/$ru/$si/]\n");
}
if (!t_relay()) {
sl_reply_error();
};
}
branch_route[1]
{
xlog("L_INFO","Branch Route1 [$fd/$fu/$rd/$ru/$si/]\n");
setflag(3); # start db accounting
}
failure_route[1]
{
xlog("L_INFO","Failure Route1 [$fd/$fu/$rd/$ru/$si/]\n");
if (t_was_cancelled()) {
xlog("L_INFO","Failed on Cancel [$fd/$fu/$rd/$ru/$si/]\n");
exit;
}
if (t_check_status("6[0-9]")) {
xlog("L_INFO","Global Failure on Congestion
[$fd/$fu/$rd/$ru/$si/]\n");
exit;
}
if (t_check_status("486")){ # Divert on BUSY
xlog("L_INFO","Call Forward on BUSY [$fd/$fu/$rd/$ru/$si/]\n");
revert_uri();
prefix("171");
rewritehostport("X.X.X.X:5060");
t_relay();
exit;
};
if (t_check_status("483")){ # Divert on UNAVAILABLE
xlog("L_INFO","Call Forward on UNAVAILABLE not available
[$fd/$fu/$rd/$ru/$si/]\n");
exit;
};
}
Regards
<http://www.greydotelecom.net/bcard/jnysschen.htm> Juri Nysschen
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Interproxy Authentication
Hi All, I want this scenario: UA - > Opensips1 -> Opensip2 -> PSTN Opensips2 has a set of subscribers and verifies authentication against a mysql db, keeps cdrs etc. Opensips1 has a different set of subscribers with db authentication and cdrs. The UA makes a call and is routed from Opensips1 to Opensips2 and then onto the PSTN gateway. My question is how do I impersonate the call made by UA as coming from a valid subscriber known to Opensips2? Currently I use asterisk to perform this role, but would ideally like to remove it from the chain: UA - > Opensips1 -> Asterisk -> Opensips2 -> PSTN Regards <http://www.greydotelecom.net/bcard/jnysschen.htm> Juri Nysschen ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] FW: CANCELs with no transaction
Hi Dave,
It worked! The CDRs are perfect. Thanks for the help.
Here's the code in case anyone else has the same issue:
rout{
..
# handle cancel and re-transmissions
if (is_method("CANCEL") ) {
xlog("L_INFO","CANCEL [$fd/$fu/$rd/$ru/$si/]\n");
setflag(3); # start db accounting
setflag(5); # log failed transactions
route(5); # disconnect media proxy
if (t_check_trans()){
t_relay();
exit;
}
xlog("L_INFO","CANCEL Generated [$fd/$fu/$rd/$ru/$si/]\n");
# send a CANCEL downstream
exec_msg("/usr/sbin/opensipsctl fifo t_uac_cancel $ci $cs");
# send a ACK upstream for cdr purposes.
sl_send_reply("200","OK");
exit;
}
}
Regards
Juri Nysschen
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
Sent: Tuesday, February 15, 2011 8:28 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] FW: CANCELs with no transaction
Juri,
You should be able to get to it with
$(hdr(via){param.value,branch})
But forcing it on the outbound cancel would probably be quite a trick
since opensips wants to add It's via header automatically and that top
via is what the next hop is counting on for matching the call.
I think your best bet is to use the MI t_uac_cancel command as
described last time. With it you don't have to same anything from the
INVITE. You just use the callid and cseq from the CANCEL to pass to
the MI command t_uac_cancel.
Be aware you may have linux and selinux permissions conflicts for
executing opensipsctl from inside opensips. I posted in a thread a
thing about dealing with selinux in the last couple months that makes
it quite easy if selinux is a problem and to see if it is the problem.
Your command would be something like:
exec("/usr/local/opensips/sbin/opensipsctl fifo t_uac_cancel $ci $cs");
Don't forget to make sure the source canceling the call gets the
response they are looking for so they don't keep sending you cancels
and you keep doing the exec over and over.
Dave
On Tue, Feb 15, 2011 at 5:52 AM, Juri Nysschen
wrote:
> Hi Dave
>
> I have used wireshark to review the cancel message on a call timeout
(which
> works) and when received from the UA.
>
> The difference is in the branch= value as you predicted.
>
> How can I save the branch value on the INVITE and then change it on the
> CANCEL?
> I've tried all sorts of combinations for $branch but the vales are always
> NULL
>
>
> Regards
> Juri Nysschen
>
> -Original Message-
> From: users-boun...@lists.opensips.org
> [mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
> Sent: Monday, February 14, 2011 10:16 PM
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] FW: CANCELs with no transaction
>
> Juri,
>
> This was gnawing at me so I searched and found the "official" answer
> of what a CANCEL should look like.
> Go to
> http://www.ietf.org/rfc/rfc3261.txt
> and search for "9 Canceling a Request"
> From what I read it basically says that the CANCEL should be nearly
> identical to the INVITE it is canceling (without some headers that
> aren't useful in a cancel like Supported)
> It seems that the "branch=" , a "Magic Cookie", on the top most
> via line is a turbo lookup to finding the transaction. That matches
> the original INVITE and all is well. If it is not there then it has to
> compare all the pertinent headers between invite and cancel.
>
> So if you can't get them to send the proper stuff, you could modify
> the previous hack to store the branch=... that opensips put in the via
> header it added (probably can't see it when sending the invite but it
> is in the 1xx response to your invite.
> Actually I just found one better I think. Use the exec module to
> execute MI command t_uac_cancel
> (http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id294623)
> All it needs are callid and cseq num, which I hope at least they are
> the same as the INVITE, which you can use the CANCEL's parsed vars for
> the params. I you will probably need to send back a negative response
> to the bad CANCEL like 400 Bad Message (look up appropriate
> code/message). And I think the t_uac_cancel will also push into
> failure_route a 487 response, which if you don't choose anything else
> specifically, will be sent back to the originator.
> You will want to verify it with packet captures and see how it affects
> your cdrs.
>
&g
Re: [OpenSIPS-Users] FW: CANCELs with no transaction
Hi Dave
I have used wireshark to review the cancel message on a call timeout (which
works) and when received from the UA.
The difference is in the branch= value as you predicted.
How can I save the branch value on the INVITE and then change it on the
CANCEL?
I've tried all sorts of combinations for $branch but the vales are always
NULL
Regards
Juri Nysschen
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
Sent: Monday, February 14, 2011 10:16 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] FW: CANCELs with no transaction
Juri,
This was gnawing at me so I searched and found the "official" answer
of what a CANCEL should look like.
Go to
http://www.ietf.org/rfc/rfc3261.txt
and search for "9 Canceling a Request"
>From what I read it basically says that the CANCEL should be nearly
identical to the INVITE it is canceling (without some headers that
aren't useful in a cancel like Supported)
It seems that the "branch=" , a "Magic Cookie", on the top most
via line is a turbo lookup to finding the transaction. That matches
the original INVITE and all is well. If it is not there then it has to
compare all the pertinent headers between invite and cancel.
So if you can't get them to send the proper stuff, you could modify
the previous hack to store the branch=... that opensips put in the via
header it added (probably can't see it when sending the invite but it
is in the 1xx response to your invite.
Actually I just found one better I think. Use the exec module to
execute MI command t_uac_cancel
(http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id294623)
All it needs are callid and cseq num, which I hope at least they are
the same as the INVITE, which you can use the CANCEL's parsed vars for
the params. I you will probably need to send back a negative response
to the bad CANCEL like 400 Bad Message (look up appropriate
code/message). And I think the t_uac_cancel will also push into
failure_route a 487 response, which if you don't choose anything else
specifically, will be sent back to the originator.
You will want to verify it with packet captures and see how it affects
your cdrs.
Let me know the outcome.
Dave
On Mon, Feb 14, 2011 at 11:05 AM, Dave Singer
wrote:
> I was half expecting that kind of result.
> I don't know what exactly opensips uses to match transactions. I
> believe Call-id and CSeq headers being the same but I'm quite sure
> there is more like maybe from tag? I don't know.
>
> Can anyone else chime in on what opensips is checking to match a
transaction.
>
> Dave.
>
> On Sun, Feb 13, 2011 at 11:36 PM, Juri Nysschen
wrote:
>> Hi Dave,
>>
>> Thanks this method is very successful in delivering the CANCEL
downstream,
>> over multiple hops, unfortunately the PSTN also doesn't see the
transaction
>> id and therefore the call keeps ringing.
>> The key is finding the reason why the transaction id disappears or at
least
>> be able to put it back when delivering the CANCEL downstream.
>>
>> Regards
>> Juri Nysschen
>>
>> -Original Message-
>> From: users-boun...@lists.opensips.org
>> [mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
>> Sent: Monday, February 14, 2011 9:03 AM
>> To: ty...@fonality.com; OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] FW: CANCELs with no transaction
>>
>> Juri,
>>
>> You say it only happens after a do_routing(). To be clear, you mean
>> that you used do_routing on the invite and not that you already tried
>> do_routing for the cancel earlier in the script. (I'm not sure it
>> would make any difference)
>>
>> The hack to store the destination in a variable is one you would want
>> to strongly avoid. But sometimes hacks are unavoidable and a stop gap
>> until you can really resolve the problem.
>> I believe $avp's are retained per transaction and if the
>> t_check_trans() fails then the $avp created in the reply would also
>> not be available.
>> $var also would not work most of the time since it is persistent per
>> process. You would need to use core functions cache_store and
>> cache_fetch using either local_cache or memcached backend depending if
>> you need persistant between opensips reboot.
>> Example:
>>
>> route{
>>
>> .
>>
>> if (is_method("CANCEL") ) {
>>
>> route(5); # drop media proxy
>>
>> if (t_check_trans()){ # this always fails after a do_routing()
>>
>> xlog("L_INFO","CANCEL
>> Transaction[$fd/$fu/$rd/$ru/$si/
Re: [OpenSIPS-Users] Weird behaviour
yeah, you're right, there's also probably no harm in filtering SUBSCIBE as
well...
Regards
Juri Nysschen
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
Sent: Monday, February 14, 2011 10:42 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Weird behaviour
Juri,
Thanks for the compliment!
Great addition yourself!
I hadn't looked at the premissions module before and it looks to be a
good resource for potentially many tasks.
Using it as you show would be much faster than trying to do db lookup
and cache_store method!
Only one thing, you are only showing to do it for OPTIONS, what about
NOTIFY?
Dave,
On Sun, Feb 13, 2011 at 11:40 PM, Juri Nysschen
wrote:
> Hi All
>
> Filtering OPTIONs is brilliant, I've taken it one step further by also
> filtering against the opensips address table.
>
> So if the ip is listed in the table OR had registered beforehand there
will
> be a reply on the OPTIONs message:
>
> if (is_method("OPTIONS")){
> xlog("L_INFO","OPTIONS [$fd/$fu/$rd/$ru/$si/]\n");
> if (check_source_address("1")) ||
> (cache_fetch("local","ip_allowed_$si",$avp(i:60))){
> xlog("L_INFO","OPTIONS OK
> [$fd/$fu/$rd/$ru/$si/]\n");
> sl_send_reply("200", "Got it");
> exit;
> };
> drop;
> };
>
>
> On a successful register:
> cache_store("local","ip_allowed_$si","$si",1200);
>
>
> Regards
> Juri Nysschen
>
>
> -Original Message-
> From: users-boun...@lists.opensips.org
> [mailto:users-boun...@lists.opensips.org] On Behalf Of Adrian Vasile
> Sent: Saturday, February 12, 2011 9:26 AM
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] Weird behaviour
>
> That's why I dropped the ideea of having numbered usernames.
>
> On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:
>
>> Adrian,
>>
>> Probably want to only respond to registers that are to valid user
>> accounts, drop the rest, as they start scanning with like 100, 101,
>> ., 5000, etc
>>
>> Dave
>>
>> On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile wrote:
>>> Hi Dave,
>>>
>>> Yeah, you're right.. Basically allow only REGISTER requests from
anywhere
> and
>>> the rest check the source ip.
>>> Great ideea.
>>>
>>> I will implement it as soon as possible.
>>>
>>> Thanks,
>>> Adrian Vasile
>>> y...@opennet.ro
>>>
>>>
>>> On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:
>>>
>>>> Adrian,
>>>>
>>>> I was just thinking about the implementing no response for INVITE a
>>>> little more...
>>>> You would want to handle the response checking similar to the
>>>> register. If not found in the cache where you check the location
>>>> table if there is a registered user at the source ip.
>>>> That way it can handle opensips reboots and other situations where the
>>>> cache is lost or unavailable. Like a memcached server fails.
>>>> Advantage to using external memcached vs local cache would be that
>>>> cache would not be cleared on opensips restart.
>>>>
>>>> Dave
>>>>
>>>> On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer
> wrote:
>>>>> I've found that generally they start out with the sip NOTIFY or
>>>>> OPTIONS message. So recently I set in the script to drop them from
>>>>> sources I'm not expecting them from. Might not work so well for some
>>>>> situation like ATA's sending pings for nat keep alives. But for the
>>>>> nat to keep open, generally it doesn't need a response, just as long
>>>>> as they keep sending the packets. Some devices I've seen actually send
>>>>> essentially an empty packet to the sip port, just enough to keep the
>>>>> nat alive but opensips just discards it because it is empty.
>>>>> The one I do send a reply to is my network monitoring server. Kind of
>>>>> helpful to know when things stop responding. :-)
>>>>> If an ATA model need to actually get a reply you could on registration
>>>>> check the model listed in the sip agent header and use localcache or
>>>>> memcached to store the source IP as ok to respond to. See
>>>>&g
Re: [OpenSIPS-Users] Weird behaviour
Hi All
Filtering OPTIONs is brilliant, I've taken it one step further by also
filtering against the opensips address table.
So if the ip is listed in the table OR had registered beforehand there will
be a reply on the OPTIONs message:
if (is_method("OPTIONS")){
xlog("L_INFO","OPTIONS [$fd/$fu/$rd/$ru/$si/]\n");
if (check_source_address("1")) ||
(cache_fetch("local","ip_allowed_$si",$avp(i:60))){
xlog("L_INFO","OPTIONS OK
[$fd/$fu/$rd/$ru/$si/]\n");
sl_send_reply("200", "Got it");
exit;
};
drop;
};
On a successful register:
cache_store("local","ip_allowed_$si","$si",1200);
Regards
Juri Nysschen
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Adrian Vasile
Sent: Saturday, February 12, 2011 9:26 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Weird behaviour
That's why I dropped the ideea of having numbered usernames.
On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:
> Adrian,
>
> Probably want to only respond to registers that are to valid user
> accounts, drop the rest, as they start scanning with like 100, 101,
> ., 5000, etc
>
> Dave
>
> On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile wrote:
>> Hi Dave,
>>
>> Yeah, you're right.. Basically allow only REGISTER requests from anywhere
and
>> the rest check the source ip.
>> Great ideea.
>>
>> I will implement it as soon as possible.
>>
>> Thanks,
>> Adrian Vasile
>> y...@opennet.ro
>>
>>
>> On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:
>>
>>> Adrian,
>>>
>>> I was just thinking about the implementing no response for INVITE a
>>> little more...
>>> You would want to handle the response checking similar to the
>>> register. If not found in the cache where you check the location
>>> table if there is a registered user at the source ip.
>>> That way it can handle opensips reboots and other situations where the
>>> cache is lost or unavailable. Like a memcached server fails.
>>> Advantage to using external memcached vs local cache would be that
>>> cache would not be cleared on opensips restart.
>>>
>>> Dave
>>>
>>> On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer
wrote:
>>>> I've found that generally they start out with the sip NOTIFY or
>>>> OPTIONS message. So recently I set in the script to drop them from
>>>> sources I'm not expecting them from. Might not work so well for some
>>>> situation like ATA's sending pings for nat keep alives. But for the
>>>> nat to keep open, generally it doesn't need a response, just as long
>>>> as they keep sending the packets. Some devices I've seen actually send
>>>> essentially an empty packet to the sip port, just enough to keep the
>>>> nat alive but opensips just discards it because it is empty.
>>>> The one I do send a reply to is my network monitoring server. Kind of
>>>> helpful to know when things stop responding. :-)
>>>> If an ATA model need to actually get a reply you could on registration
>>>> check the model listed in the sip agent header and use localcache or
>>>> memcached to store the source IP as ok to respond to. See
>>>> http://www.opensips.org/Resources/DocsCoreFcn16#toc98
>>>> cache_store and cache_fetch
>>>> at registration something like
>>>> save("location");
>>>> cache_store("local", "ping_ok_$si", "ok", 86000);
>>>> and at ping
>>>> if ( $rm =~ "OPTIONS|NOTIFY" ) {
>>>> if( $si == "" || $cache_fetch("local",
>>>> "pingok_$si", $avp(i:5)) {
>>>>sl_send_reply("200", "Ok");
>>>> }
>>>> drop;
>>>> }
>>>>
>>>> Might not need pike if they never start the brute force scan because
>>>> they didn't get the initial reply.
>>>> I just came up with this the other day so it is an unproved theory.
>>>> The other day I left a packet capture running over night on the
>>>> testing server and in the morning I saw all the failed register
>>>> attempts. I looked back to the first packet from the registering
>>>
Re: [OpenSIPS-Users] FW: CANCELs with no transaction
Hi Dave,
Thanks this method is very successful in delivering the CANCEL downstream,
over multiple hops, unfortunately the PSTN also doesn't see the transaction
id and therefore the call keeps ringing.
The key is finding the reason why the transaction id disappears or at least
be able to put it back when delivering the CANCEL downstream.
Regards
Juri Nysschen
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer
Sent: Monday, February 14, 2011 9:03 AM
To: ty...@fonality.com; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] FW: CANCELs with no transaction
Juri,
You say it only happens after a do_routing(). To be clear, you mean
that you used do_routing on the invite and not that you already tried
do_routing for the cancel earlier in the script. (I'm not sure it
would make any difference)
The hack to store the destination in a variable is one you would want
to strongly avoid. But sometimes hacks are unavoidable and a stop gap
until you can really resolve the problem.
I believe $avp's are retained per transaction and if the
t_check_trans() fails then the $avp created in the reply would also
not be available.
$var also would not work most of the time since it is persistent per
process. You would need to use core functions cache_store and
cache_fetch using either local_cache or memcached backend depending if
you need persistant between opensips reboot.
Example:
route{
.
if (is_method("CANCEL") ) {
route(5); # drop media proxy
if (t_check_trans()){ # this always fails after a do_routing()
xlog("L_INFO","CANCEL
Transaction[$fd/$fu/$rd/$ru/$si/]\n");
t_relay();
exit;
} else {
if ( cache_fetch("local", "tran_dest_$ci",
"$avp(s:next_hop)") ) {
$rd = $avp(s:next_hop);
t_relay();
}
exit;
}
}
on_reply[main] {
cache_store("local", "tran_dest_$ci", "$si", 500);
}
Dave
On Sun, Feb 13, 2011 at 5:15 AM, Tyler Merritt wrote:
>
> Why not use an $avp and grab the Call ID header on the inbound packet and
then create some routing logic that checks the $avp against the return
packet Call ID header to validate it's the same thing? $avps can be made
available onreply with a modparam though forgive me if it's a bit late at
night and I don't have the link handy.
> An avp can store more than a single value but they index in reverse order
as written if I recall correctly.
>
> On Sat, Feb 12, 2011 at 5:05 AM, Russell Bierschbach
wrote:
>>
>> I have a similar problem, but not solution, my probably is actually
occurring because the originating UA is ignoring a contact header that is
sent back during a 183 progress message. OpenSIPS uses information from
that contact header to figure out where to relay the incoming message (BYE
in my case, CANCEL in yours). It seems like it would be possible for
OpenSIPS to use a call-id or tag to determine where to relay the message
though.
>>
>>
>>
>> Russell Bierschbach
>>
>> em: rbierschb...@telepointglobal.com, im: rbierschb...@hotmail.com
>>
>>
>>
>> From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Juri Nysschen
>> Sent: Friday, February 11, 2011 7:44 AM
>> To: users@lists.opensips.org
>> Subject: [OpenSIPS-Users] FW: CANCELs with no transaction
>>
>>
>>
>> Hi All,
>>
>>
>>
>> Need help with a nagging issue:
>>
>>
>>
>> UA->Opensips 1->Opensips 2->PSTN
>>
>>
>>
>> UA sends an invite on Opensips 1, and is routed via do_routing() to
Opensips 2, Opensips 2 uses do_routing to get to the PSTN, call starts
ringing.
>>
>>
>>
>> UA cancels call before answer, but now t_check_trans fails and the CANCEL
is not passed onto the PSTN, with the result that the call rings forever and
can only be terminated by the remote answering and dropping the call or
through a timeout.
>>
>>
>>
>> The scripts on Opensips 1 & Opensips 2 is virtuall identical:
>>
>>
>>
>> How do I get the CANCEL to the PSTN ?
>>
>>
>>
>> route{
>>
>> .
>>
>> if (is_method("CANCEL") ) {
>>
>> route(5); # drop media proxy
>>
>> if (t_check_trans()){ # this always fails after a
do_routing()
>>
>> xlog("L_INFO","CANCEL
Transaction[$fd/$fu/$rd/$ru/$si/]\n");
>>
>> t_relay();
>&
[OpenSIPS-Users] FW: CANCELs with no transaction
Hi All,
Need help with a nagging issue:
UA->Opensips 1->Opensips 2->PSTN
UA sends an invite on Opensips 1, and is routed via do_routing() to Opensips
2, Opensips 2 uses do_routing to get to the PSTN, call starts ringing.
UA cancels call before answer, but now t_check_trans fails and the CANCEL is
not passed onto the PSTN, with the result that the call rings forever and
can only be terminated by the remote answering and dropping the call or
through a timeout.
The scripts on Opensips 1 & Opensips 2 is virtuall identical:
How do I get the CANCEL to the PSTN ?
route{
.
if (is_method("CANCEL") ) {
route(5); # drop media proxy
if (t_check_trans()){ # this always fails after a do_routing()
xlog("L_INFO","CANCEL
Transaction[$fd/$fu/$rd/$ru/$si/]\n");
t_relay();
exit;
};
exit;
}
}
route[4] {
xlog("L_INFO","Route4 [$fd/$fu/$rd/$ru/$si/]\n");
$avp(i:102)=1; # Default dr-group
route(10); # Do custom stuff
t_on_failure("4");
if (do_routing("$avp(i:102)")){
xlog("L_INFO","Route4 Route to Dyna Group:
$avp(i:102)[$fd/$fu/$rd/$ru/$si/]\n");
t_newtran();
route(1);
exit;
};
xlog("L_INFO","Route4 No Route to Host[$fd/$fu/$rd/$ru/$si/]\n");
sl_reply_error();
exit;
}
Regards
Juri Nysschen <http://www.greydotelecom.net/bcard/jnysschen.htm>
___
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] CANCELs with no transaction
Hi All,
Need help with a nagging issue:
UA->Opensips 1->Opensips 2->PSTN
UA sends an invite on Opensips 1, and is routed via do_routing() to Opensips
2, Opensips 2 uses do_routing to get to the PSTN, call starts ringing.
UA cancels call before answer, but now t_check_trans fails and the CANCEL is
not passed onto the PSTN, with the result that the call rings forever and
can only be terminated by the remote answering and dropping the call or
through a timeout.
The scripts on Opensips 1 & Opensips 2 is virtuall identical:
How do I get the CANCEL to the PSTN ?
route{
.
if (is_method("CANCEL") ) {
route(5); # drop media proxy
if (t_check_trans()){ # this always fails after a do_routing()
xlog("L_INFO","CANCEL
Transaction[$fd/$fu/$rd/$ru/$si/]\n");
t_relay();
exit;
};
exit;
}
}
route[4] {
xlog("L_INFO","Route4 [$fd/$fu/$rd/$ru/$si/]\n");
$avp(i:102)=1; # Default dr-group
route(10); # Do custom stuff
t_on_failure("4");
if (do_routing("$avp(i:102)")){
xlog("L_INFO","Route4 Route to Dyna Group:
$avp(i:102)[$fd/$fu/$rd/$ru/$si/]\n");
t_newtran();
route(1);
exit;
};
xlog("L_INFO","Route4 No Route to Host[$fd/$fu/$rd/$ru/$si/]\n");
sl_reply_error();
exit;
}
Regards
<http://www.greydotelecom.net/bcard/jnysschen.htm> Juri Nysschen
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
