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
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 t
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 Alex
Please see my responses below.
On Fri, Feb 20, 2015 at 4:28 PM, Alex Balashov
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.
>>
>
> In
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
rt 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
>>&g
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 endpo
>> *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
>>
> --
> 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 br
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 deep
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
-- perha
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 3
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
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"))
>>
>
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.
t_on_
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,
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.
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
= refus
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.
xing 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
>&g
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, ou
sers [mailto:sr-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
From: sr-users [mailto:sr-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 as
s.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 | r
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 wrote:
>
>> On Thursday 19 February 2015 03:44:25 Will Ferrer wrote:
>> Hopefully there is something clever we could do to corr
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 r
Sure, but Will's question was about whether the problem can be fixed via Kamailio per se.
d. 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 fr
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 continui
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 c
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 th
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 n
30 matches
Mail list logo
