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


-- 
Technical Support
http://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




--
VoIP Embedded, Inc.
http://www.voipembedded.com