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@evaristesys.com wrote:

Kamailio cannot correct this. This is an endpoint issue. The whole point of Record-Route is to hairpin sequential requests (and indeed, their replies) through the proxy. The endpoints need to comply by affixing the correct Route header to the end-to-end ACK.

-- Sent from my BlackBerry. Please excuse errors and brevity. *From: *Will Ferrer *Sent: *Wednesday, February 18, 2015 9:01 PM *To: *Kamailio (SER) - Users Mailing List *Reply To: *Kamailio (SER) - Users Mailing List *Subject: *[SR-Users] Re-invites from carrier breaks the call

Hi All

We have any issue with re invites coming from the carrier.

When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone.

This causes the softphone to keep sending 200 oks since it never gets the ack.

Eventually the softphone gets tired of sending 200 oks and sends a bye.

Is there any way that Kamailio can help me correct for this, or do we need to have our clients use different softphones? If it has to be handled via softphones is there even a softphone that can account for this?

Thanks for all your assistance in advance.

All the best.

Will Ferrer

Switchsoft

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Using a B2BUA would possibly be a solution.

--FC Sent from my 6 plus

On Feb 19, 2015, at 05:12, Alex Balashov abalashov@evaristesys.com wrote:

‎Hi Will,

Unfortunately, there's not a clever workaround at your disposal here, of all scenarios. The SDP payload in the 200 OK must mimic that endpoint's previous SDP answer in order for there to be media continuity. There's just a whole lot of state you can't keep spoof in Kamailio.

No, alas, it's one of those cases where basic SIP compliance issues in the endpoints really must be fixed. Sorry.

-- Sent from my BlackBerry. Please excuse errors and brevity. From: Will Ferrer Sent: Wednesday, February 18, 2015 9:44 PM To: Kamailio (SER) - Users Mailing List Reply To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Re-invites from carrier breaks the call

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@evaristesys.com wrote: Kamailio cannot correct this. This is an endpoint issue. The whole point of Record-Route is to hairpin sequential requests (and indeed, their replies) through the proxy. The endpoints need to comply by affixing the correct Route header to the end-to-end ACK.

-- Sent from my BlackBerry. Please excuse errors and brevity. From: Will Ferrer Sent: Wednesday, February 18, 2015 9:01 PM To: Kamailio (SER) - Users Mailing List Reply To: Kamailio (SER) - Users Mailing List Subject: [SR-Users] Re-invites from carrier breaks the call

Hi All

We have any issue with re invites coming from the carrier.

When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone.

This causes the softphone to keep sending 200 oks since it never gets the ack.

Eventually the softphone gets tired of sending 200 oks and sends a bye.

Is there any way that Kamailio can help me correct for this, or do we need to have our clients use different softphones? If it has to be handled via softphones is there even a softphone that can account for this?

Thanks for all your assistance in advance.

All the best.

Will Ferrer

Switchsoft

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On Thursday 19 February 2015 03:44:25 Will Ferrer wrote:

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.

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.

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.

On 19 Feb 2015, at 14:26, Daniel Tryba d.tryba@pocos.nl wrote:

...

On Thursday 19 February 2015 03:44:25 Will Ferrer wrote: 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.

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@pocos.nl | Service: servicedesk@pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@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@redmonsters.net wrote:

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.

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

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.

...

On 19 Feb 2015, at 14:26, Daniel Tryba d.tryba@pocos.nl wrote:

...

On Thursday 19 February 2015 03:44:25 Will Ferrer wrote: 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.

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@pocos.nl | Service: servicedesk@pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@telesip.net wrote:

On 2/18/15 9:44 PM, Will Ferrer wrote:

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.

We have struggled with this issue ourselves. The problem was that we did not want our SIP server to behave like an open relay. We were seeing that the session-timer Re-Invites have a Request-URI with the IP of the other endpoint instead of the Proxy. If the SIP server is an open relay then no problem, but ours is not so the config file was very strict and dropped the Re-Invite (since the Request-URI had an external IP) thus dropping the call. The config file could be enhanced by testing for has_totag() since the Re-Invite has the totag but an original Invite does not, but the hacker could put a bogus totag and make calls so its more secure to leave it this way. We ended up disabling session-timers at some our clients PBXs. Its always a balancing act between convenience/services and more security. We chose more security.

All the best.

Will Ferrer

On Wed, Feb 18, 2015 at 6:07 PM, Alex Balashov abalashov@evaristesys.com wrote:

