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

From: "Elwell, John" <[email-masked]>
Date: Wed, 1 Sep 2010 09:26:07 +0200

I agree with this. A redirect server could internally retarget from B to C and then redirect from C to D. Since we encourage proxies to generate hi-entries for their internal retargets, shouldn't we allow redirect servers to do the same?

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of sipcore issue tracker
> Sent: 31 August 2010 18:37
> To: [email-masked]
> Cc: [email-masked]
> Subject: [sipcore] #24: Redirect servers
> 
> #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
>