Ok I've done some testing and you are right about the area code stuff not
having anything to do with my CANCEL issues. I think my issue is the DOMAIN
part of the RURI that is being sent to the SIP Trunk provider.
I can start up a new thread if I need to, but here is what I am seeing...
So my box is Multi-Domain and for testing purposes the irock.com domain is
used for one of the users (I don't own irock.com I am just using that for
testing). When 9x12x32...@irock.com calls 9x18x13182 the call goes through
my Route[4] which I posted above. So the invite that gets sent out to my
SIP Trunk provider is this
U 6x.80.xxx.14:5060 -> 64.2.142.93:5060
INVITE sip:9x18x13...@irock.com SIP/2.0.
Record-Route: <sip:6x.80.xxx.14;lr=on;ftag=2f27602c;nat=yes;did=535.18b17>.
Via: SIP/2.0/UDP 6x.80.xxx.14;branch=z9hG4bK0de8.b68a49e7.0.
Via: SIP/2.0/UDP
192.168.100.80:22894;received=192.251.125.xx;branch=z9hG4bK-d8754z-02edb391ba5fad01-1---d8754z-;rport=10076.
Max-Forwards: 69.
Contact: <sip:9x12x32...@192.251.125.xx:10076;transport=udp>.
To: <sip:19x18x13...@irock.com>.
From: "Duane"<sip:9x12x32...@irock.com>;tag=2f27602c.
Call-ID: OTkwYTc4MjY0NTU0NjFhMGU2YjgxNDQ5N2JjYjg5YmE..
CSeq: 2 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO.
Content-Type: application/sdp.
User-Agent: Bria release 2.5.4 stamp 53956.
Content-Length: 258.
P-hint: route(3)|setflag7,forcerport,fix_contact.
P-hint: inbound->outbound .
P-hint: Route[6]: mediaproxy .
.
v=0.
o=- 9 2 IN IP4 192.168.100.80.
s=CounterPath Bria.
c=IN IP4 6x.80.xxx.13.
t=0 0.
m=audio 10854 RTP/AVP 107 0 8 18 101.
a=sendrecv.
a=rtpmap:107 BV32/16000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=yes.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
I think the issue is the domain part in the INVITE part of that SIP message
(INVITE sip:9018313...@irock.com SIP/2.0.) because when the softphone user
9x12x32...@irock.com cancels the call I see the following SIP messages
U 192.251.125.xx:10076 -> 6x.80.xxx.14:5060
CANCEL sip:19x18x13...@irock.com SIP/2.0.
Via: SIP/2.0/UDP
192.168.100.80:22894;branch=z9hG4bK-d8754z-02edb391ba5fad01-1---d8754z-;rport.
Max-Forwards: 70.
To: <sip:19x18x13...@irock.com>.
From: "Duane"<sip:9x12x32...@irock.com>;tag=2f27602c.
Call-ID: OTkwYTc4MjY0NTU0NjFhMGU2YjgxNDQ5N2JjYjg5YmE..
CSeq: 2 CANCEL.
Proxy-Authorization: Digest
username="9x12x32009",realm="irock.com",nonce="4acfa38a0000000243e104b0d51fed793230657dae910da5",uri="si
p:19x18x13...@irock.com",response="7364463734bed01be73dc4cd92742fc1",cnonce="2f2d71fe87bfdcd1325e1cb15210d1ef",nc=00000002,qop=auth,
algorithm=MD5.
User-Agent: Bria release 2.5.4 stamp 53956.
Content-Length: 0.
.
U 6x.80.xxx.14:5060 -> 192.251.125.xx:10076
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP
192.168.100.80:22894;branch=z9hG4bK-d8754z-02edb391ba5fad01-1---d8754z-;rport=10076;received=192.251.125.xx.
To: <sip:19x18x13...@irock.com>;tag=d733b86164332c9143cd163ddc2dfbf1-6635.
From: "Duane"<sip:9x12x32...@irock.com>;tag=2f27602c.
Call-ID: OTkwYTc4MjY0NTU0NjFhMGU2YjgxNDQ5N2JjYjg5YmE..
CSeq: 2 CANCEL.
Server: Aethercommunications SIP Proxy.
Content-Length: 0.
.
U 6x.80.xxx.14:5060 -> 192.251.125.xx:10076
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP
192.168.100.80:22894;branch=z9hG4bK-d8754z-02edb391ba5fad01-1---d8754z-;rport=10076;received=192.251.125.xx.
To: <sip:19x18x13...@irock.com>;tag=d733b86164332c9143cd163ddc2dfbf1-6635.
From: "Duane"<sip:9x12x32...@irock.com>;tag=2f27602c.
Call-ID: OTkwYTc4MjY0NTU0NjFhMGU2YjgxNDQ5N2JjYjg5YmE..
CSeq: 2 INVITE.
Server: Aethercommunications SIP Proxy.
Content-Length: 0.
.
U 192.251.125.xx:10076 -> 6x.80.xxx.14:5060
ACK sip:19x18x13...@irock.com SIP/2.0.
Via: SIP/2.0/UDP
192.168.100.80:22894;branch=z9hG4bK-d8754z-02edb391ba5fad01-1---d8754z-;rport.
Max-Forwards: 70.
To: <sip:19x18x13...@irock.com>;tag=d733b86164332c9143cd163ddc2dfbf1-6635.
From: "Duane"<sip:9x12x32...@irock.com>;tag=2f27602c.
Call-ID: OTkwYTc4MjY0NTU0NjFhMGU2YjgxNDQ5N2JjYjg5YmE..
CSeq: 2 ACK.
Content-Length: 0.
.
U 6x.80.xxx.14:5060 -> 192.251.125.xx:10076
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP
192.168.100.80:22894;branch=z9hG4bK-d8754z-02edb391ba5fad01-1---d8754z-;rport=10076;received=192.251.125.xx.
To: <sip:19x18x13...@irock.com>;tag=d733b86164332c9143cd163ddc2dfbf1-6635.
From: "Duane"<sip:9x12x32...@irock.com>;tag=2f27602c.
Call-ID: OTkwYTc4MjY0NTU0NjFhMGU2YjgxNDQ5N2JjYjg5YmE..
CSeq: 2 INVITE.
Server: Aethercommunications SIP Proxy.
Content-Length: 0.
So my SIP Proxy is never telling the SIP Trunk provider that a CANCEL was
issued. The domain part of the INVITE has to be the issue because if I add
the following command to my Route[4] block
rewritehostport("pt1.vitelity.net:5060");
It fixes the CANCEL issue but breaks the BYE SIP message from the PSTN user
And if I change the rewritehostport to the following
rewritehostport("IP Address of my Proxy:5060");
it fixes the CANCEL issue but breaks the BYE SIP message from the Softphone
user.
The other problem I am seeing because of the domain issue is that when
9x12x32...@irock.com calls someone an INVITE is not only sent to my SIP
Trunk provider but also to 97.74.144.17:5060 which is the IP address that
irock.com resolves too. How can I keep this from happening?
Bogdan-Andrei Iancu wrote:
>
> 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)\...@\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:9x18x13...@64.2.142.75]
>> fu[sip:9x12x32...@irock.com] tu[sip:8x13...@irock.com] si[192.251.125.xx]
>> ct[<sip:9x12x32...@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:9x12x32...@irock.com] tu[sip:8x13...@irock.com] si[192.251.125.xx]
>> ct[<sip:9x12x32...@192.168.100.80:14106;transport=udp>]
>> On Reply Route 1: call [BYE] rU[<null>] ru[<null>]
>> fu[sip:9x12x32...@irock.com] tu[sip:8x13...@irock.com] si[64.2.142.93]
>> ct[<sip:9x18x13...@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:8x13...@xyz.com]
>> fu[sip:9012732...@xyz.com] tu[sip:8x13...@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:9x18x13...@xyz.com]
>> fu[sip:9x12x32...@xyz.com] tu[sip:8x13...@xyz.com] si[192.251.125.xx]
>> ct[<sip:9x12x32...@192.168.100.80:14106;transport=udp>]
>> ----- Inside Failure Route 1
>> BEGIN: SIP message [INVITE] - To URI username=[sip:8x13...@xyz.com] From
>> URI=[sip:9x18x13...@xyz.com]
>> Main Route: call [ACK] rU[8x13182] ru[sip:8x13...@xyz.com]
>> fu[sip:9012732...@xyz.com] tu[sip:8x13...@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:8x13...@xyz.com]
>> fu[sip:9012732...@xyz.com] tu[sip:8x13...@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:8x13...@xyz.com]
>> fu[sip:9012732...@xyz.com] tu[sip:8x13...@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:8x13...@xyz.com]
>> fu[sip:9012732...@xyz.com] tu[sip:8x13...@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@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
>
>
--
View this message in context:
http://n2.nabble.com/Inquiry-487-Request-Cancelled-processing-tp3056235p3797421.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
