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? 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.
Any help on this issue is highly apreciated.
Kind regards Roger Lewau
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
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
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
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
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, Andrey Kouprianov andrey.kouprianov@gmail.com wrote:
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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@gmail.com To: 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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@gmail.com> To: 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@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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 (havent 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@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@iptel.org; jh@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" mailto:andrey.kouprianov@gmail.com andrey.kouprianov@gmail.com To: 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 mailto:jh@tutpro.com jh@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_____
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Roger Lewau writes:
302s signal that an UA has temporarily been moved and can be reached somewhere else, how is that not call forwarding?
simply because your UA replying with 302 does not forward the request anywhere. i have heard it called redirecting.
-- juha
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/bgsipc...
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@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@iptel.org; jh@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@gmail.com> <mailto:andrey.kouprianov@gmail.com> To: serusers@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@tutpro.com> <mailto:jh@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@lists.iptel.org <mailto:Serusers@lists.iptel.org> > http://lists.iptel.org/mailman/listinfo/serusers > _______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org mailto:Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@teigre.com] Skickat: den 12 september 2006 08:51 Till: Roger Lewau Kopia: serusers@iptel.org; jh@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/bgsipc f.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 (havent 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@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@iptel.org; jh@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" mailto:andrey.kouprianov@gmail.com andrey.kouprianov@gmail.com To: 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 mailto:jh@tutpro.com jh@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_____
_______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@teigre.com] *Skickat:* den 12 september 2006 08:51 *Till:* Roger Lewau *Kopia:* serusers@iptel.org; jh@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 yourUA, 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/bgsipc...
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@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@iptel.org; jh@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@gmail.com> <mailto:andrey.kouprianov@gmail.com> To: serusers@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@tutpro.com> <mailto:jh@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@lists.iptel.org <mailto:Serusers@lists.iptel.org> > http://lists.iptel.org/mailman/listinfo/serusers > _______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org mailto:Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Andrey Kouprianov -
Greger V. Teigre -
Juha Heinanen -
Roger Lewau -
Weiter Leiter