Subject: Re: [sipcore] #24: Redirect servers

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Oct 2010 17:43:51 -0500

Agreed. We'll fix this.

On Tue, Aug 31, 2010 at 12:37 PM, sipcore issue tracker
<[email-masked]> wrote:
> #24: Redirect servers
> ---------------------------------+------------------------------------------
>  Reporter:  worley@…             |       Owner:
>     Type:  defect               |      Status:  new
>  Priority:  minor                |   Milestone:  milestone1
> Component:  rfc4244bis           |     Version:
>  Severity:  In WG Last Call      |    Keywords:
> ---------------------------------+------------------------------------------
>  In section 4.3, I see:
>
>    A redirect server MUST NOT add any new History-Info entries.
>
>  How would we handle a situation where proxy A, thinking B is a redirect
>  server, sends the request to B which is actually a proxy that sends the
>  request to a redirect server C, which generates a 3xx response, which B
>  passes back to A?  From A's point of view, B looks like a redirect server.
>  But the 3xx that A receives is ultimately generated by C, and its History-
>  Info has one further entry beyond what proxy A would expect to see in a
>  3xx coming from from proxy B (which it believes to be a redirect server).
>  So A would think that B is violating this rule.
>
>  I think the solution to this situation is straightforward:  Remove the
>  above restriction.  The 3xx may have further hi-entry's than A would
>  expect, but they will be labeled as children of the hi-entry representing
>  the request from A to B, and so will not confuse any element that is
>  interpreting the History-Info.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/24>
> sipcore <http://tools.ietf.org/sipcore/>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>