It is the same. Their IAD successfully registers the first time, but
loses its registration because re-REGISTER messages are claimed to be
in voliation of RFC3261.
Here is exactly what their engineers are telling me:
Paul,
Here is the my findings regarding the contact field in the
REGISTER message...
We suspect the registration fails because the Contact of 200OK does
not match the Contact of REGISTER:
From the capture, Our network toplogy is like:
TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch
64.84.242.120
Packet 4 REGISTER:
Contact: <sip:3212514276@192.168.0.180;user=phone>;expires=200
Packet 6 200OK:
Contact: <sip:3212514276@65.77.37.2:36323;user=phone>;expires=200,
<sip:3212514276@65.77.37.2:36235;user=phone>;expires=3
In RFC3261, it says:
The 200 (OK) response from the registrar contains a list of Contact
fields enumerating all current bindings. The UA compares each
contact address to see if it created the contact address, using
comparison rules in Section 19.1.4. If so, it updates the expiration
time interval according to the expires parameter or, if absent, the
Expires field value. The UA then issues a REGISTER request for each
of its bindings before the expiration interval has elapsed. It MAY
combine several updates into one REGISTER request.
So obviously the contact addresses in 200OK don't match the one in REGISTER.
On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev <vitaly(a)voipsonic.com> wrote:
Is contact field that SER sends to UAS is same for all
requests ?
If not probably you are not doing fix natted contact in some cases
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Java Rockx
Sent: Wednesday, March 02, 2005 11:17 AM
To: serusers(a)lists.iptel.org
Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation
I just spoke with an enginee from a manufacturer of the WorldAccxx
telephone adapter and he told me that my SIP proxy was in voliation of
RFC3261.
Below is a SIP registration against my ser-0.9 proxy. I'm using media
proxy for NAT traversal and he says that my 200 OK is not valid and
therefore their IAD disregards the 200 OK response.
The problem he claims is with the <Contact:> header in the 200 OK. SER
has rewritten the contact becase his IAD is NATed. Should I not be
doing this?
The actual problem is that when their IAD is NATed the device looses
its registration with ser because (they claim) that the REGISTER
message they send has a <Contact> header iwith a different IP than
what ser sends back in the 200 OK message.
They referenced section 10.2.4 and 19.1.4 in RFC3261.
Can anyone confirm or reject their claims?
Please help.
Paul
REGISTER sip:sip.mycompany.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d
Max-Forwards: 70
Content-Length: 0
To: Accxx <sip:1000@sip.mycompany.com:5060>
From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92
Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180
CSeq: 392547129 REGISTER
Contact: Accxx <sip:1000@192.168.0.180;user=phone>;expires=200
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2
To: Accxx <sip:1000@sip.mycompany.com:5060>
From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92
Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180
CSeq: 392547129 REGISTER
Content-Length: 0
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2
To: Accxx
<sip:1000@sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1.bdad
From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92
Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180
CSeq: 392547129 REGISTER
WWW-Authenticate: Digest realm="sip.mycompany.com",
nonce="42025161902f6f6af11f01f0a93ad2877e606bbc"
Content-Length: 0
REGISTER sip:sip.mycompany.com:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76
Max-Forwards: 70
Content-Length: 0
To: Accxx <sip:1000@sip.mycompany.com:5060>
From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92
Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180
CSeq: 392547130 REGISTER
Contact: Accxx <sip:1000@192.168.0.180;user=phone>;expires=200
Allow: NOTIFY
Allow: REFER
Allow: OPTIONS
Allow: INVITE
Allow: ACK
Allow: CANCEL
Allow: BYE
Authorization:Digest
response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip.mycom
pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:sip.myco
mpany.com:5060"
User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2
To: Accxx <sip:1000@sip.mycompany.com:5060>
From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92
Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180
CSeq: 392547130 REGISTER
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2
To: Accxx
<sip:1000@sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1.5e63
From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92
Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180
CSeq: 392547130 REGISTER
Contact: <sip:1000@65.77.37.2:36323;user=phone>;expires=200,
<sip:1000@65.77.37.2:36235;user=phone>;expires=3
Content-Length: 0
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers