Adrian Georgescu writes:
A SIP provider has interconnect from incumbent PSTN operator (Cisco gateway) using SIP (SER installation). This provider has an E164 number range placed in ENUM. The problem here is that when an ENUM number is resolved to a remote domain and the destination username is an alias on the remote domain, the provider proxy will pass the redirect back to gateway who in term makes the final call.
it is not a good idea to let the gw to process the redirect, since if call is coming from pstn to a sip user and the sip user has redirect to expensive 700 number, the gateway would need to pay for the new leg. but as i tried to explained earlier, i don't think that it is a good idea for the proxy to process it either, since again, who would pay for the new leg if it would go to a 700 number? legally the user who has placed redirect in his or her sip phone cannot be charged for the redirect.
This provider gets paid by the incumbent for terminating minutes on IP for those E164 numbers but as the proxy is not in the middle they do not know how much traffic their numbers generated for anything that is an alias. The problem in this case is accounting. The Proxy should stay in the middle of the dialog in this scenario so your function makes perfect sense.
the proxy would stay in the middle if the proxy is serving the domains enum queries return. so i don't quite understand your example.
This scenario is described very nice in this document.
it is not clear from the document, why the 302 can't go all the way to A, i.e., what the benefit is for the proxy handling the redirect. if the proxy is A's outbound proxy, it would get the new invite too. if not, there is nothing the provider can do about it, since use of an outbound proxy is user's own choice.
-- juha
On Jun 14, 2004, at 9:43 AM, Juha Heinanen wrote:
Adrian Georgescu writes:
A SIP provider has interconnect from incumbent PSTN operator (Cisco gateway) using SIP (SER installation). This provider has an E164 number range placed in ENUM. The problem here is that when an ENUM number is resolved to a remote domain and the destination username is an alias on the remote domain, the provider proxy will pass the redirect back to gateway who in term makes the final call.
it is not a good idea to let the gw to process the redirect, since if call is coming from pstn to a sip user and the sip user has redirect to expensive 700 number, the gateway would need to pay for the new leg. but as i tried to explained earlier, i don't think that it is a good idea for the proxy to process it either, since again, who would pay for the new leg if it would go to a 700 number? legally the user who has placed redirect in his or her sip phone cannot be charged for the redirect.
As with any numbering plan, this is configured based on destination URI, the decision is made in ser.cfg whether to proxy or not. Depending on the peering with other you may take different decisions which fit your business plan.
This provider gets paid by the incumbent for terminating minutes on IP for those E164 numbers but as the proxy is not in the middle they do not know how much traffic their numbers generated for anything that is an alias. The problem in this case is accounting. The Proxy should stay in the middle of the dialog in this scenario so your function makes perfect sense.
the proxy would stay in the middle if the proxy is serving the domains enum queries return. so i don't quite understand your example.
This scenario is described very nice in this document.
it is not clear from the document, why the 302 can't go all the way to A, i.e., what the benefit is for the proxy handling the redirect. if the proxy is A's outbound proxy, it would get the new invite too. if not, there is nothing the provider can do about it, since use of an outbound proxy is user's own choice.
Do you know do you set a Cisco gateway to use Outbound gateway? Maybe this is the best answer for the problem.
-- juha
Adrian Georgescu writes:
Do you know do you set a Cisco gateway to use Outbound gateway? Maybe this is the best answer for the problem.
if the sip provider has a set of e.164 prefixes allocated for it, you simply define a dial-peer matching those prefixes where provider's proxy is the session target.
-- juha
Yes but ENUM yields an URI served by a distant proxy which returns a redirect. The redirect is passed back to the Cisco which makes the call directly to the redirected domain without passing through initial Proxy that did the ENUM lookup.
On Jun 14, 2004, at 10:25 AM, Juha Heinanen wrote:
Adrian Georgescu writes:
Do you know do you set a Cisco gateway to use Outbound gateway? Maybe this is the best answer for the problem.
if the sip provider has a set of e.164 prefixes allocated for it, you simply define a dial-peer matching those prefixes where provider's proxy is the session target.
-- juha
Adrian Georgescu writes:
Yes but ENUM yields an URI served by a distant proxy which returns a redirect. The redirect is passed back to the Cisco which makes the call directly to the redirected domain without passing through initial Proxy that did the ENUM lookup.
the answer to this is to turn off enum lookup in the gw and do it in the proxy.
-- juha
On Jun 14, 2004, at 11:03 AM, Juha Heinanen wrote:
Adrian Georgescu writes:
Yes but ENUM yields an URI served by a distant proxy which returns a redirect. The redirect is passed back to the Cisco which makes the call directly to the redirected domain without passing through initial Proxy that did the ENUM lookup.
the answer to this is to turn off enum lookup in the gw and do it in the proxy.
In this case it is in the proxy. But as ENUM returned URI which points to another Proxy and that proxy returned a Redirect....
-- juha
Adrian Georgescu writes:
In this case it is in the proxy. But as ENUM returned URI which points to another Proxy and that proxy returned a Redirect....
then the proxy just forwards the redirect to the gw, which is configured to reject it. in cisco gw you can do this by sip-ua command "no redirect". why the gw needs to reject the redirect is because it should be going to the calling pstn user, but there is no protocol in pstn to do it.
-- juha
-
Adrian Georgescu -
Juha Heinanen