On 01/31/06 23:18, Bogdan-Andrei Iancu wrote:
Hi Medve,
I would say the BYE is badly formatted:
U 2006/01/30 23:28:05.692840 NATBOX:5555 -> OPENSER:6060 BYE sip:imedve3@XLITE SIP/2.0. Route: sip:7741@OPENSER:6060;nat=yes;ftag=1123414629;lr=on. Via: SIP/2.0/UDP 192.168.1.101:5555;branch=z9hG4bKce5c531019c8eec7. From: sip:7741@sip2;tag=1700830800. To: imedve3 sip:imedve3@sip2;tag=1123414629. Call-ID: A412855F-F4E3-470E-AC30-F047AE517CA1@XLITE. CSeq: 1 BYE. User-Agent: Cisco ATA 188 v3.2.0 atasip (041111A). Content-Length: 0.
the FROM hdr is broken - the uri needs to be enclosed between brackets since the tag is a hdr param and not an URI param. The proper format would be:
From: <sip:7741@sip2>;tag=1700830800.
According to RFC, the From header is correctly formated, if the uri in the header is not enclosed in brackets, then the parameters are considered to be header parameters.
In my opinion the problem is that the Xlite puts a different From header value in the 200OK. In the BYE, the from is:
From: sip:7741@sip2;tag=1700830800.
and in 200OK is:
From: sip:7741@sip2;tag=1700830800;tag=1700830800.
I guess that the cisco ata does string comparison of header bodies to match the dialog, instead of the tag value.
Cheers, Daniel
regards, bogdan
Medve Istvan wrote:
Hi List,
I have similar problem what you can read at http://mail.iptel.org/pipermail/serusers/2004-June/008798.html
In my test lab I use openser 1.0.0 with mediaproxy. UAC A is an X-Lite with public IP. UAC B is a Cisco ATA 188 behind a natbox. Usernames are not numericals but I use alias table to resolve username based on CLI. Everything works fine expect one situation.
When X-Lite calls Cisco ATA and call terminated by calee side with BYE, Cisco ATA does not recognize X-lite's 200 OK response and resends BYE message some times.
ATA 188 reports the folowing to syslog:
Jan 30 22:33:29 a 00:02:23 192.168.1.101 [08]:Tags do not match <134>00:02:23 192.168.1.101 [08]:Failed to extract UID from RxMsg
If I replace ATA188 with an ATCOM phone, this sutiation works well.
So the problem is probably with Cisco ATA 188 but I am not sure that is it a real problem or Cisco ATA more sensitive for protocol violation than others or there is a missconfiguratin in nat traversal.
You can find SIP message capture at http://fuhur.euroweb.hu/ata.txt
If you have any ideal please let me know.
Regards, imedve
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users