12 Sep
2006
12 Sep
'06
6:50 a.m.
Hi Roger,
I think you are complicating the picture by trying to join two quite
different worlds: SIP world and the PSTN world. SIP was not intended to
be introduced into the PSTN world, it applied some basic "Internet-type"
principles to the problem of setting up media session over the Internet.
Even the new IMS specifications for 3G follow the intentions of SIP
(although there are some conflicts between "telco people" and "Internet
people".
By no means are you alone, many UAs have been implemented with PSTN
replacement services in mind. In PSTN, call forwarding is associated
with multiple call legs, each leg being charged to the A-number (calling
party). (Of course, tromboning can can be done to optimize the media
path, but signalling-wise the call legs are still present, and thus also
in billing). In SIP, a REFER is not the creation of a new call leg, it
is simple a message back to caller that callee can be reached elsewhere.
Strictly speaking, to simulate PSTN, but using SIP intentions, the SIP
UA should implement B2BUA and initiate a new INVITE to the forwarded
address. The reason is that SIP puts more responsibility on the
endpoints than in PSTN (where the endpoints are dumb). Of course, you
don't want to do this.
So, to your problem: You probably have incoming PSTN calls to your
UA, which you have decided should use 302 for "forwarding". The 302 is a
reply, not a failure, so you will receive it in your onreply route. You
can probably then test for 302, change the ruri and append a branch.
Depending on your billing handling, you should add a Diversion header,
CC-Diversion or store in acc module using avpairs (Jiri noted that this
is possible in a recent thread, I have never done it) the party who
redirected.
Maybe these call flows can help in understanding 302. It doesn't cover
302 from clients though.
http://www.cisco.com/univercd/cc/td/doc/product/voice/sipsols/biggulp/bgsip…
I hope this makes sense to you.
BTW, I think you would received some sensibles answers earlier if you
hadn't used your "off the wall" statement...
g-)
Roger Lewau wrote:
Hello Greger
I am surprised that you argue that 302s is not the standard call
forward scenario when this is how it is implemented in almost all sip
equipment (haven't seen any device who does it differently). Customer
will punch in cfwd (like *72<number>) in their phone and expect the
operator (me) to forward the call to the destination at their expense.
This is nothing new or strange. 302s signal that an UA has temporarily
been moved and can be reached somewhere else, how is that not call
forwarding? Also, I would never expect an UA to send back an email
address in an IP telephony system, even if it is theoretically
possible. I would expect it to send back a SIP address; everything
else is not reachable through the protocol of SIP and makes absolutely
no sense.
Most Voip customers are not techies and they are not rfc knowledgeable
and could not care any less about how the forwarding is made. They
would not be upset that their 302 generate a cost, this is the
expected behaviour for this service.
Kind regards
Roger
------------------------------------------------------------------------
*Från:* serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] *För *Greger V. Teigre
*Skickat:* den 11 september 2006 11:59
*Till:* Roger Lewau
*Kopia:* serusers(a)iptel.org; jh(a)tutpro.com
*Ämne:* Re: [Serusers] Handling 302 responses
Hi Roger,
I think that was Juha's point: we don't.
302 was created to enable a user agent to communicate back to the
other user agent that it can be reached somewhere else. Thus, your
server should relay the 302 and the receiving user agent should then
decide what to do. Some UAs immediate initiate a new call, while
others (e.g.software agents) may pop up a question to the user:
"Callee is not available, but can be reached at location" (which of
course may well be an international PSTN call that can be expensive).
Some UAs also have options that can be set: How to handle redirects
Server-centric forwarding can be better handled by user preferences
and loading av pairs.
That being said, I remember a thread a while ago with a discussion on
how to turn a 302 into a forwarding. I don't remember the outcome, but
it is probably possible, although not according to the RFCs. You do
have some problems though, e.g. if the UA sends back an email uri etc.
And of course, as people tend to follow RFCs, you will probably get
one angry customer if he realizes that his 302 generates a cost. If
you have control over the UA and have decided to use 302 instead of
the more standardized call forward scenario, you really are making
problems for yourself.
g-)
Roger Lewau wrote:
Hello Juha and Andrey
302 "Moved temporarily" is definately about forwarding/redirecting
calls. This is how the vast majority of all IP phones and ATAs handle
call forwarding. It might not be the intended use of 302 according to
RFCs, even if I see nothing that says otherwise, but this is how it is
used in end devices today. This brings us back to my original
question. How do you guys handle 302 redirection so that costs are
charged to the callee.
Kind regards
Roger
-----Original Message-----
From: "Andrey Kouprianov" <andrey.kouprianov(a)gmail.com>
<mailto:andrey.kouprianov@gmail.com>
To: serusers(a)iptel.org <mailto:serusers@iptel.org>
Date: Mon, 11 Sep 2006 12:51:09 +0700
Subject: Re: [Serusers] Handling 302 responses
You can also use 302 responses to gather some information about the
remote party. Contacts returned in the response are not necessarily
the SIP URI's. I've tried using mail addresses, SIP tel: URI's and
HTTP URLs too.
So, if the remote party is Busy at the moment, but has other ways to
let u contact them, 302 is one of the answers to this.
On 9/11/06, Juha Heinanen <jh(a)tutpro.com> <mailto:jh@tutpro.com>
wrote:
that the
Roger Lewau writes:
> 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?
302 is not about "forwarded call". it just tells the caller that the
callee is at some other uri, which the caller may or may not wish to
contact. in many pstn networks, you can hear an announcement number you tried is not in use and you should try
another number
instead.
if callee wants to "forward" calls, he has other means for that
purpose,
for example, his phone can forward the invite to
some other uri or he
may configure his proxy to do so.
-- juha
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers