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