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
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@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
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
On Wed, Jan 30, 2008 at 04:20:32PM -0500, Alex Balashov wrote:
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).
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
On Wed, Jan 30, 2008 at 04:26:26PM -0500, Alex Balashov wrote:
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
On Wed, Jan 30, 2008 at 04:20:32PM -0500, Alex Balashov wrote:
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).
Gotcha. So what do you want OpenSER to do with these? Or perhaps a more useful question is, what are you doing with OpenSER?
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.
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
El Miércoles, 30 de Enero de 2008, Jan ONDREJ (SAL) escribió:
On Wed, Jan 30, 2008 at 04:26:26PM -0500, Alex Balashov wrote:
On Wed, 30 Jan 2008, Jan ONDREJ (SAL) wrote:
On Wed, Jan 30, 2008 at 04:20:32PM -0500, Alex Balashov wrote:
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).
Gotcha. So what do you want OpenSER to do with these? Or perhaps a more useful question is, what are you doing with OpenSER?
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.
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.
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?
Yes, it's done. The problem you have is that you are sending the REFER to a gateway.
Hello,
thank you for reply.
On Thu, Jan 31, 2008 at 12:13:38AM +0100, Iñaki Baz Castillo wrote:
El Miércoles, 30 de Enero de 2008, Jan ONDREJ (SAL) escribió:
On Wed, Jan 30, 2008 at 04:26:26PM -0500, Alex Balashov wrote:
Error: Have you investigated how REFER works? Two examples:
Yes. I know this theory.
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.
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.
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?
Yes, it's done. The problem you have is that you are sending the REFER to a gateway.
Hmm, really? :(
SAL
El Jueves, 31 de Enero de 2008, Jan ONDREJ (SAL) escribió:
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.
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.
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@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@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@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@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
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:
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.
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?
-
Alex Balashov -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jan ONDREJ (SAL)