[EMAIL PROTECTED] wrote:
> From: "V.S.R Kumar Kadimcherla" <[EMAIL PROTECTED]>
>
> When a stateful proxy has received 302 responses from all the down
> stream client transactions and received some contacts in those
> responses then proxy is sending 300 response to the upstream by
> appending the all contacts received in 302 responses in to the
> contact header field. Proxy is not looking for any duplication of
> contacts before forwarding the 300 response. Is it a valid
> behavior?
>
> Elimination of duplicate entries is duty of the proxy or end point
> has to take care of this?
>
> I don't think that RFC 3261 even allows a proxy to aggregate 3xx
> responses it receives into one 3xx response to send upstream,
Why not?
This is just like any other case of a proxy aggregating responses, such
as authentication challenges.
In reality, when the proxy aggregates responses, what it is really doing
is forking to itself as a UA, and then the UA part of the proxy is
generating a final response. In that capacity it can return a 3xx
response with any contacts it wants in it. Its just a happy coincidence
that they are the equivalent of aggregating the Contacts from the 3xx's
the proxy received.
Paul
> but it
> does seem to be the correct thing to do if the proxy does not want to
> implement 3xx on its own. (But it's not clear why it wouldn't since
> the proxy already implements forking.)
>
> IIRC, a SIP element that does forking is required to not sent multiple
> requests to the same target URI regardless of how the target set is
> constructed, so it should be ignoring duplicate Contact values in any
> 3xx it receives. So it seems that it is safe for the aggregating
> proxy to not check for duplicate Contacts. But a forking proxy
> already must implement the URI-comparison operation, so it shouldn't
> be hard for it to delete duplicates as it is aggregating 3xx
> responses.
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