...

Kamailio cannot correct this. This is an endpoint issue. The whole point of Record-Route is to hairpin sequential requests (and indeed, their replies) through the proxy. The endpoints need to comply by affixing the correct Route header to the end-to-end ACK.

-- Sent from my BlackBerry. Please excuse errors and brevity. *From: *Will Ferrer *Sent: *Wednesday, February 18, 2015 9:01 PM *To: *Kamailio (SER) - Users Mailing List *Reply To: *Kamailio (SER) - Users Mailing List *Subject: *[SR-Users] Re-invites from carrier breaks the call

Hi All

We have any issue with re invites coming from the carrier.

When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone.

This causes the softphone to keep sending 200 oks since it never gets the ack.

Eventually the softphone gets tired of sending 200 oks and sends a bye.

Is there any way that Kamailio can help me correct for this, or do we need to have our clients use different softphones? If it has to be handled via softphones is there even a softphone that can account for this?

Thanks for all your assistance in advance.

All the best.

Will Ferrer

Switchsoft

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Technical Supporthttp://www.cellroute.net

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@evaristesys.com wrote:

Hi,

On 02/19/2015 12:59 PM, Andres wrote:

We have struggled with this issue ourselves. The problem was that we

...

did not want our SIP server to behave like an open relay. We were seeing that the session-timer Re-Invites have a Request-URI with the IP of the other endpoint instead of the Proxy. If the SIP server is an open relay then no problem, but ours is not so the config file was very strict and dropped the Re-Invite (since the Request-URI had an external IP) thus dropping the call. The config file could be enhanced by testing for has_totag() since the Re-Invite has the totag but an original Invite does not, but the hacker could put a bogus totag and make calls so its more secure to leave it this way. We ended up disabling session-timers at some our clients PBXs. Its always a balancing act between convenience/services and more security. We chose more security.

From a SIP point of view, this is a strange position to take. An "open relay" is an idea that normally applies to the unrestricted relay of _initial_ requests to foreign domains. Requests flowing within a dialog (i.e. loose-routed) are _supposed_ to have an RURI pointing to the endpoint's domain: this is known as the "remote target" of a dialog, and is set by the Contact URI of both dialog parties.

I suppose it's true that one could compel your proxy to relay a sequential request (like a reinvite) to any domain by including a Route header and a To-tag, but what effect would this have on the far-end UA? It would not match the spoofed request to an existing dialog.

-- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@evaristesys.com wrote:

Will,

Can we see the Required and/or Supported headers of both

1. The initial INVITE
2. The 200 OK response to that initial INVITE?

Thanks,

-- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 02/19/2015 06:26 PM, Alex Balashov wrote:

