[OpenSIPS-Users] [Inquiry] 487 Request Cancelled processing
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Fri Oct 9 08:58:29 CEST 2009
Hi
CANCEL needs a special routing in SIP. To learn more, see the
registration of the "Routing in SIP" webinar -
http://www.opensips.org/Training/Webinars#toc5.
Typically, you do not route the CANCELs in the same way as the INVITE,
but you let TM to do the job. If you look into the default opensips.cfg
(that comes with the sources), you will notice a small script block that
takes care of CANCEL processing:
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
It has nothing to do with the area code dialling.
Regards,
Bogdan
osiris123d wrote:
> I think I am running into an issue that has to do with the CANCEL sip
> message.
>
> I have set up a "tricky config" like you mentioned below where I allow the
> users to dial a local number without having to dial the area code. In my
> script I do the following
>
> # -- Allows user not to have to dial the area code
> # -- Uses the AVP $avp(s:areacode) to know the users local
> area
> if (uri=~"^sip:[2-9][0-9]{6}@") {
> xlog("L_INFO", "----- Inside Route 3 - Just added
> Area code prefix to the number dialed");
> avp_db_load("$ru/domain","$avp(s:areacode)");
>
> subst_uri('/^sip:([0-9]+)@(.*)$/sip:$avp(s:areacode)\1@\2/i');
> #$rU = $avp(s:areacode) + $rU;
> };
>
> consume_credentials();
>
>
> This works fine for calls that are connected and then either the caller or
> callee hangs up and a BYE message is sent. The problem is when the caller
> calls the callee and then the callee's phone starts ringing and then the
> caller hangs up the callee's phone continue's to ring. I know this has
> something to do with me allowing my users to dial local numbers without
> typing in the area code because I see the following...
>
>
> SNIPPIT of a good call where a user sends BYE message
>
> Main Route: call [BYE] rU[9x18x13182] ru[sip:9x18x13182 at 64.2.142.75]
> fu[sip:9x12x32009 at irock.com] tu[sip:8x13132 at irock.com] si[192.251.125.xx]
> ct[<sip:9x12x32009 at 192.168.100.80:14106;transport=udp>] RPID[<null>]
> ----- Is not REGISTER Request
> ----- Is NAT UAC 19
> ----- Has To Tag
> ----- Is Loose Route
> ----- METHOD IS BYE OR CANCEL and ending media session
> ----- Is NAT UAC Test 19 or nat=yes
> Route 1: call [BYE] rU[<null>] ru[sip:64.2.142.93:5060]
> fu[sip:9x12x32009 at irock.com] tu[sip:8x13132 at irock.com] si[192.251.125.xx]
> ct[<sip:9x12x32009 at 192.168.100.80:14106;transport=udp>]
> On Reply Route 1: call [BYE] rU[<null>] ru[<null>]
> fu[sip:9x12x32009 at irock.com] tu[sip:8x13132 at irock.com] si[64.2.142.93]
> ct[<sip:9x18x13182 at 64.2.142.75>]
> ----- Inside OnReply Route 1
> ----- Inside OnReply Route 1 with bflag being 6 or 7 and a bunch other stuff
>
>
>
> SNIPPIT of a bad call where Caller sends CANCEL message
>
>
> Main Route: call [CANCEL] rU[8x13182] ru[sip:8x13182 at xyz.com]
> fu[sip:9012732009 at xyz.com] tu[sip:8x13182 at xyz.com] si[192.251.125.xx]
> ct[<null>] RPID[<null>]
> ----- Is not REGISTER Request
> ----- Is NAT UAC 19
> Failure Route 1: call [INVITE] rU[9x18x13182] ru[sip:9x18x13182 at xyz.com]
> fu[sip:9x12x32009 at xyz.com] tu[sip:8x13182 at xyz.com] si[192.251.125.xx]
> ct[<sip:9x12x32009 at 192.168.100.80:14106;transport=udp>]
> ----- Inside Failure Route 1
> BEGIN: SIP message [INVITE] - To URI username=[sip:8x13182 at xyz.com] From
> URI=[sip:9x18x13182 at xyz.com]
> Main Route: call [ACK] rU[8x13182] ru[sip:8x13182 at xyz.com]
> fu[sip:9012732009 at xyz.com] tu[sip:8x13182 at xyz.com] si[192.251.125.xx]
> ct[<null>] RPID[<null>]
> ----- Is not REGISTER Request
> ----- Is NAT UAC 19
> ----- Has To Tag
> Main Route: call [ACK] rU[8x13182] ru[sip:8x13182 at xyz.com]
> fu[sip:9012732009 at xyz.com] tu[sip:8x13182 at xyz.com] si[192.251.125.xx]
> ct[<null>] RPID[<null>]
> ----- Is not REGISTER Request
> ----- Is NAT UAC 19
> ----- Has To Tag
> Main Route: call [ACK] rU[8x13182] ru[sip:8x13182 at xyz.com]
> fu[sip:9012732009 at xyz.com] tu[sip:8x13182 at xyz.com] si[192.251.125.xx]
> ct[<null>] RPID[<null>]
> ----- Is not REGISTER Request
> ----- Is NAT UAC 19
> ----- Has To Tag
> Main Route: call [ACK] rU[8x13182] ru[sip:8x13182 at xyz.com]
> fu[sip:9012732009 at xyz.com] tu[sip:8x13182 at xyz.com] si[192.251.125.xx]
> ct[<null>] RPID[<null>]
> ----- Is not REGISTER Request
> ----- Is NAT UAC 19
> ----- Has To Tag
>
> At the end of the bad call you see a bunch of Main Route logs because the
> SIP proxy is sending the caller "487 Request Terminated" messages and the
> caller is just replying back wiht ACK and its a loop.
>
>
> I can provide my .cfg file, but my main question was is my appending the
> Area Code going against the SIP standards? Should I just not be doing this?
>
>
>
>
> Bogdan-Andrei Iancu wrote:
>
>> Hi,
>>
>> There were some discussion on the list on the topic if a cancelled call
>> should hit the failure route or not, or more technically said, if the
>> "487 request cancelled" should be caught by the failure route or not.
>>
>> The argument for transparently and automatically handle this reply is:
>> if the call was cancelled by the caller, you as a proxy cannot do
>> anything about (like forking) - you have to obey and send back the
>> reply. Right now you have to manually handle this case in failure route
>> via t_was_cancelled() function. So, automatizing this will reduce the
>> complexity of the script (special cases are automatically handled).
>> Anyhow, logically speaking, a caller cancelling should not be translated
>> in a call failure...
>>
>> The only argument against is that you will not be able to log info
>> related to this reply from failure_route - but you can do it from
>> onreply_route. The accounting part will not be affected at all.
>>
>>
>>
>> My question is if somebody uses some tricky configuration where he needs
>> to catch the 487 reply in failure route ?
>>
>>
>> Regards,
>> Bogdan
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
More information about the Users
mailing list