I Agree that forwarding should be handled by the registrar of the calle and this is what I am trying to accomplish. However I found no way in SER to handle this situation. If I let SER relay the 302 to the caller there is no way of knowing that the resulting new INVITE should be billed to the calle because it is a completely new call leg. The way to handle this, I think, should be to catch the 302 response in a failure route and then turn that into a new invite that can be billed to the callee. My question is how do you do this?
Kind regards Roger
-----Original Message----- From: "Weiter Leiter" bp4mls@googlemail.com To: "Roger Lewau" roger.lewau@serverhallen.com Cc: serusers@lists.iptel.org Date: Mon, 11 Sep 2006 03:55:25 +0200 Subject: Re: Handling 302 responses
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