11 Sep
2006
11 Sep
'06
1:55 a.m.
Hi,
On 9/11/06, Roger Lewau <roger.lewau(a)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