I could notice it is missing the ACK package from your PEER. Maybe its sending it to the wrong place, maybe its not sending it at all. FreeSWITCH will retry 200 OK over and over 'cause it expects an ACK in order to continue. here are some tips: Enable sip trace on the PEER side to check whether its sending ACK or not. Compare 200 OK (SDP) from FreeSWITCH in each scenario. Maybe there are differences between them. On Wed, Feb 11, 2015 at 5:05 PM, Ben Hood <0x6e6562@gmail.com> wrote:
I think you may well have a point.
I've spent days on this issue and I'm beginning to narrow it down by breaking the bridging down into the individual legs. I've also been able to establish RTP flow with the same originator by proxying the INVITE to a non-FS user agent (i.e. a phone registered with Kamailio).
I didn't want to leave this post dangling without a some kind of closure, so I thought I'd just post this status update.
On Tue, Feb 10, 2015 at 8:33 PM, Michael Jerris <mike@jerris.com> wrote:
I doubt it has anything to do with 180vs183. Check for nat issues in the trace that isn't working.
On Feb 10, 2015, at 2:55 PM, Ben Hood <0x6e6562@gmail.com> wrote:
Hi all,
I'm wondering what influences Freeswitch's signalling response when it responds to an INVITE.
In some instances it appears to follow this sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 183 (SDP) <- FS Peer <- 200 (SDP) <- FS Peer -> ACK -> FS
Which leads to a successful bridge between two legs.
But in other instances it appears to follow the sequence:
Peer -> INVITE (SDP) -> FS Peer <- 100 <- FS Peer <- 180 (SDP) <- FS Peer <- 200 (SDP) <- FS (1st attempt) Peer <- 200 (SDP) <- FS (2nd attempt) .... Peer <- 200 (SDP) <- FS (nth attempt) ....timeout
I'm not 100% sure whether the remote peer (itself a SIP trunk) doesn't like the 100/180/200 sequence (as opposed to 100/183/200), so I need to find that out for myself.
But I am wondering what factors influence Freeswitch's decision of what sequence signals to send in response to an INVITE.
Any pointers appreciated,
Ben
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.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
-- Atenciosamente, Lucas Castro