Re: [reSIProcate] 439 response to REGISTER in Resip 1.8.5

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

I agree this is a bug.

Please try out the following change to ServerRegistration::testFlowRequirements:

bool 

ServerRegistration::testFlowRequirements(ContactInstanceRecord &rec,

                                          const resip::SipMessage& msg,

                                          bool hasFlow) const

{

   const resip::NameAddr& contact(rec.mContact);

   if(!mRequestContext.getOriginalRequest().empty(h_Supporteds) &&

      mRequestContext.getOriginalRequest().header(h_Supporteds).find(Token(Symbols::Outbound)) &&

      contact.exists(p_Instance) && 

      contact.exists(p_regid))

   {

      // Client has explicitly requested Outbound processing, which requires us 

      // to have a flow.

      if(!hasFlow)

      {

         SharedPtr<SipMessage> failure(new SipMessage);

         mDum.makeResponse(*failure, msg, 439);

         mDum.send(failure);

         return false;

      }

   }

....

Note:  The outbound drafts have more towards full RFC status now.  RFC 5626 (http://tools.ietf.org/html/rfc5626).

Scott

On Wed, Aug 22, 2012 at 8:31 PM, Mike Hubbard <mike.hubbard@xxxxxxx> wrote:

It appears in Resip 1.8.5 that if a UAC sends a REGISTER with a reg-id parameter in the contact header and branched via, the stack responds with a 439, despite the REGISTER not containing a Supported header advertising support of the “outbound” feature.  Based on my reading of the draft http://tools.ietf.org/html/draft-ietf-sip-outbound-16 in sections 6 and 11.6, it seems that this is an incorrect response.  The draft seems to indicate that a 439 should only be sent if the REGISTER message contains the reg-id parameter AND the outbound option tag. 

 

Has anyone else experienced problems with this?

 

Mike

 

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel