[Serusers] Claims of ser-0.9 RFC3261 Violation

Wed Mar 2 19:44:19 CET 2005

Hi All.

Thanks to Vitaly for the answer to the question. I didn't even realize
there was a fix_nated_contact() function.

So for anyone else with this problem, I'm now calling force_rport()
and fix_nated_contact() before save("location") when processing
REGISTER messages.

I'm still using fix_nated_contact() in the reply route and before
relaying INVITE messages.

Many thanks Vitaly.

Paul

On Wed, 2 Mar 2005 10:16:08 -0800, Linda Xiao
<linda.xiao at arkonnetworks.com> wrote:
>  
> You are not the only service provider who makes this kind of changes. I also
> encountered the same problem recently. But so far, this problem only
> happened on one UA which has the same sip engine as this engineer's. All
> other UAs in my hand can adapt this kinds of changes. So I personally think
> that instead of complaining SIP proxy violation, I would rather complain the
> interoperatibility of this sip engine. 
>   
> regards/Linda 
> 
> 
>  
> 
> 
> -----Original Message-----
> From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
> Behalf Of Klaus Darilion
> Sent: Wednesday, March 02, 2005 9:37 AM
> To: Java Rockx
> Cc: serusers at lists.iptel.org
> Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
> 
> 
> I guess the engineer is right. Thus, I use fix_nated_register() instead
> of fix_nated_contact which does not rewrite the contact header.
> 
> regards,
> klaus
> 
> 
> Java Rockx wrote:
> 
> > 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
> >>
> >>
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
>