onreply_route[MAIN_REPLY] {
   if(t_check_status("200")) {
      if_is_present_hf("Supported"))

Sorry:

if(is_present_hf("Supported"))

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@switchsoft.com wrote:

Hi Alex

Thanks so much.

I will try it right now.

All the best.

Will

On Thu, Feb 19, 2015 at 3:27 PM, Alex Balashov abalashov@evaristesys.com wrote:

...

On 02/19/2015 06:26 PM, Alex Balashov wrote:

 onreply_route[MAIN_REPLY] {

...

   if(t_check_status("200")) {
      if_is_present_hf("Supported"))

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/

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@evaristesys.com wrote:

You can try it, but if they shove SST reinvites down your throat despite no indicated support for them from the client, or the client sends SST headers despite no indicated support from the carrier, there are deeper-seated fundamental issues here.

-- Sent from my BlackBerry. Please excuse errors and brevity. *From: *Will Ferrer *Sent: *Thursday, February 19, 2015 7:00 PM *To: *Kamailio (SER) - Users Mailing List *Reply To: *Kamailio (SER) - Users Mailing List *Subject: *Re: [SR-Users] Re-invites from carrier breaks the call

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@switchsoft.com wrote:

...

Hi Alex

Thanks so much.

I will try it right now.

All the best.

Will

On Thu, Feb 19, 2015 at 3:27 PM, Alex Balashov <abalashov@evaristesys.com

...

wrote:

...

On 02/19/2015 06:26 PM, Alex Balashov wrote:

 onreply_route[MAIN_REPLY] {

...

   if(t_check_status("200")) {
      if_is_present_hf("Supported"))

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/

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@ng-voice.com wrote:

Hi Will,

please be aware, that in-call Re-INIVTEs may always happen, even with Session-Timers disabled on both sides (e.g. Codec/Media Change, Networkchanges and many more).

If an in-call Re-INVITE breaks your phone, it would be better to fix that phone than to fix your network.

Kind regards, Carsten

2015-02-20 1:18 GMT+01:00 Will Ferrer will.ferrer@switchsoft.com:

...

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@evaristesys.com

...

wrote:

...

You can try it, but if they shove SST reinvites down your throat despite no indicated support for them from the client, or the client sends SST headers despite no indicated support from the carrier, there are deeper-seated fundamental issues here.

-- Sent from my BlackBerry. Please excuse errors and brevity. *From: *Will Ferrer *Sent: *Thursday, February 19, 2015 7:00 PM *To: *Kamailio (SER) - Users Mailing List *Reply To: *Kamailio (SER) - Users Mailing List *Subject: *Re: [SR-Users] Re-invites from carrier breaks the call

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@switchsoft.com

...

wrote:

...

Hi Alex

Thanks so much.

I will try it right now.

All the best.

Will

On Thu, Feb 19, 2015 at 3:27 PM, Alex Balashov < abalashov@evaristesys.com> wrote:

...

On 02/19/2015 06:26 PM, Alex Balashov wrote:

 onreply_route[MAIN_REPLY] {

...

   if(t_check_status("200")) {
      if_is_present_hf("Supported"))

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/

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Carsten Bock CEO (Geschäftsführer)

ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany

http://www.ng-voice.com mailto:carsten@ng-voice.com

Office +49 40 5247593-0 Fax +49 40 5247593-99

Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284

Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Alex

Please see my responses below.

On Fri, Feb 20, 2015 at 4:28 PM, Alex Balashov abalashov@evaristesys.com wrote:

Hi Will,

On 02/20/2015 07:24 PM, Will Ferrer wrote:

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.

Indeed not, and that's what I was trying to say in my response yesterday.

Oh yes, I noted it there as well and then saw it also in the document I referenced. Thank you for the information.

First, don't confuse the OpenSIPS and Kamailio SST modules, even though they do appear to be identical. Still, two different projects.

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

Second, if you read this documentation, you'll find that nowhere in there exists the capability for Kamailio to initiate SST reinvites itself. All this module provides is policing for the SE value and the ability to peg dialog state to it by making Kamailio SST-aware--that is, aware of SST-motivated reinvites that still very much have to be initiated by the endpoints themselves.

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.

In short, there's nothing you can do here except fix the endpoints.

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

-- 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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 abalashov@evaristesys.com 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:

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.

"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

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.

2. A request URI equal to the Contact URI of the counterparty, as declared

in the initial INVITE and the final 2xx reply respectively. These are known as "remote targets" of the dialog, and can only be updated (although usually aren't) in reinvites.

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.

They must also be sent to P on the network and transport level, regardless of the RURI.

So, I assume that in your initial complaint,

"When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone."

... you are lumping together the discussion of the _sequential_ reinvite with the 200 OK for the _initial_ INVITE. Thus, it is not correct to say that "When a reinvite occurs... the 200 OK does not have the softphone's IP in the Record-Route". It sounds like the answerer of the call isn't copying the Record-Route set into the final 2xx reply for the _initial_ INVITE transaction, leading the UAC to be unaware of it. The 200 OK for the _reinvite_ shouldn't have a Record-Route header. There should not be any Record-Route headers outside of the initial INVITE transaction flow (Record-Route != Route).

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.

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

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 abalashov@evaristesys.com 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

2. A request URI equal to the Contact URI of the counterparty, as declared

in the initial INVITE and the final 2xx reply respectively. These are known as "remote targets" of the dialog, and can only be updated (although usually aren't) in reinvites.

They must also be sent to P on the network and transport level, regardless of the RURI.

So, I assume that in your initial complaint,

"When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone."

... you are lumping together the discussion of the _sequential_ reinvite with the 200 OK for the _initial_ INVITE. Thus, it is not correct to say that "When a reinvite occurs... the 200 OK does not have the softphone's IP in the Record-Route". It sounds like the answerer of the call isn't copying the Record-Route set into the final 2xx reply for the _initial_ INVITE transaction, leading the UAC to be unaware of it. The 200 OK for the _reinvite_ shouldn't have a Record-Route header. There should not be any Record-Route headers outside of the initial INVITE transaction flow (Record-Route != Route).

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users