30 Jan
2008
30 Jan
'08
4:19 p.m.
Hello,
can somebody give me a working example of configuration file, supporting
"Call transfer" or proper "REFER" passing?
Call transfer does not work with default openser.cfg and also with my
extended configuration or sipwise generated configuration.
My phones supports call transfer and it works well with asterisk, but no
success with openser. Can somebody give me an example config or hints,
what to do to make a working call transfer?
Thank you.
SAL
30 Jan
30 Jan
4:20 p.m.
Jan,
Do your phones actually support transfer via the REFER method, or by
issuing 302 Moved Temporarily messages?
Thanks,
-- Alex
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
Hello,
can somebody give me a working example of configuration file, supporting
"Call transfer" or proper "REFER" passing?
Call transfer does not work with default openser.cfg and also with my
extended configuration or sipwise generated configuration.
My phones supports call transfer and it works well with asterisk, but no
success with openser. Can somebody give me an example config or hints,
what to do to make a working call transfer?
Thank you.
SAL
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : +1-678-954-0670
Direct : +1-678-954-0671
4:26 p.m.
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
On Wed, Jan 30, 2008 at 04:20:32PM -0500, Alex
Balashov wrote:
Gotcha. So what do you want OpenSER to do with these? Or perhaps a
more useful question is, what are you doing with OpenSER?
They are not going to be statefully proxied as they are a distinct
method unto themselves, so they're going to require some sort of
association with an existing call ID, which you can do via AVPs, a
database, whatever. But otherwise, just purely for routing them,
rewrite the destination URI as necessary based on the REFER parameters.
OpenSER is a proxy, so it shouldn't really be "handling" referrals,
just passing them back to the user agent/server (UAC/UAS) that will
ultimately be taking care of that.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : +1-678-954-0670
Direct : +1-678-954-0671
Do your phones actually support transfer via the
REFER method, or by
issuing 302 Moved Temporarily messages?
I see "REFER" in sniffed packets (Polycom phones).
4:35 p.m.
On Wed, Jan 30, 2008 at 04:26:26PM -0500, Alex Balashov wrote:
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
We are using openser to route calls between our gateway, a PSTN gateway,
ENUM, etc...
Evrything worked fine before we tryed to transfer calls from phone to phone.
I want to add this feature to my VoIP site.
On Wed, Jan 30, 2008 at 04:20:32PM -0500, Alex
Balashov wrote:
Gotcha. So what do you want OpenSER to do with these? Or perhaps a more
useful question is, what are you doing with OpenSER? Do your phones actually support transfer via the
REFER method, or by
issuing 302 Moved Temporarily messages?
I see "REFER" in sniffed packets (Polycom phones). They are not going to be statefully proxied as they
are a distinct
method unto themselves, so they're going to require some sort of
association with an existing call ID, which you can do via AVPs, a
database, whatever. But otherwise, just purely for routing them,
rewrite the destination URI as necessary based on the REFER parameters.
Can you give me an example, how to do this? I still don't understand all
magics of AVPs.
An example configuration with call transfer support can be useful for other
users too, so it can be good to include it into openser distribution's
example configurations.
OpenSER is a proxy, so it shouldn't really be
"handling" referrals,
just passing them back to the user agent/server (UAC/UAS) that will
ultimately be taking care of that.
It's not done by default config?
Somewhere I read, that REFER handling need to be supported in UACs only.
But why it is not working in standard configurations?
SAL
6:13 p.m.
El Miércoles, 30 de Enero de 2008, Jan ONDREJ (SAL) escribió:
Yes, it's done. The problem you have is that you are sending the REFER to a
gateway.
--
Iñaki Baz Castillo
On Wed, Jan 30, 2008 at 04:26:26PM -0500, Alex
Balashov wrote:
Error: Have you investigated how REFER works? Two examples:
case 1)
3 phones (A, B, C)
- A calls B and they speak.
- B wants to transfer the call to C. So B sends a REFER to A like this:
REFER sip:A@IP_A
Refer-To: sip:C@domain
- So A will receive that REFER and then A will generate an INVITE to C:
INVITE sip:C@domain
From: A@domain
- So in conclusion: a REFER in fact means: "please, invite this other user".
case 2)
2 phones (A, B) and a gateway.
- The gateway calls B and they speak.
- B wants to transfer to A so it sends a REFER to gateway like this:
REFER sip:gateway@IP_gateway
Refer-To: sip:A@domain
- So now the **gateway** should generate an INVITE to A. Unfortunatelly AFAIK
most of gateways won't allow it (and it sems logical to me).
What you need is a B2BUA between the gateway and phones. In this way the UAS
receiving the REFER will be the B2BUA (that you control) and not the gateway.
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
We are using openser to route calls between our gateway, a PSTN gateway,
ENUM, etc...
Evrything worked fine before we tryed to transfer calls from phone to
phone. I want to add this feature to my VoIP site. On Wed, Jan 30, 2008 at 04:20:32PM -0500, Alex
Balashov wrote:
Gotcha. So what do you want OpenSER to do with these? Or perhaps a
more useful question is, what are you doing with OpenSER? Do your phones actually support transfer via the
REFER method, or by
issuing 302 Moved Temporarily messages?
I see "REFER" in sniffed packets (Polycom phones). An example configuration with call transfer support
can be useful for other
users too, so it can be good to include it into openser distribution's
example configurations.
No, OpenSer is a SIP proxy, not a PBX or B2BUA, it just should route the REFER
according to RFC 3261 for in-dialog messages.
OpenSER is a
proxy, so it shouldn't really be "handling" referrals,
just passing them back to the user agent/server (UAC/UAS) that will
ultimately be taking care of that.
It's not done by default config?
31 Jan
31 Jan
3:02 a.m.
Hello,
thank you for reply.
On Thu, Jan 31, 2008 at 12:13:38AM +0100, Iñaki Baz Castillo wrote:
Hmm, theory. Does not work for me. After trying to change to asterisk
it works with my phones, but I am unable to do this with openser.
I don't like asterisk, so I want to configure openser for this situation.
Yes, it's done. The problem you have is that you are sending the REFER to a
gateway.
Hmm, really? :(
SAL
El Miércoles, 30 de Enero de 2008, Jan ONDREJ (SAL)
escribió:
Yes. I know this theory.
On Wed, Jan 30, 2008 at 04:26:26PM -0500, Alex
Balashov wrote:
Error: Have you investigated how REFER works? Two examples: case 1)
3 phones (A, B, C)
- A calls B and they speak.
- B wants to transfer the call to C. So B sends a REFER to A like this:
REFER sip:A@IP_A
Refer-To: sip:C@domain
- So A will receive that REFER and then A will generate an INVITE to C:
INVITE sip:C@domain
From: A@domain
- So in conclusion: a REFER in fact means: "please, invite this other user".
I am trying call transfer in this situation (case 1). It is not working in
my default cofnig (attached to this email, there are just removed
authentications to simply my testing).
Tryed blind transfer and also managed transfer.
One of three phnes still goes to undefined state (for example holding an
nonexistent call). In different situations different phones.
case 2)
2 phones (A, B) and a gateway.
- The gateway calls B and they speak.
- B wants to transfer to A so it sends a REFER to gateway like this:
REFER sip:gateway@IP_gateway
Refer-To: sip:A@domain
- So now the **gateway** should generate an INVITE to A. Unfortunatelly AFAIK
most of gateways won't allow it (and it sems logical to me).
What you need is a B2BUA between the gateway and phones. In this way the UAS
receiving the REFER will be the B2BUA (that you control) and not the gateway.
This is what I will need in future, but I am now experimenting only with
"case 1". I can't experiment on my active openser, so I configured another
openser and trying something simple (case 1). But it is not working. :(
An example
configuration with call transfer support can be useful for other
users too, so it can be good to include it into openser distribution's
example configurations.
No, OpenSer is a SIP proxy, not a PBX or B2BUA, it just should route the REFER
according to RFC 3261 for in-dialog messages. OpenSER is a proxy, so it shouldn't really be
"handling" referrals,
just passing them back to the user agent/server (UAC/UAS) that will
ultimately be taking care of that.
It's not done by default config?
10:08 a.m.
El Jueves, 31 de Enero de 2008, Jan ONDREJ (SAL) escribió:
Maybe that is a phone issue. I can sure that SIP transfer works perfectly
between some UAC's as Twinkle, Linksys SPA, Thomson S2030...
Of course, nothing special in OpenSer, it just has to route an in-dialog
REFER, no more.
Try doing a SIP trace in OpenSer host with ngrep:
ngrep -d any -P ' ' -W byline -T -t "" port 5060
And examinate it.
--
Iñaki Baz Castillo
case 1)
3 phones (A, B, C)
- A calls B and they speak.
- B wants to transfer the call to C. So B sends a REFER to A like this:
REFER sip:A@IP_A
Refer-To: sip:C@domain
- So A will receive that REFER and then A will generate an INVITE to C:
INVITE sip:C@domain
From: A@domain
- So in conclusion: a REFER in fact means: "please, invite this other
user".
I am trying call transfer in this situation (case 1). It is not working in
my default cofnig (attached to this email, there are just removed
authentications to simply my testing).
Tryed blind transfer and also managed transfer.
One of three phnes still goes to undefined state (for example holding an
nonexistent call). In different situations different phones.
4 Feb
4 Feb
9:10 a.m.
On Thu, Jan 31, 2008 at 04:08:04PM +0100, Iñaki Baz Castillo wrote:
El Jueves, 31 de Enero de 2008, Jan ONDREJ (SAL)
escribió:
Maybe that is a phone issue. I can sure that SIP transfer works perfectly
between some UAC's as Twinkle, Linksys SPA, Thomson S2030...
Of course, nothing special in OpenSer, it just has to route an in-dialog
REFER, no more.
What means "route an in-dialog REFER"? Something special in configuration?
Transfer still does not work for me. :-(
My situation:
caller: XXX.YYY.10.231 (phone A 1975)
tranferer: XXX.YYY.10.120 (phone B 1976)
transfer_to: XXX.YYY.10.10 (phone C 1515)
openser: XXX.YYY.240.41
Calling from phone A to phone B, after call is answered, transfering call to
phone C, answer on phone C. It's working to this point.
Then trying to start call tranfer by touching "Transfer" again on B,
but my phone is not responding to this button. Same situation with
different or same phones, different configuration.
Sending part of my log, begginning with "REFER" packet. If you need whole
log, just tell me (~14 kB).
Thank you for help.
SAL
#
U 2008/02/04 14:48:31.492882 XXX.YYY.10.120:5060 -> XXX.YYY.240.41:5060
REFER sip:1975@XXX.YYY.10.231:5060 SIP/2.0
Via: SIP/2.0/UDP XXX.YYY.10.120:5060;branch=z9hG4bK61b9579666FB47A7
From: <sip:1976@_______.sk:5060>;tag=9630F891-C38074A8
To: "Ondrej Jan - hid" <sip:1975@_______.sk>;tag=602903766
Route: <sip:XXX.YYY.240.41;lr;ftag=602903766>
CSeq: 2 REFER
Call-ID: 1784793844(a)XXX.YYY.10.231
Contact: <sip:1976@XXX.YYY.10.120:5060>
User-Agent: PolycomSoundPointIP-SPIP_501-UA/2.1.2.0078
Refer-To:
<sip:1515@work._______.sk;user=phone?Replaces=5d2787c0-b7a8f9be-527864c9%40XXX.YYY.10.120%3Bto-tag%3DD00A3DBB-DA0E760E%3Bfrom-tag%3DC3B5546C-A3986FAF>
Referred-By: <sip:1976@work._______.sk>
Max-Forwards: 70
Content-Length: 0
#
U 2008/02/04 14:48:31.493464 XXX.YYY.240.41:5060 -> XXX.YYY.10.231:5060
REFER sip:1975@XXX.YYY.10.231:5060 SIP/2.0
Record-Route: <sip:XXX.YYY.240.41;lr;ftag=9630F891-C38074A8>
Via: SIP/2.0/UDP XXX.YYY.240.41;branch=z9hG4bKe063.cdbf274.0
Via: SIP/2.0/UDP XXX.YYY.10.120:5060;branch=z9hG4bK61b9579666FB47A7
From: <sip:1976@_______.sk:5060>;tag=9630F891-C38074A8
To: "Ondrej Jan - hid" <sip:1975@_______.sk>;tag=602903766
CSeq: 2 REFER
Call-ID: 1784793844(a)XXX.YYY.10.231
Contact: <sip:1976@XXX.YYY.10.120:5060>
User-Agent: PolycomSoundPointIP-SPIP_501-UA/2.1.2.0078
Refer-To:
<sip:1515@work._______.sk;user=phone?Replaces=5d2787c0-b7a8f9be-527864c9%40XXX.YYY.10.120%3Bto-tag%3DD00A3DBB-DA0E760E%3Bfrom-tag%3DC3B5546C-A3986FAF>
Referred-By: <sip:1976@work._______.sk>
Max-Forwards: 69
Content-Length: 0
#
U 2008/02/04 14:48:31.512593 XXX.YYY.10.231:5060 -> XXX.YYY.240.41:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP XXX.YYY.240.41;branch=z9hG4bKe063.cdbf274.0
Via: SIP/2.0/UDP XXX.YYY.10.120:5060;branch=z9hG4bK61b9579666FB47A7
Record-Route: <sip:XXX.YYY.240.41;lr;ftag=9630F891-C38074A8>
From: <sip:1976@_______.sk:5060>;tag=9630F891-C38074A8
To: "Ondrej Jan - hid" <sip:1975@_______.sk>;tag=602903766
Call-ID: 1784793844(a)XXX.YYY.10.231
CSeq: 2 REFER
Contact: <sip:1975@XXX.YYY.10.231:5060>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER, UPDATE
Content-Length: 0
#
U 2008/02/04 14:48:31.513013 XXX.YYY.240.41:5060 -> XXX.YYY.10.120:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP XXX.YYY.10.120:5060;branch=z9hG4bK61b9579666FB47A7
Record-Route: <sip:XXX.YYY.240.41;lr;ftag=9630F891-C38074A8>
From: <sip:1976@_______.sk:5060>;tag=9630F891-C38074A8
To: "Ondrej Jan - hid" <sip:1975@_______.sk>;tag=602903766
Call-ID: 1784793844(a)XXX.YYY.10.231
CSeq: 2 REFER
Contact: <sip:1975@XXX.YYY.10.231:5060>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER, UPDATE
Content-Length: 0
exit
35 received, 0 dropped
9:21 a.m.
On Monday 04 February 2008 15:10:17 Jan ONDREJ (SAL) wrote:
On Thu, Jan 31, 2008 at 04:08:04PM +0100, Iñaki Baz
Castillo wrote:
Sorry, but I don't see enough information in that trace. Could you send a
complete trace of a failure case replacing IP's with "phone_A" or something
similar to make easier the understanding?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
El Jueves, 31 de Enero de 2008, Jan ONDREJ (SAL)
escribió:
Maybe that is a phone issue. I can sure that SIP transfer works perfectly
between some UAC's as Twinkle, Linksys SPA, Thomson S2030...
Of course, nothing special in OpenSer, it just has to route an in-dialog
REFER, no more.
What means "route an in-dialog REFER"? Something special in configuration?
Transfer still does not work for me. :-(
My situation:
caller: XXX.YYY.10.231 (phone A 1975)
tranferer: XXX.YYY.10.120 (phone B 1976)
transfer_to: XXX.YYY.10.10 (phone C 1515)
openser: XXX.YYY.240.41
Calling from phone A to phone B, after call is answered, transfering call
to phone C, answer on phone C. It's working to this point.
Then trying to start call tranfer by touching "Transfer" again on B,
but my phone is not responding to this button. Same situation with
different or same phones, different configuration.
6070
days inactive
6075
days old
9 comments
4 participants
participants (4)
-
Alex Balashov -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jan ONDREJ (SAL)