<HTML>
<HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE title="table borders">.htmtableborders, .htmtableborders td,
.htmtableborders th {border : 1px dashed lightgrey ! important;} </STYLE>
<STYLE type=text/css>html, body { border: 0px; } span.macro, span.macro ul,
span.macro div, span.macro p {background : #CCCCCC;} </STYLE> <STYLE
type=text/css> p{margin-bottom: 0.15em;margin-top:
0.15em;}body{font-family:tahoma;font-size:10pt;}; </STYLE> </HEAD> <BODY>
<FONT style="FONT-SIZE: 10pt; FONT-FAMILY: tahoma"> <DIV>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?</DIV> <DIV> </DIV>
<DIV>Kind regards</DIV> <DIV>Roger</DIV></FONT><BR> <BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT:
#000000 2px solid; MARGIN-RIGHT: 0px">-----Original Message-----<BR>From:
"Weiter Leiter" <bp4mls@googlemail.com><BR>To: "Roger Lewau"
<roger.lewau@serverhallen.com><BR>Cc: serusers@lists.iptel.org<BR>
Date: Mon, 11 Sep 2006 03:55:25 +0200<BR>Subject: Re: Handling 302
responses<BR><BR> <DIV style="FONT-FAMILY: monospace, courier new, courier">
Hi,<BR><BR>On 9/11/06, Roger Lewau <roger.lewau@serverhallen.com>
wrote:<BR>> Hello list,<BR>><BR>> I have searched this list for an
answer to the 302 response handling problem<BR>> but found no real
solution. It seems no one actually has an aswer for this<BR>> so I
studied the RFC 3261 and found the following statement:<BR>><BR>> The
requesting client SHOULD retry the request at the new address(es) given<BR>
> by the contact header field.<BR>><BR>> In my mind that statement
is completely off the wall, it is not the<BR>> requesting client that
should be responsible for establishing the forwarded<BR>> call, it never
is in the rest of the telecom industry so why should it be<BR>> the case
for SIP?<BR><BR>SIP, indeed, moved some inteligence towards the edge of the
network,<BR>into the clients, compared to older protocols.<BR>On the other
hand, this helps to protocol's scalability (and this<BR>characteristic can
be observed with dns or http or most of the scaling<BR>protocols).<BR><BR>
<BR>> Instead, this should ofcourse be the responsibility of the<BR>>
forwarding client or the service provider on behalf of the forwarding<BR>
> client. But as the RFC is not crafted that way I need to find a way
to<BR>> handle call forwarding in a proper way so that the cost for the
forwarded<BR>> call ends up on the forwarding clients bill. As call
forwarding is a basic<BR>> requirement in any phone network there must be
some one reading this list<BR>> who has solved this issue that can share
there insight.<BR><BR>Normally the forwarding is handled by the registrar
responsible for<BR>the callee (because it offers the callee greater
flexibility with his<BR>forwarding settings).<BR>But if the 'final' proxy is
missing this feature and a 3xx is replied,<BR>what would prevent you to bill
your client which presumably makes a<BR>new request, probably still through
your proxy, to some other<BR>destination?<BR><BR>WL.<BR><BR>><BR>> Any
help on this issue is highly apreciated.<BR>><BR>> Kind regards<BR>
> Roger Lewau<BR>><BR>><BR>><BR></DIV></BLOCKQUOTE></BODY>
</HTML>