Hi Alex Thanks so much for the reply. Is there anything that we could do perhaps that is a more creative solution, for instance not passing the re-invite all the way to the softphone and just responding from the kamailio box handling the call? We tried this as well actually, but we didn't get it to work. We just sent a 200 ok from the kamailio box, no sdp or anything on the packet since we sent it with just send_reply and the carrier just sent a bye. Hopefully there is something clever we could do to correct the problem, it is preventing us from using alot of our carriers since the re-invite breaks our clients softphones. Thanks again for the assistance. All the best. Will Ferrer On Wed, Feb 18, 2015 at 6:07 PM, Alex Balashov <abalashov(a)evaristesys.com> wrote:

Using a B2BUA would possibly be a solution. --FC Sent from my 6 plus

On Thursday 19 February 2015 03:44:25 Will Ferrer wrote: What kind of reInvites are this? If they are session timer related, you could try to remove any support for them in kamailio if disabling them on the client doesn't work. -- Telefoon: 088 0100 700 Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024

Some carriers require session timers -- even if you refuse them in Asterisk\Freeswitch\etc, the call will disconnect when the timer fires off. I wouldn't rely on this as a possible solution in this situation. Michael -----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Eric Koome Sent: Thursday, February 19, 2015 8:36 AM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Re-invites from carrier breaks the call If session timers, you can accept or refuse in UAS. Eg asterisk peer settings : session-timer = accept | refuse | originate. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 19 Feb 2015, at 15:44, Michael Young <myoung(a)redmonsters.net> wrote: The standard is written in a way that even if the other party does not use SIP Session timers, you can still do it one-sided. It's a feature, not a bug. I am more concerned over the phones that doesn't accept a plain re-invite. /O

Well ... kamailio is a proxy (not a B2BUA), and in dialog requests should not point at the proxy. If you are paranoid about it, then you can alter signalling by mangling and de-mangling the Contact header for requests and reply to achieve that. Regards, Ovidiu Sas On Thu, Feb 19, 2015 at 12:59 PM, Andres <andres(a)telesip.net> wrote: -- VoIP Embedded, Inc. http://www.voipembedded.com

Hi All Wow, thanks so much for the conversation on sorting this out. I think you are right, it is likely a session timer issue. I found this tag on the 200 ok from the carrier: Session-Expires: 300;refresher=uas It may not help anything but I would like to try setting the session-timer = refuse as Michael suggested. I did a search for how to do this and came up empty, didn't see in the SST module. I think I may be missing something simple. Could any one tell me how to set this up? Thanks again to every one. All the best. Will Ferrer Switchsoft On Thu, Feb 19, 2015 at 10:10 AM, Alex Balashov <abalashov(a)evaristesys.com> wrote:

Hi Alex In the test case I have right now we send the carrier an invite. Our invite to the carrier doesn't have either the required or the supported headers. There 200 ok however has the following supported header: Supported: timer, path, replaces Thanks again for the assistance. All the best. Will On Thu, Feb 19, 2015 at 3:17 PM, Alex Balashov <abalashov(a)evaristesys.com> wrote:

On 02/19/2015 06:26 PM, Alex Balashov wrote: Sorry: if(is_present_hf("Supported")) -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

Hi Alex Ok, not the 200 ok from the carrier from the initial invite has the supported heard, but it is stripped by the first box that receives it in our system. The carrier still sends the second invite however. Is there any way we can signal to the carrier not to send the second invite -- perhaps using the session-timer = refuse method that Michael mentioned? Thanks again for all the assistance. Will On Thu, Feb 19, 2015 at 3:28 PM, Will Ferrer <will.ferrer(a)switchsoft.com> wrote:

Hi Alex Yeah I think we may out of luck. Do you know how to send the session-timer = refuse flag to try though? I didn't see how to do it looking at the SST module. I hope all is going well with you and thanks again for your help. All the best. Will On Thu, Feb 19, 2015 at 4:15 PM, Alex Balashov <abalashov(a)evaristesys.com> wrote:

