Hi,

On 9/11/06, Roger Lewau <roger.lewau@serverhallen.com> wrote:
> Hello list,
>
> I have searched this list for an answer to the 302 response handling problem
> but found no real solution. It seems no one actually has an aswer for this
> so I studied the RFC 3261 and found the following statement:
>
> The requesting client SHOULD retry the request at the new address(es) given
> by the contact header field.
>
> In my mind that statement is completely off the wall, it is not the
> requesting client that should be responsible for establishing the forwarded
> call, it never is in the rest of the telecom industry so why should it be
> the case for SIP?

SIP, indeed, moved some inteligence towards the edge of the network,
into the clients, compared to older protocols.
On the other hand, this helps to protocol's scalability (and this
characteristic can be observed with dns or http or most of the scaling
protocols).

> Instead, this should ofcourse be the responsibility of the
> forwarding client or the service provider on behalf of the forwarding
> client. But as the RFC is not crafted that way I need to find a way to
> handle call forwarding in a proper way so that the cost for the forwarded
> call ends up on the forwarding clients bill. As call forwarding is a basic
> requirement in any phone network there must be some one reading this list
> who has solved this issue that can share there insight.

Normally the forwarding is handled by the registrar responsible for
the callee (because it offers the callee greater flexibility with his
forwarding settings).
But if the 'final' proxy is missing this feature and a 3xx is replied,
what would prevent you to bill your client which presumably makes a
new request, probably still through your proxy, to some other
destination?

WL.

>
> Any help on this issue is highly apreciated.
>
> Kind regards
> Roger Lewau
>
>
>