[Serusers] Claims of ser-0.9 RFC3261 Violation

Java Rockx javarockx at gmail.com
Wed Mar 2 20:34:52 CET 2005


Here's one more update.

I don't know why things are this way, but when I use the fix_contact()
function in the mediaproxy.so module, it does not appear to properly
fix the contact header.

So I changed all fix_contact() references to fix_nated_contact() from
the nathelper.so module and now everything seems to work.

So what exactly does fix_contact() in mediaproxy.so do?

Regards,
Paul


On Wed, 2 Mar 2005 14:01:12 -0500, Java Rockx <javarockx at gmail.com> wrote:
> Perhaps I jumped the gun here. My WorldAccxx IAD now keeps its
> registration updated, but now since I've called fix_nated_register()
> rather than fix_nated_contact() in my REGISTER message handler I
> cannot call phones that are NATed on different networks.
> 
> I see in the location table in MySQL that the Contact column has the
> value that came in with the REGISTER message and the Received column
> has the NATed public IP and port number.
> 
> So what is the trick to fixing NATed contacts when handling INVITE messages?
> 
> Right now I'm calling force_rport() and fix_contact() prior to
> lookup("location")
> 
> Regards,
> Paul
> 
> On Wed, 2 Mar 2005 13:44:19 -0500, Java Rockx <javarockx at gmail.com> wrote:
> > 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
> > >
> > >
> > >
> >
>




More information about the sr-users mailing list