Re: [reSIProcate-users] Handling of 408 Request Timeout for INFO requests in DUM

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Joerg,

After examining your log file, I see why this is happening.  The 200 response from the far end is missing the To tag.  This must be an old RFC2543 implementation, I've never run across an endpoint that doesn't provide a to tag in the 200 response to date, which is why you are probably the first to notice this.  This is causing the INFO to go out without a to tag, and the resulting internally generated 408 to fabricate a to tag and not match the "to-tag"less Dialog correctly.

Seems we are not correctly handling RFC2543 backwards compatibility support correctly with internally generated responses.  

From RFC3261

A UAC MUST be prepared to receive a response without a tag in the To
field, in which case the tag is considered to have a value of null.

This is to maintain backwards compatibility with RFC 2543, which
did not mandate To tags.

I believe I found the code that is inserting the To tag into the 408 response and there are comments in it, that indicate some confusion as to whether we should be adding it or not.  Check out Helper.cxx makeResponse (near line 391):

if(responseCode > 100 && 
   response.const_header(h_To).isWellFormed() &&
      !
   response.const_header(h_To).exists(p_tag)) 
{

    // Only generate a To: tag if one doesn't exist.  Think Re-INVITE. 
    // No totag for failure responses or 100s 
    // ?bwc? Should we be generating to-tags for failure responses or not?

    // The comments say no, but the code says yes. Which is it?

   response.header(h_To).param(p_tag) = Helper::computeTag(Helper::tagSize); 
 }

I don't really understand the comment about Re-INVITE's.  More research into the "correct" behaviour here would be required to understand the correct fix.  If anyone has an opinion on this, please chime in.  In the meantime, you could try just removing this block and seeing if everything is still working.

Scott

On Wed, Oct 5, 2016 at 10:46 AM, Lehmann, Joerg <Joerg.Lehmann@xxxxxxxx> wrote:

Hi Scott,

 

Thanks for your reply.

 

I attached a log file which I created on STACK level. In row 447 we send an info request to a destination which does not answer. For this reason, the stack creates a 408 Request Timeout (row 540). The problem is, that this timeout message cannot be assigned to the invite session dialog (row 568). Therefore we can’t handle this message in the InviteSessionHandler.

 

Best regards,

Joerg

 

From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Freitag, 30. September 2016 18:16
To: Lehmann, Joerg <Joerg.Lehmann@xxxxxxxx>
Cc: resiprocate-users@resiprocate.org
Subject: Re: [reSIProcate-users] Handling of 408 Request Timeout for INFO requests in DUM

 

Hi Joerg,

 

I can't imagine why this would be intended.  Can you please share a DEBUG level, so I can see if I can figure out what's going on?

 

Thanks,

Scott

 

On Mon, Sep 26, 2016 at 11:33 AM, Lehmann, Joerg <Joerg.Lehmann@xxxxxxxx> wrote:

Hi,

 

When I send an INFO request to the UAS and get no answer, I would expect, that the onInfoFailure method in the InviteSessionHandler is called. But as far as I can see, an internal response 408 Request Timeout is created which is not handled by the DUM. The reason for this seems to be that the corresponding dialog is not found with the new generated remoteTagId.

 

Is this behavior intended?

 

Thanks,

Joerg

_______________________________________________
resiprocate-users mailing list
resiprocate-users@resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/