Hi Cartsten and Alex Thanks very much for the advice. I knew could throw in and remove headers from the config but I was hoping for a cleaner way of handling it with a module or something along those lines. That said though I didn't see anything here https://www.rfc-editor.org/rfc/rfc4028.txt about a header that lets the other end know you are refusing the session timer. It seems that if I didn't pass it in the supported header then the carrier shouldn't be sending me the timer refreshes anyway. At this point I have 2 ideas of things to try and I was wondering if you had any thoughts about them. 1) If you can't beat em join em -- It occurs to me that if I configure the sst module my self ( http://www.opensips.org/html/docs/modules/devel/sst.html#id293440), and start sending session timers to the carrier, instead of them sending them to me, then I can probably get around the issue of having softphones that don't support the session timer. 2) I have tested the issue in lin phone and my partner has tested it in jitsi. Is there another softphone that you could recommend for us and our clients that would be able to support this feature? Thanks for all your invaluable advice. All the best. Will Ferrer Switchsoft On Fri, Feb 20, 2015 at 3:15 AM, Carsten Bock <carsten(a)ng-voice.com> wrote:

Hi Alex Please see my responses below. On Fri, Feb 20, 2015 at 4:28 PM, Alex Balashov <abalashov(a)evaristesys.com> wrote: Oh yes, I noted it there as well and then saw it also in the document I referenced. Thank you for the information. My apologizes, my google search grabbed me the wrong project. The real one is here, incase any one is referencing this thread: http://www.kamailio.org/docs/modules/3.1.x/modules_k/sst.html I see what you mean. Perhaps what I could do with the module is set a long minimum timeout, long enough that it would allow our calls to complete before the re-invite occurs. A messy solution but might work in a pinch. Ok thank you for the advice. We will start testing what softphones we can find that support the functionality. I hope all is going well with you. All the best. Will

Hi Alex Thanks for the great analyse, see my comments below. I will send you some sip captures as well. On Fri, Feb 20, 2015 at 4:53 PM, Alex Balashov &lt;abalashov(a)evaristesys.com&gt; wrote: Hehe, yes, which is why I will start looking for a softphone that doesn't have the issue, but since we can't guaranteed that all our clients use compliant soft phones and networks I was hoping maybe a band aid would suffice. The 200 ok from softphone after the second invite does not have a record route for the softphone this what I thought was the problem but after reading the rest of your post I think it's another issue entirely. Ah, well this piece of info points to another problem which may be the actual issue. So what you are saying is that the final hop that ack makes on it's way back should be made via the request uri of the ack. After reading this I see that the request uri of the ack coming back from the carrier is wrong. It has the outside of the softphone as it's target with the alias of our sbc box. Looking at what is happening I found the following: 1) The softphone sends an invite with the contact set to it's inside ip. 2) We send a correct contact with the inside ip of the phone and an alias of the outside ip of the softphone. This gets through both our dispatcher box and our call processing box out to the carrier. 3) All the messages looking good and latter down the line the carrier sends back it's 200 ok. 4) This is where things start going down hill. Our softphone sends an ack, but for some reason this ack has a contact header which contains just the softphones outside ip, instead of it's inside ip as it did in the softphones first invite. 5) The re invite comes in from the carrier, it's RURI looks good, pointed at the softphone with the right alias. 6) Softphone sends a 200 ok, with just the outside ip of the softphone as the contact (which is likely the cause of the problem). 7) Our call processing box mistakenly adds the ip of the dispatcher box to the contact as the alias for the outside ip of the softphone and this gets passed to the carrier. 8) The carriers RURI in the ack that has the outside of the softphone and the dispatcher box as it's alias. I had apparently mistakenly understood that the 200 ok needed to have the softphone in the record route. The 200 ok coming from the softphone in response to the second invite does have a record route header but it has just the dispatcher box and the call processing box. It looks like I had misdiagnosed the problem and your well put together explanation pointed me in the direction of what is likely the real problem. I still don't know what to do for a solution however. Thanks again for your in valuable assistance. I hope this message finds you well. Will On Fri, Feb 20, 2015 at 4:53 PM, Alex Balashov &lt;abalashov(a)evaristesys.com&gt; wrote: > On 02/20/2015 07:39 PM, Will Ferrer wrote: > > Perhaps what I could do with the module is set a long minimum timeout, >> long enough that it would allow our calls to complete before the >> re-invite occurs. A messy solution but might work in a pinch. >> > > Perhaps. But again, I would say you are solving the wrong problem > entirely. :-) Your initial complaint was: > > "This causes the softphone to keep sending 200 oks since it > never gets the ack. > > This is the REAL problem, and that's the problem that should be solved. > > To clarify: > > When an initial INVITE from A to B is routed through a record-routing > proxy P, the proxy adds a Record-Route header containing its own IP address > to the INVITE before relaying it. That is: > > INVITE sip:foo@B SIP/2.0 > ... > Contact: <sip:myself@A:5060> > Record-Route: <sip:P;lr=on> > > The UAS receiving this INVITE is supposed to copy this Record-Route > header, verbatim, into the 200 OK response to that INVITE: > > SIP/2.0 200 OK > ... > Contact: <sip:me@B:5060> > Record-Route: <sip:P;lr=on> > > This step causes the UAC that sent the initial INVITE to also be aware of > the Record-Route set. > > Subsequent sequential (in-dialog requests having a to-tag) sent from > EITHER party to the other, including end-to-end ACKs for 2xx responses, > reinvites, BYEs, et cetera, MUST have the following attributes: > > 1) Route header whose value is equivalent to the Record-Route set added by > the proxy, e.g. > > Route: <sip:P;lr=on> > This statement is also not a correct diagnosis: > > "the 200 ok does not have the softphones ip in the record route" > > ... nor should it. The proxy's IP, not the softphone's IP, should be in > the Route set. > > -- Alex > > > > > -- > Alex Balashov - Principal > Evariste Systems LLC > 235 E Ponce de Leon Ave > Suite 106 > Decatur, GA 30030 > United States > > Tel: +1-678-954-0670 > Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >