[OpenSIPS-Users] [Inquiry] 487 Request Cancelled processing

osiris123d duane.larson at gmail.com
Fri Oct 9 00:33:44 CEST 2009


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
> 
> 

-- 
View this message in context: http://n2.nabble.com/Inquiry-487-Request-Cancelled-processing-tp3056235p3791202.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.



More information about the Users mailing list