Help! FS Unable to Handle Incoming Calls Through SIP Gateway
Hi, FreeSWITCH gurus! I need your help! First off, I am new to FS and I am new to Internet telephony as well. Heck, I am new to the concept of NAT, UPnP, etc., so please bear with my ignorance. I subscribe to a VoIP service at home, with which I get one DID. They supply me a VoIP adapter. Their expected usage is for you to plug in analog phones to the analog phone jacks in the VoIP adapter. However, It also has four Ethernet LAN ports and it acts as a router. You can also access it from the LAN side and register with its built-in SIP gateway. What I would like to do is to run FS (Windows version) on one of the Windows PCs, have it register with the SIP gateway, and have it act as an AA or IVR. For testing, I am having it just play music. When I tried the same idea with AsterikWin32, it worked just as I had hoped; it answered incoming calls automatically. However, I somehow cannot make it work with FS. I simulate incoming calls to my DID number with Skype's Sypeout. It fails after a short while with such error messages as "network error." It appears the call was never answered. FS is assigned an extension number 7 at the gateway. When I call extension 7 from a different extension (at the gateway level, not an extension inside FS), FS does answer the call and I hear music. FS fails to answer only incoming calls from outside. I think my FS configuration is fairly standard. I created an external SIP profile for the gateway under conf/sip_profiles/external/ and modified conf/dialplan/public/00_inbound_did.xml so incoming calls to the gateway will be transferred to an extension within FS. FS's messages and logs, plus the result of packet captures indicate that FS /thinks /it has answered the call, and goes on to initiate media communication. I see RTP packets going from FS to the SIP gateway. What's different from AsteriskWin32's case is that there are no RTP packets coming back from the SIP gateway to FS. Turning of the firewall of the PC does not seem to change the result in any way. For your perusal, I have created the following logs of communication between FS/AsteriskWin32 and the SIP gateway: * AsteriskWin32's case o Summary: http://pastebin.freeswitch.org/14457 o Details: http://pastebin.freeswitch.org/14460 * FreeSWITCh's case o Summary: http://pastebin.freeswitch.org/14462 o Details: http://pastebin.freeswitch.org/14463 o Log: http://pastebin.freeswitch.org/14465 The IP address of the SIP gateway is *192.168.11.250*, and that of the PC FS/AsteriskWin32 resides in is *192.168.11.11*. My DID number is masked as ABCDEFGHIJ. I do not know if it gives you any useful information, but those files include the registration phase. /FS's log was taken at a different time/, so it does not entirely match the packet captures. I also have the corresponding Pcap files. Please let me know if you need them. I am not entirely sure, but I think as far as what I'd like to do is concerned, NAT is not going to be an issue, because the FS/AsteriskWin32 PC and the SIP gateway (its LAN side IP address) are on the same subnet (192.168.11/24). At this time, I do not need to access FS from the Internet. Finally, I will give you more details about my setup, which may or may not be relevant to this issue. My home LAN is set up this way: http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup... Please note that there are /two layers/ of NAT, and that in the inner layer, two NAT devices exist. I know it looks convoluted, but there are logical reasons for this setup. The VoIP service provider only supports the PCMU codec. The music file I prepared for this testing is encoded in PCMU, so codecs will not be an issue. Please do not hesitate to ask if you have any questions. Thanks for your help in advance! Yasuro
Run your same test on FreeSWITCH but turn on sip debugging at the fs_cli: sofia global siptrace on Then make the call and capture the output and put into new pastebin. Hopefully you'll see why the channel is already hungup when it goes to play music. -MC 2010/11/10 Yasuro <yasuro@yasuro.com>
Hi, FreeSWITCH gurus! I need your help!
First off, I am new to FS and I am new to Internet telephony as well. Heck, I am new to the concept of NAT, UPnP, etc., so please bear with my ignorance.
I subscribe to a VoIP service at home, with which I get one DID. They supply me a VoIP adapter. Their expected usage is for you to plug in analog phones to the analog phone jacks in the VoIP adapter. However, It also has four Ethernet LAN ports and it acts as a router. You can also access it from the LAN side and register with its built-in SIP gateway.
What I would like to do is to run FS (Windows version) on one of the Windows PCs, have it register with the SIP gateway, and have it act as an AA or IVR. For testing, I am having it just play music.
When I tried the same idea with AsterikWin32, it worked just as I had hoped; it answered incoming calls automatically. However, I somehow cannot make it work with FS. I simulate incoming calls to my DID number with Skype's Sypeout. It fails after a short while with such error messages as "network error." It appears the call was never answered.
FS is assigned an extension number 7 at the gateway. When I call extension 7 from a different extension (at the gateway level, not an extension inside FS), FS does answer the call and I hear music. FS fails to answer only incoming calls from outside.
I think my FS configuration is fairly standard. I created an external SIP profile for the gateway under conf/sip_profiles/external/ and modified conf/dialplan/public/00_inbound_did.xml so incoming calls to the gateway will be transferred to an extension within FS.
FS's messages and logs, plus the result of packet captures indicate that FS *thinks *it has answered the call, and goes on to initiate media communication. I see RTP packets going from FS to the SIP gateway. What's different from AsteriskWin32's case is that there are no RTP packets coming back from the SIP gateway to FS. Turning of the firewall of the PC does not seem to change the result in any way.
For your perusal, I have created the following logs of communication between FS/AsteriskWin32 and the SIP gateway:
- AsteriskWin32's case - Summary: http://pastebin.freeswitch.org/14457 - Details: http://pastebin.freeswitch.org/14460 - FreeSWITCh's case - Summary: http://pastebin.freeswitch.org/14462 - Details: http://pastebin.freeswitch.org/14463 - Log: http://pastebin.freeswitch.org/14465
The IP address of the SIP gateway is *192.168.11.250*, and that of the PC FS/AsteriskWin32 resides in is *192.168.11.11*. My DID number is masked as ABCDEFGHIJ. I do not know if it gives you any useful information, but those files include the registration phase. *FS's log was taken at a different time*, so it does not entirely match the packet captures.
I also have the corresponding Pcap files. Please let me know if you need them.
I am not entirely sure, but I think as far as what I'd like to do is concerned, NAT is not going to be an issue, because the FS/AsteriskWin32 PC and the SIP gateway (its LAN side IP address) are on the same subnet (192.168.11/24). At this time, I do not need to access FS from the Internet.
Finally, I will give you more details about my setup, which may or may not be relevant to this issue.
My home LAN is set up this way:
http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup... Please note that there are *two layers* of NAT, and that in the inner layer, two NAT devices exist. I know it looks convoluted, but there are logical reasons for this setup.
The VoIP service provider only supports the PCMU codec. The music file I prepared for this testing is encoded in PCMU, so codecs will not be an issue.
Please do not hesitate to ask if you have any questions. Thanks for your help in advance!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Michael and other FreeSWITCH gurus: As per your instruction, I have created logs. Please take a look <http://pastebin.freeswitch.org/14479>. It includes FS's messages while it initializes itself. The VoIP adapter (SIP gateway, which also works as a router)'s IP address is *192.168.11.250* on the LAN side. That of the PC which is running FS is *192.168.11.11*. Its firewall function was turned off during this testing. The summary of packet exchange between the two during this same period is here <http://pastebin.freeswitch.org/14480>. Please see my original posting (which is included at the end of this message) for the setup of my home LAN. ~250 is sending RTCP receiver report before ~11 starts RTP communication. I am wondering if the former is giving up on the call because of time out; and, if it is true, if there is any way to have it wait longer. I am completely stuck about this issue and I'll welcome any input you have. Thanks! Yasuro Michael Collins wrote (11/12/2010 4:43 AM):
Run your same test on FreeSWITCH but turn on sip debugging at the fs_cli: sofia global siptrace on
Then make the call and capture the output and put into new pastebin. Hopefully you'll see why the channel is already hungup when it goes to play music. -MC
2010/11/10 Yasuro <yasuro@yasuro.com <mailto:yasuro@yasuro.com>>
Hi, FreeSWITCH gurus! I need your help!
First off, I am new to FS and I am new to Internet telephony as well. Heck, I am new to the concept of NAT, UPnP, etc., so please bear with my ignorance.
I subscribe to a VoIP service at home, with which I get one DID. They supply me a VoIP adapter. Their expected usage is for you to plug in analog phones to the analog phone jacks in the VoIP adapter. However, It also has four Ethernet LAN ports and it acts as a router. You can also access it from the LAN side and register with its built-in SIP gateway.
What I would like to do is to run FS (Windows version) on one of the Windows PCs, have it register with the SIP gateway, and have it act as an AA or IVR. For testing, I am having it just play music.
When I tried the same idea with AsterikWin32, it worked just as I had hoped; it answered incoming calls automatically. However, I somehow cannot make it work with FS. I simulate incoming calls to my DID number with Skype's Sypeout. It fails after a short while with such error messages as "network error." It appears the call was never answered.
FS is assigned an extension number 7 at the gateway. When I call extension 7 from a different extension (at the gateway level, not an extension inside FS), FS does answer the call and I hear music. FS fails to answer only incoming calls from outside.
I think my FS configuration is fairly standard. I created an external SIP profile for the gateway under conf/sip_profiles/external/ and modified conf/dialplan/public/00_inbound_did.xml so incoming calls to the gateway will be transferred to an extension within FS.
FS's messages and logs, plus the result of packet captures indicate that FS /thinks /it has answered the call, and goes on to initiate media communication. I see RTP packets going from FS to the SIP gateway. What's different from AsteriskWin32's case is that there are no RTP packets coming back from the SIP gateway to FS. Turning of the firewall of the PC does not seem to change the result in any way.
For your perusal, I have created the following logs of communication between FS/AsteriskWin32 and the SIP gateway:
* AsteriskWin32's case o Summary: http://pastebin.freeswitch.org/14457 o Details: http://pastebin.freeswitch.org/14460 * FreeSWITCh's case o Summary: http://pastebin.freeswitch.org/14462 o Details: http://pastebin.freeswitch.org/14463 o Log: http://pastebin.freeswitch.org/14465
The IP address of the SIP gateway is *192.168.11.250*, and that of the PC FS/AsteriskWin32 resides in is *192.168.11.11*. My DID number is masked as ABCDEFGHIJ. I do not know if it gives you any useful information, but those files include the registration phase. /FS's log was taken at a different time/, so it does not entirely match the packet captures.
I also have the corresponding Pcap files. Please let me know if you need them.
I am not entirely sure, but I think as far as what I'd like to do is concerned, NAT is not going to be an issue, because the FS/AsteriskWin32 PC and the SIP gateway (its LAN side IP address) are on the same subnet (192.168.11/24). At this time, I do not need to access FS from the Internet.
Finally, I will give you more details about my setup, which may or may not be relevant to this issue.
My home LAN is set up this way: http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup... Please note that there are /two layers/ of NAT, and that in the inner layer, two NAT devices exist. I know it looks convoluted, but there are logical reasons for this setup.
The VoIP service provider only supports the PCMU codec. The music file I prepared for this testing is encoded in PCMU, so codecs will not be an issue.
Please do not hesitate to ask if you have any questions. Thanks for your help in advance!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hello Yasuro, what I am wondering about is: Freeswitch is offering port 16670 in its SDP message of the SIP OK message, and 192.168.11.250 is trying to send RTP packets to 16671 instead. But this Freeswitch port is not open. So 192.168.11.250 closes the connection: See 217 49.351287 192.168.11.250 5005 192.168.11.11 16671 RTCP Receiver Report Source description 218 49.351369 192.168.11.11 5005 192.168.11.250 16671 ICMP Destination unreachable (Port unreachable) -- With kind regards Peter Steinbach Telefaks Services GmbH Theo-Geisel-Strasse 25 D 61250 Usingen, Germany mailto:lists (att) telefaks.de Internet: www.telefaks.de Yasuro schrieb:
Michael and other FreeSWITCH gurus:
As per your instruction, I have created logs. Please take a look <http://pastebin.freeswitch.org/14479>. It includes FS's messages while it initializes itself. The VoIP adapter (SIP gateway, which also works as a router)'s IP address is *192.168.11.250* on the LAN side. That of the PC which is running FS is *192.168.11.11*. Its firewall function was turned off during this testing. The summary of packet exchange between the two during this same period is here <http://pastebin.freeswitch.org/14480>. Please see my original posting (which is included at the end of this message) for the setup of my home LAN.
~250 is sending RTCP receiver report before ~11 starts RTP communication. I am wondering if the former is giving up on the call because of time out; and, if it is true, if there is any way to have it wait longer.
I am completely stuck about this issue and I'll welcome any input you have.
Thanks!
Yasuro
Michael Collins wrote (11/12/2010 4:43 AM):
Run your same test on FreeSWITCH but turn on sip debugging at the fs_cli: sofia global siptrace on
Then make the call and capture the output and put into new pastebin. Hopefully you'll see why the channel is already hungup when it goes to play music. -MC
2010/11/10 Yasuro <yasuro@yasuro.com <mailto:yasuro@yasuro.com>>
Hi, FreeSWITCH gurus! I need your help!
First off, I am new to FS and I am new to Internet telephony as well. Heck, I am new to the concept of NAT, UPnP, etc., so please bear with my ignorance.
I subscribe to a VoIP service at home, with which I get one DID. They supply me a VoIP adapter. Their expected usage is for you to plug in analog phones to the analog phone jacks in the VoIP adapter. However, It also has four Ethernet LAN ports and it acts as a router. You can also access it from the LAN side and register with its built-in SIP gateway.
What I would like to do is to run FS (Windows version) on one of the Windows PCs, have it register with the SIP gateway, and have it act as an AA or IVR. For testing, I am having it just play music.
When I tried the same idea with AsterikWin32, it worked just as I had hoped; it answered incoming calls automatically. However, I somehow cannot make it work with FS. I simulate incoming calls to my DID number with Skype's Sypeout. It fails after a short while with such error messages as "network error." It appears the call was never answered.
FS is assigned an extension number 7 at the gateway. When I call extension 7 from a different extension (at the gateway level, not an extension inside FS), FS does answer the call and I hear music. FS fails to answer only incoming calls from outside.
I think my FS configuration is fairly standard. I created an external SIP profile for the gateway under conf/sip_profiles/external/ and modified conf/dialplan/public/00_inbound_did.xml so incoming calls to the gateway will be transferred to an extension within FS.
FS's messages and logs, plus the result of packet captures indicate that FS /thinks /it has answered the call, and goes on to initiate media communication. I see RTP packets going from FS to the SIP gateway. What's different from AsteriskWin32's case is that there are no RTP packets coming back from the SIP gateway to FS. Turning of the firewall of the PC does not seem to change the result in any way.
For your perusal, I have created the following logs of communication between FS/AsteriskWin32 and the SIP gateway:
* AsteriskWin32's case o Summary: http://pastebin.freeswitch.org/14457 o Details: http://pastebin.freeswitch.org/14460 * FreeSWITCh's case o Summary: http://pastebin.freeswitch.org/14462 o Details: http://pastebin.freeswitch.org/14463 o Log: http://pastebin.freeswitch.org/14465
The IP address of the SIP gateway is *192.168.11.250*, and that of the PC FS/AsteriskWin32 resides in is *192.168.11.11*. My DID number is masked as ABCDEFGHIJ. I do not know if it gives you any useful information, but those files include the registration phase. /FS's log was taken at a different time/, so it does not entirely match the packet captures.
I also have the corresponding Pcap files. Please let me know if you need them.
I am not entirely sure, but I think as far as what I'd like to do is concerned, NAT is not going to be an issue, because the FS/AsteriskWin32 PC and the SIP gateway (its LAN side IP address) are on the same subnet (192.168.11/24). At this time, I do not need to access FS from the Internet.
Finally, I will give you more details about my setup, which may or may not be relevant to this issue.
My home LAN is set up this way: http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup... Please note that there are /two layers/ of NAT, and that in the inner layer, two NAT devices exist. I know it looks convoluted, but there are logical reasons for this setup.
The VoIP service provider only supports the PCMU codec. The music file I prepared for this testing is encoded in PCMU, so codecs will not be an issue.
Please do not hesitate to ask if you have any questions. Thanks for your help in advance!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Peter, that's not RTP, but RTCP. The RTCP port is always RTP+1. David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 14/11/2010 à 22:31, Peter Steinbach a écrit :
Hello Yasuro,
what I am wondering about is: Freeswitch is offering port 16670 in its SDP message of the SIP OK message, and 192.168.11.250 is trying to send RTP packets to 16671 instead. But this Freeswitch port is not open. So 192.168.11.250 closes the connection: See 217 49.351287 192.168.11.250 5005 192.168.11.11 16671 RTCP Receiver Report Source description 218 49.351369 192.168.11.11 5005 192.168.11.250 16671 ICMP Destination unreachable (Port unreachable)
-- With kind regards Peter Steinbach
Telefaks Services GmbH Theo-Geisel-Strasse 25 D 61250 Usingen, Germany mailto:lists (att) telefaks.de Internet: www.telefaks.de
Yasuro schrieb:
Michael and other FreeSWITCH gurus:
As per your instruction, I have created logs. Please take a look <http://pastebin.freeswitch.org/14479>. It includes FS's messages while it initializes itself. The VoIP adapter (SIP gateway, which also works as a router)'s IP address is *192.168.11.250* on the LAN side. That of the PC which is running FS is *192.168.11.11*. Its firewall function was turned off during this testing. The summary of packet exchange between the two during this same period is here <http://pastebin.freeswitch.org/14480>. Please see my original posting (which is included at the end of this message) for the setup of my home LAN.
~250 is sending RTCP receiver report before ~11 starts RTP communication. I am wondering if the former is giving up on the call because of time out; and, if it is true, if there is any way to have it wait longer.
I am completely stuck about this issue and I'll welcome any input you have.
Thanks!
Yasuro
Michael Collins wrote (11/12/2010 4:43 AM):
Run your same test on FreeSWITCH but turn on sip debugging at the fs_cli: sofia global siptrace on
Then make the call and capture the output and put into new pastebin. Hopefully you'll see why the channel is already hungup when it goes to play music. -MC
2010/11/10 Yasuro <yasuro@yasuro.com <mailto:yasuro@yasuro.com>>
Hi, FreeSWITCH gurus! I need your help!
First off, I am new to FS and I am new to Internet telephony as well. Heck, I am new to the concept of NAT, UPnP, etc., so please bear with my ignorance.
I subscribe to a VoIP service at home, with which I get one DID. They supply me a VoIP adapter. Their expected usage is for you to plug in analog phones to the analog phone jacks in the VoIP adapter. However, It also has four Ethernet LAN ports and it acts as a router. You can also access it from the LAN side and register with its built-in SIP gateway.
What I would like to do is to run FS (Windows version) on one of the Windows PCs, have it register with the SIP gateway, and have it act as an AA or IVR. For testing, I am having it just play music.
When I tried the same idea with AsterikWin32, it worked just as I had hoped; it answered incoming calls automatically. However, I somehow cannot make it work with FS. I simulate incoming calls to my DID number with Skype's Sypeout. It fails after a short while with such error messages as "network error." It appears the call was never answered.
FS is assigned an extension number 7 at the gateway. When I call extension 7 from a different extension (at the gateway level, not an extension inside FS), FS does answer the call and I hear music. FS fails to answer only incoming calls from outside.
I think my FS configuration is fairly standard. I created an external SIP profile for the gateway under conf/sip_profiles/external/ and modified conf/dialplan/public/00_inbound_did.xml so incoming calls to the gateway will be transferred to an extension within FS.
FS's messages and logs, plus the result of packet captures indicate that FS /thinks /it has answered the call, and goes on to initiate media communication. I see RTP packets going from FS to the SIP gateway. What's different from AsteriskWin32's case is that there are no RTP packets coming back from the SIP gateway to FS. Turning of the firewall of the PC does not seem to change the result in any way.
For your perusal, I have created the following logs of communication between FS/AsteriskWin32 and the SIP gateway:
* AsteriskWin32's case o Summary: http://pastebin.freeswitch.org/14457 o Details: http://pastebin.freeswitch.org/14460 * FreeSWITCh's case o Summary: http://pastebin.freeswitch.org/14462 o Details: http://pastebin.freeswitch.org/14463 o Log: http://pastebin.freeswitch.org/14465
The IP address of the SIP gateway is *192.168.11.250*, and that of the PC FS/AsteriskWin32 resides in is *192.168.11.11*. My DID number is masked as ABCDEFGHIJ. I do not know if it gives you any useful information, but those files include the registration phase. /FS's log was taken at a different time/, so it does not entirely match the packet captures.
I also have the corresponding Pcap files. Please let me know if you need them.
I am not entirely sure, but I think as far as what I'd like to do is concerned, NAT is not going to be an issue, because the FS/AsteriskWin32 PC and the SIP gateway (its LAN side IP address) are on the same subnet (192.168.11/24). At this time, I do not need to access FS from the Internet.
Finally, I will give you more details about my setup, which may or may not be relevant to this issue.
My home LAN is set up this way: http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup... Please note that there are /two layers/ of NAT, and that in the inner layer, two NAT devices exist. I know it looks convoluted, but there are logical reasons for this setup.
The VoIP service provider only supports the PCMU codec. The music file I prepared for this testing is encoded in PCMU, so codecs will not be an issue.
Please do not hesitate to ask if you have any questions. Thanks for your help in advance!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks David, missed the "C". But anyway, I am wondering why .250 sends a BYE right after reception of "Destination unreachable (Port unreachable)". -- With kind regards Peter Steinbach Telefaks Services GmbH Theo-Geisel-Strasse 25 D 61250 Usingen, Germany mailto:lists (att) telefaks.de Internet: www.telefaks.de David Ponzone schrieb:
Peter,
that's not RTP, but RTCP. The RTCP port is always RTP+1.
David Ponzone Direction Technique email: david.ponzone@ipeva.fr <mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr <BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com <BLOCKED::http://www.ipeva-studio.com/>
/Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. /*/IPeva/*/ décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur./ / /
Le 14/11/2010 à 22:31, Peter Steinbach a écrit :
Hello Yasuro,
what I am wondering about is: Freeswitch is offering port 16670 in its SDP message of the SIP OK message, and 192.168.11.250 is trying to send RTP packets to 16671 instead. But this Freeswitch port is not open. So 192.168.11.250 closes the connection: See 217 49.351287 192.168.11.250 5005 192.168.11.11 16671 RTCP Receiver Report Source description 218 49.351369 192.168.11.11 5005 192.168.11.250 16671 ICMP Destination unreachable (Port unreachable)
-- With kind regards Peter Steinbach
Telefaks Services GmbH Theo-Geisel-Strasse 25 D 61250 Usingen, Germany mailto:lists (att) telefaks.de <http://telefaks.de> Internet: www.telefaks.de <http://www.telefaks.de>
Yasuro schrieb:
Michael and other FreeSWITCH gurus:
As per your instruction, I have created logs. Please take a look <http://pastebin.freeswitch.org/14479>. It includes FS's messages while it initializes itself. The VoIP adapter (SIP gateway, which also works as a router)'s IP address is *192.168.11.250* on the LAN side. That of the PC which is running FS is *192.168.11.11*. Its firewall function was turned off during this testing. The summary of packet exchange between the two during this same period is here <http://pastebin.freeswitch.org/14480>. Please see my original posting (which is included at the end of this message) for the setup of my home LAN.
~250 is sending RTCP receiver report before ~11 starts RTP communication. I am wondering if the former is giving up on the call because of time out; and, if it is true, if there is any way to have it wait longer.
I am completely stuck about this issue and I'll welcome any input you have.
Thanks!
Yasuro
Michael Collins wrote (11/12/2010 4:43 AM):
Run your same test on FreeSWITCH but turn on sip debugging at the fs_cli: sofia global siptrace on
Then make the call and capture the output and put into new pastebin. Hopefully you'll see why the channel is already hungup when it goes to play music. -MC
2010/11/10 Yasuro <yasuro@yasuro.com <mailto:yasuro@yasuro.com> <mailto:yasuro@yasuro.com>>
Hi, FreeSWITCH gurus! I need your help!
First off, I am new to FS and I am new to Internet telephony as well. Heck, I am new to the concept of NAT, UPnP, etc., so please bear with my ignorance.
I subscribe to a VoIP service at home, with which I get one DID. They supply me a VoIP adapter. Their expected usage is for you to plug in analog phones to the analog phone jacks in the VoIP adapter. However, It also has four Ethernet LAN ports and it acts as a router. You can also access it from the LAN side and register with its built-in SIP gateway.
What I would like to do is to run FS (Windows version) on one of the Windows PCs, have it register with the SIP gateway, and have it act as an AA or IVR. For testing, I am having it just play music.
When I tried the same idea with AsterikWin32, it worked just as I had hoped; it answered incoming calls automatically. However, I somehow cannot make it work with FS. I simulate incoming calls to my DID number with Skype's Sypeout. It fails after a short while with such error messages as "network error." It appears the call was never answered.
FS is assigned an extension number 7 at the gateway. When I call extension 7 from a different extension (at the gateway level, not an extension inside FS), FS does answer the call and I hear music. FS fails to answer only incoming calls from outside.
I think my FS configuration is fairly standard. I created an external SIP profile for the gateway under conf/sip_profiles/external/ and modified conf/dialplan/public/00_inbound_did.xml so incoming calls to the gateway will be transferred to an extension within FS.
FS's messages and logs, plus the result of packet captures indicate that FS /thinks /it has answered the call, and goes on to initiate media communication. I see RTP packets going from FS to the SIP gateway. What's different from AsteriskWin32's case is that there are no RTP packets coming back from the SIP gateway to FS. Turning of the firewall of the PC does not seem to change the result in any way.
For your perusal, I have created the following logs of communication between FS/AsteriskWin32 and the SIP gateway:
* AsteriskWin32's case o Summary: http://pastebin.freeswitch.org/14457 o Details: http://pastebin.freeswitch.org/14460 * FreeSWITCh's case o Summary: http://pastebin.freeswitch.org/14462 o Details: http://pastebin.freeswitch.org/14463 o Log: http://pastebin.freeswitch.org/14465
The IP address of the SIP gateway is *192.168.11.250*, and that of the PC FS/AsteriskWin32 resides in is *192.168.11.11*. My DID number is masked as ABCDEFGHIJ. I do not know if it gives you any useful information, but those files include the registration phase. /FS's log was taken at a different time/, so it does not entirely match the packet captures.
I also have the corresponding Pcap files. Please let me know if you need them.
I am not entirely sure, but I think as far as what I'd like to do is concerned, NAT is not going to be an issue, because the FS/AsteriskWin32 PC and the SIP gateway (its LAN side IP address) are on the same subnet (192.168.11/24). At this time, I do not need to access FS from the Internet.
Finally, I will give you more details about my setup, which may or may not be relevant to this issue.
My home LAN is set up this way: http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup... Please note that there are /two layers/ of NAT, and that in the inner layer, two NAT devices exist. I know it looks convoluted, but there are logical reasons for this setup.
The VoIP service provider only supports the PCMU codec. The music file I prepared for this testing is encoded in PCMU, so codecs will not be an issue.
Please do not hesitate to ask if you have any questions. Thanks for your help in advance!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Peter and David, thanks for trying to help out. I did wonder about that too, Peter, but it seems to me that my VoIP adapter at 192.168.11.250 sends out an RTCP receiver report right before it ends a call. This is shown in the trace of packet exchange between AsteriskWin32 and the VoIP adapter <http://pastebin.freeswitch.org/14457>. In case you did not see my original posting, AsteriskWin32 does do what I want to achieve, i.e., automatically answers incoming calls to my DID number. I have FreeSWITCH at 192.168.11.11 register with the VoIP adapter, which is a SIP gateway provided by my SIP service provider. When I call FS's extension number from another softphone, also on the home LAN, which is also registered with the same VoIP adapter, FS answers automatically as I expect it to. The RTP steam is established between FS and the softphone directly. This part is different from incoming calls' case, where the VoIP adapter seems to act as a proxy and tries to establish an RTP stream between itself and FS. The VoIP adapter sends an ACK back to FS when FS accepts an INVITE with an OK. I'd think everything is hunky dory up to that point. What I do not get is why the VoIP adapter decides to end the call immediately after (and sends an RTCP receiver report). I am guessing it is because there is something wrong with the RTP communication that is supposed to follow. I am thinking it is either because: A. the VoIP adapter somehow couldn't send RTP packets, or B. the VoIP adapter didn't like the RTP packets that it received from FS. I don't think A. is the case. The firewall of the PC on which FS runs was turned off during testing and the VoIP adapter has no problem sending RTP packets to AsteriskWin32 on the same PC (I did not run FS and Asterisk simultaneously). Since I could not find anything particularly odd about RTP packets sent by FS, I have no idea if B. is a possibility. By the way, my home LAN is set up in a weird way (please see http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup...). Double NAT layers are understandably a concern, but since both the VoIP adapter and FS (and the softphone too) are accessible on the inner layer of NAT, this should not be a problem... I would think (Correct me if I am wrong). I do not need to and thus am not trying to access FS from the Internet. I would welcome any input. Thanks again for your help! Yasuro Peter Steinbach wrote (11/15/2010 9:01 AM):
Thanks David,
missed the "C".
But anyway, I am wondering why .250 sends a BYE right after reception of "Destination unreachable (Port unreachable)".
Hi. I am wondering how I can remove the following headers from the SIP OK messages FreeSWITCH sends in response to INVITE messages it receives from a SIP gateway: Session-Expires: 300;refresher=uac Min-SE: 120 Yes, I have read http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options and it reads like you're supposed to add relevant configuration lines to the profile of the gateway under conf/sip_profiles/external/. I added the following two lines: <param name="enable-timer" value="false"/> <param name="minimum-session-expires" value="3000"/> ... but I do not see any changes to the header lines. I must be missing something, please do let me know. If there I am using November 6 weekly git build, Windows version. At this point, I just need to remove those header lines. I will explain why below, in case you'd like to know. I subscribe to a SIP-based VoIP service. They supply you with a hardware SIP gateway/proxy/ATA. I have FS register with it as a SIP client. When a call comes in, the gateway sends an INVITE to FS, which responds with an OK. What's odd is that the gateway immediately terminates the call with a BYE right after it sends an ACK, with no explicit reason (in case you're curious, here's a log: http://pastebin.freeswitch.org/14479). I have thought about many possible reasons, but my current theory is that the gateway passes the OK to its superior, which somehow does not like what it sees and immediately decides to end the call. We all know their service is built around SIP, but it is never an advertised feature. Officially, you're only supposed to plug in analog phones, or use a small number of particular hardware IP phones and a softphone they created. Officially they do not support anything else, although they do not prohibit the use of other SIP-compliant software or devices either. So they have no obligation to adhere to the SIP standard rigidly. I think that's why they do not give you a helpful message. I want FS to work as IVR or AA. And my setup works perfectly with incoming calls through Gizmo. So now I am guessing the reason why it does not work with the other VoIP service provider is something specific to their service. A similar setup with AsteriskWin32 works fine even with this provider, so now I am trying to eliminate differences in the messages FS sends. I hope I explained myself well. Thanks for your help! Yasuro Yasuro wrote (11/15/2010 4:09 PM):
Peter and David, thanks for trying to help out.
I did wonder about that too, Peter, but it seems to me that my VoIP adapter at 192.168.11.250 sends out an RTCP receiver report right before it ends a call. This is shown in the trace of packet exchange between AsteriskWin32 and the VoIP adapter <http://pastebin.freeswitch.org/14457>. In case you did not see my original posting, AsteriskWin32 does do what I want to achieve, i.e., automatically answers incoming calls to my DID number.
I have FreeSWITCH at 192.168.11.11 register with the VoIP adapter, which is a SIP gateway provided by my SIP service provider. When I call FS's extension number from another softphone, also on the home LAN, which is also registered with the same VoIP adapter, FS answers automatically as I expect it to. The RTP steam is established between FS and the softphone directly. This part is different from incoming calls' case, where the VoIP adapter seems to act as a proxy and tries to establish an RTP stream between itself and FS.
The VoIP adapter sends an ACK back to FS when FS accepts an INVITE with an OK. I'd think everything is hunky dory up to that point. What I do not get is why the VoIP adapter decides to end the call immediately after (and sends an RTCP receiver report). I am guessing it is because there is something wrong with the RTP communication that is supposed to follow.
I am thinking it is either because: A. the VoIP adapter somehow couldn't send RTP packets, or B. the VoIP adapter didn't like the RTP packets that it received from FS. I don't think A. is the case. The firewall of the PC on which FS runs was turned off during testing and the VoIP adapter has no problem sending RTP packets to AsteriskWin32 on the same PC (I did not run FS and Asterisk simultaneously). Since I could not find anything particularly odd about RTP packets sent by FS, I have no idea if B. is a possibility.
By the way, my home LAN is set up in a weird way (please see http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup...). Double NAT layers are understandably a concern, but since both the VoIP adapter and FS (and the softphone too) are accessible on the inner layer of NAT, this should not be a problem... I would think (Correct me if I am wrong). I do not need to and thus am not trying to access FS from the Internet.
I would welcome any input. Thanks again for your help!
Yasuro
Peter Steinbach wrote (11/15/2010 9:01 AM):
Thanks David,
missed the "C".
But anyway, I am wondering why .250 sends a BYE right after reception of "Destination unreachable (Port unreachable)".
Hello! Would you tell me how you can stop FreeSWITCH from including the Remote-Party-ID header in its SIP messages? I am suspecting my SIP service provider does not like to see it in the OK messages FS sends in response to their INVITEs. I know there issip_cid_variable channel variable <http://wiki.freeswitch.org/wiki/Channel_Variables#sip_cid_type>, but setting it to none by <action application="set" data="sip_cid_type=none" /> in the 00_inbound_did.xml dialplan before transferring the incoming call to an extension does not seem to have any effect. Please advise. Thanks! Yasuro
Hmm, are you sure your ITSP is not sending a RPID in the INVITE ? David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 17/11/2010 à 11:25, Yasuro a écrit :
Hello!
Would you tell me how you can stop FreeSWITCH from including the Remote-Party-ID header in its SIP messages? I am suspecting my SIP service provider does not like to see it in the OK messages FS sends in response to their INVITEs.
I know there is sip_cid_variable channel variable, but setting it to none by <action application="set" data="sip_cid_type=none" /> in the 00_inbound_did.xml dialplan before transferring the incoming call to an extension does not seem to have any effect.
Please advise. Thanks!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yes, I am. The only header line that seems to resemble is the following: P-Called-Party-ID:<sip:ABCDEFGHIJ@192.168.11.250> where ABCDEFGHIJ is my DID number. Oddly, I do not see the same line in the INVITES from the same gateway to Express Talk (software SIP phone) and AseteriskWin32. Does this help at all? Yasuro P.S. Here's an INVITE in its entirety: INVITE sip:gw+192.168.11.250@192.168.11.100:5080 SIP/2.0 f:<sip:anonymous@anonymous.invalid>;tag=2D690025DC15F5C9001DAD62 t:<tel:0787920215;phone-context=192.168.11.250> m:<sip:09909290030970274201@192.168.11.250> Allow:INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,REFER,NOTIFY k:replaces,100rel,timer x:300 Max-Forwards:68 P-Called-Party-ID:<sip:ABCDEFGHIJ@192.168.11.250> Record-Route:<sip:192.168.11.250;lr> c:application/sdp Call-ID:78E99320A3B0D174D7C754C031078615@192.168.11.250 CSeq:1 INVITE Via:SIP/2.0/UDP 192.168.11.250:5060;branch=z9hG4bK8C863FC5D5 Content-Length:141 v=0 o=- 395453 395453 IN IP4 192.168.11.250 s=- c=IN IP4 192.168.11.250 t=0 0 m=audio 5004 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:20 David Ponzone wrote (11/17/2010 7:39 PM):
Hmm, are you sure your ITSP is not sending a RPID in the INVITE ?
David Ponzone Direction Technique email: david.ponzone@ipeva.fr <mailto:david.ponzone@ipeva.fr> tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service ClientIPeva tel: 0811 46 26 26 www.ipeva.fr <BLOCKED::http://www.ipeva.fr/> - www.ipeva-studio.com <BLOCKED::http://www.ipeva-studio.com/>
/Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. /*/IPeva/*/ décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur./ / /
Le 17/11/2010 à 11:25, Yasuro a écrit :
Hello!
Would you tell me how you can stop FreeSWITCH from including the Remote-Party-ID header in its SIP messages? I am suspecting my SIP service provider does not like to see it in the OK messages FS sends in response to their INVITEs.
I know there issip_cid_variable channel variable <http://wiki.freeswitch.org/wiki/Channel_Variables#sip_cid_type>, but setting it to none by
<action application="set" data="sip_cid_type=none" />
in the 00_inbound_did.xml dialplan before transferring the incoming call to an extension does not seem to have any effect.
Please advise. Thanks!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You've got the wrong debugs turned on. This is okay: sofia global siptrace on But this is not necessary: sofia loglevel all 9 (This just puts out tons and tons of lower-level output from the sofia stack which is only useful to someone who really knows what they're doing.) Instead, do this: console loglevel debug Then repeat your test and post the pastebin URL here. Thanks, MC On Tue, Nov 16, 2010 at 10:57 AM, Yasuro <yasuro@yasuro.com> wrote:
Hi.
I am wondering how I can remove the following headers from the SIP OK messages FreeSWITCH sends in response to INVITE messages it receives from a SIP gateway:
Session-Expires: 300;refresher=uac Min-SE: 120
Yes, I have read http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options and it reads like you're supposed to add relevant configuration lines to the profile of the gateway under conf/sip_profiles/external/. I added the following two lines:
<param name="enable-timer" value="false"/> <param name="minimum-session-expires" value="3000"/>
... but I do not see any changes to the header lines. I must be missing something, please do let me know. If there I am using November 6 weekly git build, Windows version.
At this point, I just need to remove those header lines. I will explain why below, in case you'd like to know.
I subscribe to a SIP-based VoIP service. They supply you with a hardware SIP gateway/proxy/ATA. I have FS register with it as a SIP client. When a call comes in, the gateway sends an INVITE to FS, which responds with an OK. What's odd is that the gateway immediately terminates the call with a BYE right after it sends an ACK, with no explicit reason (in case you're curious, here's a log: http://pastebin.freeswitch.org/14479). I have thought about many possible reasons, but my current theory is that the gateway passes the OK to its superior, which somehow does not like what it sees and immediately decides to end the call.
We all know their service is built around SIP, but it is never an advertised feature. Officially, you're only supposed to plug in analog phones, or use a small number of particular hardware IP phones and a softphone they created. Officially they do not support anything else, although they do not prohibit the use of other SIP-compliant software or devices either. So they have no obligation to adhere to the SIP standard rigidly. I think that's why they do not give you a helpful message.
I want FS to work as IVR or AA. And my setup works perfectly with incoming calls through Gizmo. So now I am guessing the reason why it does not work with the other VoIP service provider is something specific to their service. A similar setup with AsteriskWin32 works fine even with this provider, so now I am trying to eliminate differences in the messages FS sends.
I hope I explained myself well. Thanks for your help!
Yasuro
Yasuro wrote (11/15/2010 4:09 PM):
Peter and David, thanks for trying to help out.
I did wonder about that too, Peter, but it seems to me that my VoIP adapter at 192.168.11.250 sends out an RTCP receiver report right before it ends a call. This is shown in the trace of packet exchange between AsteriskWin32 and the VoIP adapter <http://pastebin.freeswitch.org/14457>. In case you did not see my original posting, AsteriskWin32 does do what I want to achieve, i.e., automatically answers incoming calls to my DID number.
I have FreeSWITCH at 192.168.11.11 register with the VoIP adapter, which is a SIP gateway provided by my SIP service provider. When I call FS's extension number from another softphone, also on the home LAN, which is also registered with the same VoIP adapter, FS answers automatically as I expect it to. The RTP steam is established between FS and the softphone directly. This part is different from incoming calls' case, where the VoIP adapter seems to act as a proxy and tries to establish an RTP stream between itself and FS.
The VoIP adapter sends an ACK back to FS when FS accepts an INVITE with an OK. I'd think everything is hunky dory up to that point. What I do not get is why the VoIP adapter decides to end the call immediately after (and sends an RTCP receiver report). I am guessing it is because there is something wrong with the RTP communication that is supposed to follow.
I am thinking it is either because: A. the VoIP adapter somehow couldn't send RTP packets, or B. the VoIP adapter didn't like the RTP packets that it received from FS. I don't think A. is the case. The firewall of the PC on which FS runs was turned off during testing and the VoIP adapter has no problem sending RTP packets to AsteriskWin32 on the same PC (I did not run FS and Asterisk simultaneously). Since I could not find anything particularly odd about RTP packets sent by FS, I have no idea if B. is a possibility.
By the way, my home LAN is set up in a weird way (please see http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup...). Double NAT layers are understandably a concern, but since both the VoIP adapter and FS (and the softphone too) are accessible on the inner layer of NAT, this should not be a problem... I would think (Correct me if I am wrong). I do not need to and thus am not trying to access FS from the Internet.
I would welcome any input. Thanks again for your help!
Yasuro
Peter Steinbach wrote (11/15/2010 9:01 AM):
Thanks David,
missed the "C".
But anyway, I am wondering why .250 sends a BYE right after reception of "Destination unreachable (Port unreachable)".
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
As per your instruction, Michael, here's a new log: http://pastebin.freeswitch.org/14523 Please let me know if you need other info. Thanks. Yasuro Michael Collins wrote (11/18/2010 7:48 AM):
You've got the wrong debugs turned on. This is okay: sofia global siptrace on
But this is not necessary: sofia loglevel all 9 (This just puts out tons and tons of lower-level output from the sofia stack which is only useful to someone who really knows what they're doing.)
Instead, do this: console loglevel debug
Then repeat your test and post the pastebin URL here.
Thanks, MC
On Tue, Nov 16, 2010 at 10:57 AM, Yasuro <yasuro@yasuro.com <mailto:yasuro@yasuro.com>> wrote:
Hi.
I am wondering how I can remove the following headers from the SIP OK messages FreeSWITCH sends in response to INVITE messages it receives from a SIP gateway:
Session-Expires: 300;refresher=uac Min-SE: 120
Yes, I have read http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options and it reads like you're supposed to add relevant configuration lines to the profile of the gateway under conf/sip_profiles/external/. I added the following two lines:
<param name="enable-timer" value="false"/> <param name="minimum-session-expires" value="3000"/>
... but I do not see any changes to the header lines. I must be missing something, please do let me know. If there I am using November 6 weekly git build, Windows version.
At this point, I just need to remove those header lines. I will explain why below, in case you'd like to know.
I subscribe to a SIP-based VoIP service. They supply you with a hardware SIP gateway/proxy/ATA. I have FS register with it as a SIP client. When a call comes in, the gateway sends an INVITE to FS, which responds with an OK. What's odd is that the gateway immediately terminates the call with a BYE right after it sends an ACK, with no explicit reason (in case you're curious, here's a log: http://pastebin.freeswitch.org/14479). I have thought about many possible reasons, but my current theory is that the gateway passes the OK to its superior, which somehow does not like what it sees and immediately decides to end the call.
We all know their service is built around SIP, but it is never an advertised feature. Officially, you're only supposed to plug in analog phones, or use a small number of particular hardware IP phones and a softphone they created. Officially they do not support anything else, although they do not prohibit the use of other SIP-compliant software or devices either. So they have no obligation to adhere to the SIP standard rigidly. I think that's why they do not give you a helpful message.
I want FS to work as IVR or AA. And my setup works perfectly with incoming calls through Gizmo. So now I am guessing the reason why it does not work with the other VoIP service provider is something specific to their service. A similar setup with AsteriskWin32 works fine even with this provider, so now I am trying to eliminate differences in the messages FS sends.
I hope I explained myself well. Thanks for your help!
Yasuro
Yasuro wrote (11/15/2010 4:09 PM):
Peter and David, thanks for trying to help out.
I did wonder about that too, Peter, but it seems to me that my VoIP adapter at 192.168.11.250 sends out an RTCP receiver report right before it ends a call. This is shown in the trace of packet exchange between AsteriskWin32 and the VoIP adapter <http://pastebin.freeswitch.org/14457>. In case you did not see my original posting, AsteriskWin32 does do what I want to achieve, i.e., automatically answers incoming calls to my DID number.
I have FreeSWITCH at 192.168.11.11 register with the VoIP adapter, which is a SIP gateway provided by my SIP service provider. When I call FS's extension number from another softphone, also on the home LAN, which is also registered with the same VoIP adapter, FS answers automatically as I expect it to. The RTP steam is established between FS and the softphone directly. This part is different from incoming calls' case, where the VoIP adapter seems to act as a proxy and tries to establish an RTP stream between itself and FS.
The VoIP adapter sends an ACK back to FS when FS accepts an INVITE with an OK. I'd think everything is hunky dory up to that point. What I do not get is why the VoIP adapter decides to end the call immediately after (and sends an RTCP receiver report). I am guessing it is because there is something wrong with the RTP communication that is supposed to follow.
I am thinking it is either because: A. the VoIP adapter somehow couldn't send RTP packets, or B. the VoIP adapter didn't like the RTP packets that it received from FS. I don't think A. is the case. The firewall of the PC on which FS runs was turned off during testing and the VoIP adapter has no problem sending RTP packets to AsteriskWin32 on the same PC (I did not run FS and Asterisk simultaneously). Since I could not find anything particularly odd about RTP packets sent by FS, I have no idea if B. is a possibility.
By the way, my home LAN is set up in a weird way (please see http://i139.photobucket.com/albums/q302/starplatina/For%20Blogs/HomeLANSetup...). Double NAT layers are understandably a concern, but since both the VoIP adapter and FS (and the softphone too) are accessible on the inner layer of NAT, this should not be a problem... I would think (Correct me if I am wrong). I do not need to and thus am not trying to access FS from the Internet.
I would welcome any input. Thanks again for your help!
Yasuro
Peter Steinbach wrote (11/15/2010 9:01 AM):
Thanks David,
missed the "C".
But anyway, I am wondering why .250 sends a BYE right after reception of "Destination unreachable (Port unreachable)".
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Just to be clear, I am currently trying to figure out a way to stop FreeSWITCH from including the Remote-Party-ID header in its SIP messages. I am suspecting my SIP service provider does not like to see it in the OK messages FS sends in response to their INVITEs. It is reported to be the case with Halonet <http://wiki.freeswitch.org/wiki/Provider_Configuration:_Halonet>. I know there issip_cid_variable channel variable <http://wiki.freeswitch.org/wiki/Channel_Variables#sip_cid_type>, but setting it to none by <action application="set" data="sip_cid_type=none" /> in the 00_inbound_did.xml dialplan before transferring the incoming call to an extension does not seem to have any effect. Here is a log: http://pastebin.freeswitch.org/14523 Please advise. Thanks! Yasuro Yasuro wrote (11/18/2010 4:59 PM):
As per your instruction, Michael, here's a new log: http://pastebin.freeswitch.org/14523
Please let me know if you need other info.
Thanks.
Yasuro
Hi! Could you tell me how you can change the To: SIP header from "tel:' format to "sip:"? I found a thread on the mailing list about someone who was trying to do the opposite <http://freeswitch-users.2379917.n2.nabble.com/How-to-change-SIP-To-header-td5300587.html> and it mentions sip_to_uri variable, but just as Mr. David Ponzone wrote there, setting/exporting it before transferring an incoming call through a SIP ITSP does not seem to have any effect. What I am trying to do is to have FreeSWITCH act as IVR/AA to incoming calls through ITSPs. My setup works fine with Gizmo but not with a Japanese ITSP. I figured the ITSP's SIP server does not conform to the standards entirely, and does not understand or like something FS sends to it, to which it responds by BYE-ing the call without giving any reason. So I have been doing a lot of trial and error, and now I am reasonably certain the header above is the culprit. Since I could not figure out how to change it by myself, I placed AsterikWin32 as a middleman, and FS responded perfectly. This worked, I believe, because AsteriskWin32 uses the sip: scheme, not the tel: scheme. Now I have a working setup, but I'd very much like to get AsteriskWin32 out of the way. Your help will be highly appreciated! Yasuro
Could someone please help me with this? I am completely stuck and need your help desperately... Yasuro wrote (11/19/2010 8:02 PM):
Hi!
Could you tell me how you can change the To: SIP header from "tel:' format to "sip:"? I found a thread on the mailing list about someone who was trying to do the opposite <http://freeswitch-users.2379917.n2.nabble.com/How-to-change-SIP-To-header-td5300587.html> and it mentions sip_to_uri variable, but just as Mr. David Ponzone wrote there, setting/exporting it before transferring an incoming call through a SIP ITSP does not seem to have any effect.
What I am trying to do is to have FreeSWITCH act as IVR/AA to incoming calls through ITSPs. My setup works fine with Gizmo but not with a Japanese ITSP. I figured the ITSP's SIP server does not conform to the standards entirely, and does not understand or like something FS sends to it, to which it responds by BYE-ing the call without giving any reason.
So I have been doing a lot of trial and error, and now I am reasonably certain the header above is the culprit. Since I could not figure out how to change it by myself, I placed AsterikWin32 as a middleman, and FS responded perfectly. This worked, I believe, because AsteriskWin32 uses the sip: scheme, not the tel: scheme.
Now I have a working setup, but I'd very much like to get AsteriskWin32 out of the way. Your help will be highly appreciated!
Yasuro
Yasuro, Try the IRC channel (#freeswitch on irc.freenode.net) for real-time help, you'll most likely get a faster answer there. -- MM. On Sun, Nov 21, 2010 at 10:00, Yasuro <yasuro@yasuro.com> wrote:
Could someone please help me with this? I am completely stuck and need your help desperately...
Yasuro wrote (11/19/2010 8:02 PM):
Hi!
Could you tell me how you can change the To: SIP header from "tel:' format to "sip:"? I found a thread on the mailing list about someone who was trying to do the opposite<http://freeswitch-users.2379917.n2.nabble.com/How-to-change-SIP-To-header-td5300587.html>and it mentions sip_to_uri variable, but just as Mr. David Ponzone wrote there, setting/exporting it before transferring an incoming call through a SIP ITSP does not seem to have any effect.
What I am trying to do is to have FreeSWITCH act as IVR/AA to incoming calls through ITSPs. My setup works fine with Gizmo but not with a Japanese ITSP. I figured the ITSP's SIP server does not conform to the standards entirely, and does not understand or like something FS sends to it, to which it responds by BYE-ing the call without giving any reason.
So I have been doing a lot of trial and error, and now I am reasonably certain the header above is the culprit. Since I could not figure out how to change it by myself, I placed AsterikWin32 as a middleman, and FS responded perfectly. This worked, I believe, because AsteriskWin32 uses the sip: scheme, not the tel: scheme.
Now I have a working setup, but I'd very much like to get AsteriskWin32 out of the way. Your help will be highly appreciated!
Yasuro
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You can't change it like that its an inbound invite.. go yell at your provider. /b On Nov 22, 2010, at 5:34 PM, mm_202 wrote:
Yasuro,
Try the IRC channel (#freeswitch on irc.freenode.net) for real-time help, you'll most likely get a faster answer there.
-- MM.
participants (6)
-
Brian West
-
David Ponzone
-
Michael Collins
-
mm_202
-
Peter Steinbach
-
Yasuro