[Serusers] Claims of ser-0.9 RFC3261 Violation

Wed Mar 2 17:40:28 CET 2005

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 at 192.168.0.180;user=phone>;expires=200

Packet 6 200OK:
Contact: <sip:3212514276 at 65.77.37.2:36323;user=phone>;expires=200,
<sip:3212514276 at 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 at 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 at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
> Behalf Of Java Rockx
> Sent: Wednesday, March 02, 2005 11:17 AM
> To: serusers at 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 at sip.mycompany.com:5060>
> From: Accxx <sip:1000 at sip.mycompany.com:5060>;tag=1eb7db0b344ac92
> Call-ID: bd4da0ebfe98297597243a92b1b0f868 at 192.168.0.180
> CSeq: 392547129 REGISTER
> Contact: Accxx <sip:1000 at 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 at sip.mycompany.com:5060>
> From: Accxx <sip:1000 at sip.mycompany.com:5060>;tag=1eb7db0b344ac92
> Call-ID: bd4da0ebfe98297597243a92b1b0f868 at 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 at sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1.bdad
> From: Accxx <sip:1000 at sip.mycompany.com:5060>;tag=1eb7db0b344ac92
> Call-ID: bd4da0ebfe98297597243a92b1b0f868 at 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 at sip.mycompany.com:5060>
> From: Accxx <sip:1000 at sip.mycompany.com:5060>;tag=1eb7db0b344ac92
> Call-ID: bd4da0ebfe98297597243a92b1b0f868 at 192.168.0.180
> CSeq: 392547130 REGISTER
> Contact: Accxx <sip:1000 at 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 at sip.mycompany.com:5060>
> From: Accxx <sip:1000 at sip.mycompany.com:5060>;tag=1eb7db0b344ac92
> Call-ID: bd4da0ebfe98297597243a92b1b0f868 at 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 at sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1.5e63
> From: Accxx <sip:1000 at sip.mycompany.com:5060>;tag=1eb7db0b344ac92
> Call-ID: bd4da0ebfe98297597243a92b1b0f868 at 192.168.0.180
> CSeq: 392547130 REGISTER
> Contact: <sip:1000 at 65.77.37.2:36323;user=phone>;expires=200,
> <sip:1000 at 65.77.37.2:36235;user=phone>;expires=3
> Content-Length: 0
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
>