Hi Scott,
Thanks a lot for this solution. We tested it with a dummy endpoint and it works as mentioned. So for us the first step to solve the problem will be to find out,
why the to-tag is not set in the 200 ok of the real endpoint.
Best regards,
Joerg
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx]
On Behalf Of Scott Godin
Sent: Mittwoch, 5. Oktober 2016 20:59
To: Lehmann, Joerg <Joerg.Lehmann@xxxxxxxx>; resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] Handling of 408 Request Timeout for INFO requests in DUM
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.
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@xxxxxxxxxxxxxxx
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?
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@xxxxxxxxxxxxxxx
List Archive:
http://list.resiprocate.org/archive/resiprocate-users/
|