Hi!
I'm not sure, but the ACK has a different branch parameter in the Via
header, than the CANCEL and INVITE. I guess this will cause that openser
wont find the corresponding transaction
klaus
On Wed, February 15, 2006 11:16, unplug said:
Thanks! But I don't really understand why
there is a mismatch between
487and ACK. Below is a part of sip message pair of 487 and ACK.
Below is the complete log from ngrep. (From line 290, openser creates
487 and line 304 UA1 ACK. After that, multiple 487 are created by
openser)
http://meerkat.no-ip.com/openser/cancel_normal.log
Below is my openser.cfg for reference
http://meerkat.no-ip.com/openser/openser.cfg
290 U 203.193.26.226:5060 -> 210.184.23.31:5060
291 SIP/2.0 487 Request Cancelled.
292 Via: SIP/2.0/UDP
10.0.0.46:5060;rport=5060;received=210.184.23.31;branch=z9hG4bKdUyOnG9Zel82UECI.
293 From:
"sip:36418488@o01.ol.com"<sip:871966806561@o01.ol.com>;tag=xLTdFs7yGkeXq3wn.
294 To: "34163634" <sip:34163634@o01.ol.com>;tag=A81AFED4-21D7.
295 Date: Tue, 15 Feb 2005 01:52:57 GMT.
296 Call-ID: Z0wcK4WwdTU6mH00(a)10.0.0.46.
297 Server: Cisco-SIPGateway/IOS-12.x.
298 CSeq: 1 INVITE.
299 Allow-Events: telephone-event.
300 Content-Length: 0.
301 .
302
303 #
304 U 210.184.23.31:5060 -> 203.193.26.226:5060
305 ACK sip:34163634@o01.ol.com SIP/2.0.
306 Via: SIP/2.0/UDP 10.0.0.46:5060;branch=z9hG4bKdUyOnG9Zel82UECI.
307 Route:
<sip:34163634@203.193.26.226:5060;nat=yes;ftag=xLTdFs7yGkeXq3wn;lr=on>.
308 Max-Forwards: 70.
309 User-Agent: Koncept KE10XX v4.32.10 00-09-45-0a-fc-2d.
310 From: "871966806561"
<sip:871966806561@o01.ol.com>;tag=xLTdFs7yGkeXq3wn.
311 To: "34163634" <sip:34163634@o01.ol.com>;tag=A81AFED4-21D7.
312 Call-ID: Z0wcK4WwdTU6mH00(a)10.0.0.46.
313 Contact: <sip:871966806561@10.0.0.46:5060>.
314 CSeq: 1 ACK.
315 Content-Length: 0.
In my openser.cfg line 184-187, it is remarked. Do you mean it should
un-remarked for handling ACK according to your point 2?
On 2/15/06, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
This means that openser does not receive the ACK
or is not able to match
the ACK to the canceled transaction. Thus it is re-transmitting the 487.
Increas the debug level and take a look at the syslog to find out if:
1. the ACK to the 487 is received by openser
2. if it is received, check if there is a problem during handling of the
ACK. (for these kind of ACKs just t_relay()).
klaus
On Wed, February 15, 2006 5:13, unplug said:
For the normal cancel situation.
UA1 OPENSER UA2
--------INVITE----------------->
<-----------100-----------------
--------------------INVITE---------->
<---------------100-------------------
----------CANCEL---------->
--------------CANCEL------------->
<--------------200------------------
<------------487-------------------
--------------ACK----------------->
<---------487---------------
-------------ACK------------>
But in my case, I found that there are many 487 created from openser
to UA1. The multiple 487 may cause a call drop in the following call.
Why does openser create so many 487 for UA1? How can I prevent it?
UA1 OPENSER UA2
--------INVITE----------------->
<-----------100-----------------
--------------------INVITE---------->
<---------------100-------------------
----------CANCEL---------->
--------------CANCEL------------->
<--------------200------------------
<------------487-------------------
--------------ACK----------------->
<---------487---------------
-------------ACK------------>
<---------487-------------
-------------ACK------------>
<---------487---------------
-------------ACK------------>
<---------487-------------
-------------ACK------------>
<---------487-------------
-------------ACK------------>
<---------487-------------
-------------ACK------------>
<---------487-------------
-------------ACK------------>
...
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users