491 Request Pending causes Disconnect of both legs
Strange issue I am not 100% sure that this is the correct way to handle the transaction I have a client that calls a PSTN number the calls flow is Meta Switch --> FreeSwitch --> Carrier (Meta Switch) call set's up correctly however during the re-invite process for session timers the client's Meta switch sends an invite however ms after the client sends the invite so does the carrier resulting in 491 glare on the FreeSwitch box at this point FreeSwitch disconnects both calls. Clients initial invite requested Session Timers UAC however on the response from the carrier they did not include that in the response so they feel that they are not allowing the client to be in control of the session timers. My question is in the case of 491's being generated from both leg's of the call because now both have open dialogs should freeswitch disconnect the call like it's doing or back off by allowing the 491's to pass to each leg and allow the end points to work out the dialog. (carrier seems to think that's what should happen)
Since FS is not a proxy, you may need to disable session timers. But I am not sure if seeing the session timer stuff in the packets won't kick them back in or get them to refuse them. We don't put tons of effort into emulating a proxy since it was the SIP implementors who invented all the crazy rules and we fall into the category of b2bua and happen to do a few proxy-ish things. On Tue, Oct 23, 2012 at 1:32 PM, Mike Burlingame <mike.burlingame@me.com>wrote:
Strange issue I am not 100% sure that this is the correct way to handle the transaction I have a client that calls a PSTN number the calls flow is Meta Switch --> FreeSwitch --> Carrier (Meta Switch) call set's up correctly however during the re-invite process for session timers the client's Meta switch sends an invite however ms after the client sends the invite so does the carrier resulting in 491 glare on the FreeSwitch box at this point FreeSwitch disconnects both calls.
Clients initial invite requested Session Timers UAC however on the response from the carrier they did not include that in the response so they feel that they are not allowing the client to be in control of the session timers.
My question is in the case of 491's being generated from both leg's of the call because now both have open dialogs should freeswitch disconnect the call like it's doing or back off by allowing the 491's to pass to each leg and allow the end points to work out the dialog. (carrier seems to think that's what should happen)
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
This sounds suspiciously similar to http://jira.freeswitch.org/browse/FS-4754 - Phil -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/491-Request-Pending-causes-Dis... Sent from the freeswitch-users mailing list archive at Nabble.com.
participants (3)
-
Anthony Minessale
-
Mike Burlingame
-
PhilQ