Problem with t_check_trans()

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with t_check_trans()

Carlo Dimaggio
Hi all,

I have a problem with the following configuration and the  
t_check_trans() function:

userA -> Asterisk -> Opensips -> userB

In detail, if userA calls userB and then userA sends CANCEL,  
t_check_trans doesn't recognize the transaction.
I would like to know how t_check_trans matches the transaction (which  
headers?).
With another client (instead of Asterisk) all works fine.

Thank you,
Carlo Dimaggio



1) In my opensips.cfg I have:

     # CANCEL processing
     if (is_method("CANCEL")) {
         if (t_check_trans()) {
              xlog ("L_INFO", "Cancel Session - M=$rm RURI=$ru F=$fu T=
$tu IP=$si ID=$ci\n");
              route(1);
         };
         exit;
     }

route[1] {
     #
     # --- FORWARD REQUEST TO TARGET
     #
     # Forward statefully

     xlog ("L_INFO", "Forward request to target - M=$rm RURI=$ru F=$fu  
T=$tu IP=$si ID=$ci\n");
     t_on_reply("1");
     t_on_failure("1");
     if (!t_relay()) {
         sl_reply_error();
     };
     exit;
}



2) The ngrep is:

U 10.0.6.101:5060 -> 10.0.6.1:5060
INVITE sip:1000@opensips SIP/2.0.
Via: SIP/2.0/UDP 10.0.6.101:5060;branch=z9hG4bK765f9c34;rport.
From: "1005" <sip:1005@opensips>;tag=as44c8623d.
To: <sip:1000@opensips>.
Contact: <sip:1005@10.0.6.101>.
Call-ID: 59f29a0e0b415eb8208902334bcfe302@opensips.
CSeq: 103 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Proxy-Authorization: Digest username="1005", realm="opensips",  
algorithm=MD5, uri="sip:1000@opensips",  
nonce="49bfb4ee00000064a87d5b8f0656c0b2ac4ff80e64bebff0",  
response="137b777f01625c5e28f50f9972d2c23c", qop=auth,  
cnonce="6d2606c0", nc=00000001.
Date: Tue, 17 Mar 2009 14:33:57 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 258.
.
v=0.
o=root 4614 4615 IN IP4 10.0.6.101.
s=session.
c=IN IP4 10.0.6.101.
t=0 0.
m=audio 15694 RTP/AVP 0 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

U 10.0.6.101:5060 -> 10.0.6.1:5060
CANCEL sip:1000@opensips SIP/2.0.
Via: SIP/2.0/UDP 10.0.6.101:5060;branch=z9hG4bK63d5b445;rport.
From: "1005" <sip:1005@opensips>;tag=as44c8623d.
To: <sip:1000@opensips>.
Call-ID: 59f29a0e0b415eb8208902334bcfe302@opensips.
CSeq: 103 CANCEL.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Content-Length: 0.

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Problem with t_check_trans()

Alex Hermann
On Tuesday 17 March 2009 15:51:40 Carlo Dimaggio wrote:
> userA -> Asterisk -> Opensips -> userB
>
> In detail, if userA calls userB and then userA sends CANCEL,
> t_check_trans doesn't recognize the transaction.

Asterisk messed things up again. This time they decided that the branch
parameter wouldn't matter in a CANCEL. In 1.4.24 there is a fix.

> INVITE sip:1000@opensips SIP/2.0.
> Via: SIP/2.0/UDP 10.0.6.101:5060;branch=z9hG4bK765f9c34;rport.

> CANCEL sip:1000@opensips SIP/2.0.
> Via: SIP/2.0/UDP 10.0.6.101:5060;branch=z9hG4bK63d5b445;rport.

--
Alex Hermann


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users