23 Nov
2010
23 Nov
'10
7:59 p.m.
Hi, Samsung PBX's generate a wrong CANCEL:
- It contains To tag !!!
- It contains "application/sdp" mirroring the SDP of the 183 received !!!
Really ugly. Actually those CANCEL's are being rejected by my
kamailio (403) as they contain Totag but no Route header.
So, as a workaround, I will move the section of CANCEL before the
loose-routing section. I expect it will work, but I would like to be
sure that Kamailio (1.5) will not react due to the Totag of the CANCEL
(it shouldn't IMHO as the Totag has no relationship with the INVITE
transaction being cancelled).
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
23 Nov
23 Nov
8:12 p.m.
Am 23.11.2010 18:59, schrieb Iñaki Baz Castillo:
Hi, Samsung PBX's generate a wrong CANCEL:
- It contains To tag !!!
- It contains "application/sdp" mirroring the SDP of the 183 received !!!
Really ugly. Actually those CANCEL's are being rejected by my
kamailio (403) as they contain Totag but no Route header.
So, as a workaround, I will move the section of CANCEL before the
loose-routing section. I expect it will work, but I would like to be
sure that Kamailio (1.5) will not react due to the Totag of the CANCEL
(it shouldn't IMHO as the Totag has no relationship with the INVITE
transaction being cancelled).
I guess you have to try to find out if CANCEL matching in TM module does
look at totag or not.
regards
Klaus
8:14 p.m.
Iñaki,
On 11/23/2010 12:59 PM, Iñaki Baz Castillo wrote:
Really ugly. Actually those CANCEL's are being
rejected by my
kamailio (403) as they contain Totag but no Route header.
Are you saying that if not for this security check, Kamailio would match
the CANCELs to the INVITE transaction to which they are intended to
correspond?
This should not happen; in order for CANCELs to be matched, they must
have the same attributes, tag-wise, as the initial INVITE to which they
correspond.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street NE
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
8:18 p.m.
2010/11/23 Alex Balashov <abalashov(a)evaristesys.com>om>:
I expect Kamailio just matches the Via branch, and not the Totag, am I wrong?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Really ugly.
Actually those CANCEL's are being rejected by my
kamailio (403) as they contain Totag but no Route header.
Are you saying that if not for this security check, Kamailio would match the
CANCELs to the INVITE transaction to which they are intended to correspond?
This should not happen; in order for CANCELs to be matched, they must have
the same attributes, tag-wise, as the initial INVITE to which they
correspond.
24 Nov
24 Nov
5:36 p.m.
2010/11/23 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
It works as I expected:
- The CANCEL arrives to Kamailio (1.5) with Totag (bug in UAC).
- Kamailio does t_relay() for the CANCEL without checking
loose-routing or Totag (CANCEL threatment is now above loose-routing
section).
- Kamailio replies 200 to the CANCEL and generates its own CANCEL (of
course with no Totag).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
This should
not happen; in order for CANCELs to be matched, they must have
the same attributes, tag-wise, as the initial INVITE to which they
correspond.
I expect Kamailio just matches the Via branch, and not the Totag, am I wrong?
7:11 p.m.
On 11/24/2010 10:36 AM, Iñaki Baz Castillo wrote:
It works as I expected:
- The CANCEL arrives to Kamailio (1.5) with Totag (bug in UAC).
- Kamailio does t_relay() for the CANCEL without checking
loose-routing or Totag (CANCEL threatment is now above loose-routing
section).
- Kamailio replies 200 to the CANCEL and generates its own CANCEL (of
course with no Totag).
It seems to me that this should not work here if Kamailio were being
properly strict.
As per RFC 3261 Section 9.1, "Client Behavior" in "Canceling a Request:
The Request-URI, Call-ID, To, the numeric part of CSeq, and
From header fields in the CANCEL request MUST be identical to
those in the request being cancelled, including tags.
If the initial INVITE did not have a To tag (which, it of course,
doesn't), neither should the CANCEL. Otherwise, this CANCEL should not
be matched.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street NE
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
8:13 p.m.
2010/11/24 Alex Balashov <abalashov(a)evaristesys.com>om>:
On 11/24/2010 10:36 AM, Iñaki Baz Castillo wrote:
I know, sure. This is a bug in the UAC. I have done a workaround in
Kamailio. And as I expected, Kamailio doesn't care the existence or
not of a Totag, it just matches the INVITE transaction by inspecting
the Via branch (which allows my workaround).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
It works as I expected:
- The CANCEL arrives to Kamailio (1.5) with Totag (bug in UAC).
- Kamailio does t_relay() for the CANCEL without checking
loose-routing or Totag (CANCEL threatment is now above loose-routing
section).
- Kamailio replies 200 to the CANCEL and generates its own CANCEL (of
course with no Totag).
It seems to me that this should not work here if Kamailio were being
properly strict.
As per RFC 3261 Section 9.1, "Client Behavior" in "Canceling a Request:
The Request-URI, Call-ID, To, the numeric part of CSeq, and
From header fields in the CANCEL request MUST be identical to
those in the request being cancelled, including tags.
If the initial INVITE did not have a To tag (which, it of course, doesn't),
neither should the CANCEL. Otherwise, this CANCEL should not be matched. 
1 Dec
1 Dec
3:17 p.m.
Hi Iñaki
We tried to reproduce the Samsung behavior you recently described.
My observation is that the CANCEL, which was generated after the received
provisional response (183 with SDP), has no To tag nor SDP body.
According to local Samsung representative, the tested model and version is
OfficeServ 7100 4.48e and same software is used also in models 7000,
7030, 7200 and 7400.
Do you have similar device? Any other hints how we could reproduce this?
I am asking this because we want to avoid the workaround you kindly
reported and it looks like the vendor is able to fix reported issues.
At least during the initial tests before green light for deployment ;)
--
Mikko Lehto
3:40 p.m.
2010/12/1 Mikko Lehto <mikko.lehto(a)setera.fi>fi>:
Hi Iñaki
We tried to reproduce the Samsung behavior you recently described.
My observation is that the CANCEL, which was generated after the received
provisional response (183 with SDP), has no To tag nor SDP body.
According to local Samsung representative, the tested model and version is
OfficeServ 7100 4.48e and same software is used also in models 7000,
7030, 7200 and 7400.
Do you have similar device? Any other hints how we could reproduce this?
I am asking this because we want to avoid the workaround you kindly
reported and it looks like the vendor is able to fix reported issues.
At least during the initial tests before green light for deployment ;)
I've asked the client about model and version of his Samsung. I'll
tell it to you when I get it.
This is a CANCEL generated by such PBX:
CANCEL sip:XXX533633@XXX.XXX.32.177:6060 SIP/2.0'
From:
<sip:XXX050402@XXX.XXX.32.177:5060>;tag=c0a80165-13c4-80eae-1f79584b-57c22399'
To: <sip:XXX533633@XXX.XXX.32.177:6060>;tag=3d69a021-co3158-INS001'
Call-ID: eae804-c0a80165-13c4-80eae-1f79584a-6f05d2e3(a)212.230.32.177'
CSeq: 1 CANCEL'
Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK-80eae-1f79584c-65d7f65e'
Max-Forwards: 70'
Supported: 100rel,replaces'
Content-Type: application/SDP'
Content-Length: 244'
'
v=0'
o=- 1030332449 1030332449 IN IP4 XXX.XXX.5.228'
s=ENSResip'
c=IN IP4 XXX.XXX.32.178'
t=0 0'
m=audio 31274 RTP/AVP 8 101'
a=fmtp:101 0-11'
a=ptime:20'
a=rtpmap:8 PCMA/8000'
a=rtpmap:101 telephone-event/8000'
a=sendrecv'
a=nortpproxy:yes'
The SDP is the same as the received by the PBX in the 183.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:05 p.m.
Iñaki Baz Castillo wrote:
I've asked the client about model and version of
his Samsung. I'll
tell it to you when I get it.
OK, thanks!
For the record, here is the CANCEL we captured:
CANCEL sip:+3589XXXXXXXX@proxy.siplab.fi:5060;user=phone SIP/2.0
From:
<sip:+3589XXXXXXXX@XXX.FI:5060;user=phone>;tag=13a7588-26fb446d-13c4-50017-4cf664e7-12afeb6a-4cf664e7
To: <sip:+3589XXXXXXXX@proxy.siplab.fi:5060;user=phone>
Call-ID: 13a9ff0-26fb446d-13c4-50017-4cf664e7-288b990c-4cf664e7
CSeq: 1 CANCEL
Via: SIP/2.0/UDP 89.18.XXX.XXX:5060;rport;branch=z9hG4bK-4cf664e7-a27a29d2-2d80c774
Max-Forwards: 70
Supported: replaces
User-Agent: Samsung OfficeServ
Content-Length: 0
--
Mikko Lehto
4:27 p.m.
2010/12/1 Mikko Lehto <mikko.lehto(a)setera.fi>fi>:
Iñaki Baz Castillo wrote:
> I've asked the client about model and version of his Samsung. I'll
> tell it to you when I get it.
This is the Samsung model in which I've detected the bug:
OfficeServ 7200 with firmware 4.40.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5107
days inactive
5115
days old
11 comments
4 participants
participants (4)
-
Alex Balashov -
Iñaki Baz Castillo -
Klaus Darilion -
Mikko Lehto