Hi ,
that's not correct - you shouldn't route sequential request based on user location, but based on Route headers. Roughly :
if (is_method("REFER")) { loose_route(); t_relay(); exit; }
regards, bogdan
Frogger wrote:
Thanks for the quick response,
So basically its as simple as:
if (method=="REFER") {
#routing code here or
if (lookup("location")) {
# or routing code here
}
}
Does that sound right?
Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi,
you need to process the REFER as an within the dialog request - it has to tag so you have to route it based on Route headers (via loose_route).
regards, bogdan
Frogger wrote:
I have a successful implementation of openser 0.9.5 and its been working very nicely.
I am faced with transferring of calls from pstn to userC by way of userB and I am struggling.
path:
PSTN=>GW=>SBC=>openser=>uB
uB transfers call to uC
Call is failing to transfer as "refer" message is
not
properly handled by my openser script.
Any guidance would be appreciated.
Transfer works when all legs are from registered clients. Only when the initial call leg is from
the
PSTN does it not work.
Thanks, Rock
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I have added this code and I am suffering the same problem.
Here is a more detailed verion of my issue...
When pstn-callerA calls IPuserB, IPuserB talks to pstn-callerA... then IPuserB "transfers" to IPuserC.
IPuserB and IPuserC are able to talk (as before while pstn-caller "holds": working) and then,
(this is where it fails) IPuserB presses "transfer" again to complete the "transfer" of the pstn-callerA to IPuserC.
This should connect IPuserC and pstn-callerA.
(BTW, this works if all callers are registered UAs and there are no pstn legs.)
How do I connect the original PSTN caller to userC
I am sorry for being so dense and I am sure its a simple matter.
Thanks, Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi ,
that's not correct - you shouldn't route sequential request based on user location, but based on Route headers. Roughly :
if (is_method("REFER")) { loose_route(); t_relay(); exit; }
regards, bogdan
Frogger wrote:
Thanks for the quick response,
So basically its as simple as:
if (method=="REFER") {
#routing code here or
if (lookup("location")) {
# or routing code here
}
}
Does that sound right?
Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi,
you need to process the REFER as an within the dialog request - it has to tag so you have to route it based on Route headers (via loose_route).
regards, bogdan
Frogger wrote:
I have a successful implementation of openser
0.9.5
and its been working very nicely.
I am faced with transferring of calls from pstn
to
userC by way of userB and I am struggling.
path:
PSTN=>GW=>SBC=>openser=>uB
uB transfers call to uC
Call is failing to transfer as "refer" message is
not
properly handled by my openser script.
Any guidance would be appreciated.
Transfer works when all legs are from registered clients. Only when the initial call leg is from
the
PSTN does it not work.
Thanks, Rock
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
There is only one way to find out the reason of the problem: watch the SIP signalling.
use "ngrep port 5060" and watch the signalling during the call transfer. Probably the REFER will be sent to the GW, which may have another dialing plan as the userA and thus, the new INVITE sent from the GW can't be handled correctly.
(Take a look at the Refer-To header and verify that the GW and SIP Proxy can route the new INVITE request which uses the URI form the Refered-To header in the request URI)
klaus
On Fri, February 10, 2006 22:34, Frogger said:
I have added this code and I am suffering the same problem.
Here is a more detailed verion of my issue...
When pstn-callerA calls IPuserB, IPuserB talks to pstn-callerA... then IPuserB "transfers" to IPuserC.
IPuserB and IPuserC are able to talk (as before while pstn-caller "holds": working) and then,
(this is where it fails) IPuserB presses "transfer" again to complete the "transfer" of the pstn-callerA to IPuserC.
This should connect IPuserC and pstn-callerA.
(BTW, this works if all callers are registered UAs and there are no pstn legs.)
How do I connect the original PSTN caller to userC
I am sorry for being so dense and I am sure its a simple matter.
Thanks, Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi ,
that's not correct - you shouldn't route sequential request based on user location, but based on Route headers. Roughly :
if (is_method("REFER")) { loose_route(); t_relay(); exit; }
regards, bogdan
Frogger wrote:
Thanks for the quick response,
So basically its as simple as:
if (method=="REFER") {
#routing code here or
if (lookup("location")) {
# or routing code here
}
}
Does that sound right?
Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi,
you need to process the REFER as an within the dialog request - it has to tag so you have to route it based on Route headers (via loose_route).
regards, bogdan
Frogger wrote:
I have a successful implementation of openser
0.9.5
and its been working very nicely.
I am faced with transferring of calls from pstn
to
userC by way of userB and I am struggling.
path:
PSTN=>GW=>SBC=>openser=>uB
uB transfers call to uC
Call is failing to transfer as "refer" message is
not
properly handled by my openser script.
Any guidance would be appreciated.
Transfer works when all legs are from registered clients. Only when the initial call leg is from
the
PSTN does it not work.
Thanks, Rock
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
I am also using a B2BUA.
I am sure this is a big contributor to my issue.
Any thoughts?
Thanks, Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi ,
that's not correct - you shouldn't route sequential request based on user location, but based on Route headers. Roughly :
if (is_method("REFER")) { loose_route(); t_relay(); exit; }
regards, bogdan
Frogger wrote:
Thanks for the quick response,
So basically its as simple as:
if (method=="REFER") {
#routing code here or
if (lookup("location")) {
# or routing code here
}
}
Does that sound right?
Rock
--- Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi,
you need to process the REFER as an within the dialog request - it has to tag so you have to route it based on Route headers (via loose_route).
regards, bogdan
Frogger wrote:
I have a successful implementation of openser
0.9.5
and its been working very nicely.
I am faced with transferring of calls from pstn
to
userC by way of userB and I am struggling.
path:
PSTN=>GW=>SBC=>openser=>uB
uB transfers call to uC
Call is failing to transfer as "refer" message is
not
properly handled by my openser script.
Any guidance would be appreciated.
Transfer works when all legs are from registered clients. Only when the initial call leg is from
the
PSTN does it not work.
Thanks, Rock
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam
protection around
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com