1 Feb
2006
1 Feb
'06
10:19 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users