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.
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
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
2010/11/23 Alex Balashov abalashov@evaristesys.com:
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.
I expect Kamailio just matches the Via branch, and not the Totag, am I wrong?
2010/11/23 Iñaki Baz Castillo ibc@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?
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).
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.
2010/11/24 Alex Balashov abalashov@evaristesys.com:
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.
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).
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 ;)
2010/12/1 Mikko Lehto mikko.lehto@setera.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@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 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
2010/12/1 Mikko Lehto mikko.lehto@setera.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.
-
Alex Balashov -
Iñaki Baz Castillo -
Klaus Darilion -
Mikko Lehto