Re: [SR-Users] Kamailio not increasing cseq

Daniel, Any further Help you can give me? Regards, Camila *From:* Camila Troncoso [mailto:ctroncoso@redvoiss.net] *Sent:* jueves, 21 de febrero de 2013 9:52 *To:* &#39;miconda(a)gmail.com&#39;com'; 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List' *Subject:* RE: [SR-Users] Kamailio not increasing cseq Hi Daniel, In deed the Ruri is the only difference with the second invite. For the first Invite, I received an “503 Service unavailable” from the gateway , it goues trough the SBC and it is pass to the LCR so it reroutes the call to the second gateway in the cloud. I asked in FreeSWITCH forum for this issue and they said that the problem is Cseq not increasing, Freeswitch doesn’t take Ruri as compare. Regards, Camila *From:* sr-users-bounces(a)lists.sip-router.org [ mailto:sr-users-bounces@lists.sip-router.org<sr-users-bounces@lists.sip-router.org>] *On Behalf Of *Daniel-Constantin Mierla *Sent:* jueves, 21 de febrero de 2013 5:08 *To:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List *Subject:* Re: [SR-Users] Kamailio not increasing cseq Hello, On 2/20/13 7:44 PM, Camila Troncoso wrote: Hi all, I’m working for a while with Kamailio+Freeswitch as SBC. I have this structure: * * When I make a call from one client connected to LCR, it is route to my SBC and afterwards to his destiny in the cloud passing though a gateway. When the destiny is unreachable, the LCR reroutes the call to another gateway. Sometimes the LCR send this retry again to the SBC , because the second gateway is also in the cloud, but when this happens, FreeSWITCH answer with : “482 Request merged” because it detects that is the same call. This is because the second INVITE has the same Call-ID and same Cseq. Kamailio *is not* increasing CSeq. Is there a way to resolve this? it is a second branch, the top via header of the second invite should have a different branch parameter than the previous one. Freeswitch should detect that and handle it as a separate branch of the call, too. Try changing the r-uri a bit and see if works (e.g., set a prefix that you remove it if set), as an workaround. Also, is the CANCEL sent to Freeswitch for first branch? Or is Freeswitch sending a negative reply? Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin - http://conference.kamailio.com -