SV: SV: [Serusers] Handling 302 responses
Greger V. Teigre
greger at teigre.com
Wed Sep 13 11:42:19 CEST 2006
Yes, avp_write("$headername","$avp"); can be used to extract the header,
but remember that you cannot trust the diversion header from a UA for
billing... You probably want to keep the original callee in an avp that
can be accessed in the onreply route.
g-)
Roger Lewau wrote:
> Thank you for your answer.
>
> You are probably right that I would get better answer without the "off
> the wall" remark. Sorry if upset anyone.
>
> Ok, now we are getting some where. The 302s I get back from the UAs
> contains a diversion header with the callee info and the contact
> header contains the destination for the "forwarding". So is it
> possible to extract the info from these headers to use when appending
> the branch?
>
> Kind regards
> Roger
>
> ------------------------------------------------------------------------
> *Från:* Greger V. Teigre [mailto:greger at teigre.com]
> *Skickat:* den 12 september 2006 08:51
> *Till:* Roger Lewau
> *Kopia:* serusers at iptel.org; jh at tutpro.com
> *Ämne:* Re: SV: [Serusers] Handling 302 responses
>
> 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/bgsipcf.htm
>
> 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 at lists.iptel.org
>> [mailto:serusers-bounces at lists.iptel.org] *För *Greger V. Teigre
>> *Skickat:* den 11 september 2006 11:59
>> *Till:* Roger Lewau
>> *Kopia:* serusers at iptel.org; jh at 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 at gmail.com>
>> <mailto:andrey.kouprianov at gmail.com>
>> To: serusers at iptel.org <mailto:serusers at 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 at tutpro.com> <mailto:jh at tutpro.com>
>> wrote:
>> > 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
>> that the
>> > 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 at lists.iptel.org <mailto:Serusers at lists.iptel.org>
>> > http://lists.iptel.org/mailman/listinfo/serusers
>> >
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060913/dbbcb779/attachment.htm>
More information about the sr-users
mailing list