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>