I added the record route for SUBSCRIBE, UPDATE, INFO, PUBLISH, NOTIFY
when there were some issues with FreeSWITCH trying to bypass Kamailio...
That being said, when this was discussed on the FreeSWITCH channel, the
FreeSWITCH users flipped out over record-route. I removed it, had the
same results,
Yes, record route is being generated for all SUBSCRIBE, NOTIFY, and just
in case REFER, INFO, PUBLISH.
--fred
On 03/27/2015 06:38 AM, Daniel-Constantin Mierla wrote:
> 202 is ok, so freeswitch has created the subscription dialog and should
> send notify requests with event dialog.
>
> As I can s
I suppose this speaks to it:
https://tools.ietf.org/html/rfc6665#appendix-B.19
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/,
On 03/27/2015 06:45 AM, Daniel-Constantin Mierla wrote:
I haven't really read the specs, but IETF overturned the old rules in
RFC 6665, so now NOTIFY must be record-routed all the time. IIRC, it was
signaled to us by Inaki few years ago when it was added to default
kamailio.cfg (perhaps can be e
On 27/03/15 11:41, Alex Balashov wrote:
> Daniel,
>
> On 03/27/2015 06:38 AM, Daniel-Constantin Mierla wrote:
>
>> Are you doing record_route() for all SUBSCRIBE and NOTIFY requests?
>
> My understanding was that SUBSCRIBE is a dialog-forming request and
> NOTIFYs are sequential requests. If so,
Daniel,
On 03/27/2015 06:38 AM, Daniel-Constantin Mierla wrote:
Are you doing record_route() for all SUBSCRIBE and NOTIFY requests?
My understanding was that SUBSCRIBE is a dialog-forming request and
NOTIFYs are sequential requests. If so, why would one insert
record_route() in the course o
On 27/03/15 08:07, Olle E. Johansson wrote:
> On 26 Mar 2015, at 23:33, Fred Posner wrote:
>
>> Subscription-State: terminated;reason=noresource.
> THis header in the TCP example should tell you something. FreeSwitch is
> telling you that something has gone wrong with your subscription request.
202 is ok, so freeswitch has created the subscription dialog and should
send notify requests with event dialog.
As I can see in the traces, traffic is TCP to Kamailio and UDP in
between Kamailio and FreeSwitch. Are you doing record_route() for all
SUBSCRIBE and NOTIFY requests?
Cheers,
Daniel
On
On 26 Mar 2015, at 23:33, Fred Posner wrote:
> Subscription-State: terminated;reason=noresource.
THis header in the TCP example should tell you something. FreeSwitch is telling
you that something has gone wrong with your subscription request.
/O
___
For both UDP and TCP I receive a 202.
--fred
On 03/26/2015 06:45 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> actually there is nothing wrong with the NOTIFY via TCP. But it is not
> for Event: dialog (which is for BLF), it is for Event: refer (which is
> for other purposes, having Content-T
Hello,
actually there is nothing wrong with the NOTIFY via TCP. But it is not
for Event: dialog (which is for BLF), it is for Event: refer (which is
for other purposes, having Content-Type: message/sipfrag -- see
https://www.ietf.org/rfc/rfc3420.txt).
You have to see why freeswitch is not sending
Greetings all:
Having a weird issue with BLF relay from Kamailio <-> FreeSWITCH on the
EC2 network.
Set-up:
Natted Client <-> Natted Kamailio <-> Natted FreeSWITCH
Kamailio has a public advertised IP (Amazon Cloud) and sends to
FreeSWITCH's public IP (Amazon Cloud). Clients register to Kamailio
12 matches
Mail list logo
