*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
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
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.
1) If you can't beat em join em -- It
, 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
Will,
You can strip and remove headers with append_hf() and remove_hf() at
will, and add headers to replies with append_to_reply().
However, as a methodological matter, I have to concur with the position
taken by Carsten. Ultimately, the problem is improper handling of
reinvites by one
Hi Alex
Please see my responses below.
On Fri, Feb 20, 2015 at 4:28 PM, Alex Balashov abalas...@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
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
. 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
Sure, but Will's question was about whether the problem can be fixed via Kamailio per se.
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.tr...@pocos.nl wrote:
On Thursday 19 February 2015 03:44:25 Will Ferrer wrote:
Hopefully there is something clever we could
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
...@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
-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
-users-boun...@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
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
: *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
: *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
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
=
.
--
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
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:
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
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
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
--
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
Since timer is Supported: but not Required:, you're almost certainly
safe to simply remove it in Kamailio, even though, of course, strictly
speaking, that is not RFC 3261-compliant proxy behaviour.
As a simple test, try:
request_route {
...
# Handle initial INVITE.
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 abalas...@evaristesys.com
wrote:
On 02/19/2015 06:26 PM, Alex Balashov wrote:
onreply_route[MAIN_REPLY] {
if(t_check_status(200)) {
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
) - 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
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
29 matches
Mail list logo
