On Wednesday 28 January 2015 13:52:26 Daniel-Constantin Mierla wrote:
> One solution I thought of is to propagate the direction via topoh
> 'cookie' header, as it is done by the dialog module for the local
> generated BYE. Tm code needs to be changed, but I haven't found the time
> for it yet.
>
>
On 27/01/15 17:40, Daniel Tryba wrote:
> On Tuesday 27 January 2015 11:24:59 Daniel Tryba wrote:
>> Works for my 488, will test some more to see if nothing else is broken.
> I was a bit optimistic, patch breaks if the called endpoint responds with a
> 4xx :(
>
One solution I thought of is to prop
On Tuesday 27 January 2015 11:24:59 Daniel Tryba wrote:
> Works for my 488, will test some more to see if nothing else is broken.
I was a bit optimistic, patch breaks if the called endpoint responds with a
4xx :(
--
Telefoon: 088 0100 700
Sales: sa...@pocos.nl | Service: serviced...@pocos.nl
h
> Am I to naive to think that these ACKs to negatives always (callid masking
> and whether topoh is active or not) need to use the Call-ID from the
> negative (in this case 488) response? Call-ID has only to be rewritten in
> forwarding the negative response towards the endpoint that triggered it
>
On Wednesday 21 January 2015 23:52:46 Daniel-Constantin Mierla wrote:
> It is an ACK for a negative response, therefore it is hop-by-hop
> (received and discared by kamailio, then a new one is generated to the
> next hop). The information of direction which was detected with Route
> header ftag can
It is an ACK for a negative response, therefore it is hop-by-hop
(received and discared by kamailio, then a new one is generated to the
next hop). The information of direction which was detected with Route
header ftag cannot be done in this case. I will try to figure out how
can be solved...
Cheer
On Wednesday 21 January 2015 08:45:59 Daniel-Constantin Mierla wrote:
> To understand properly, this is after the re-INVITE from B to A? I will
> look in the code as I get a chance, being out of the office for few days...
Yes. Full trace below. Only the ACK to SIP_A for the 488 has the wrong Call-
To understand properly, this is after the re-INVITE from B to A? I will
look in the code as I get a chance, being out of the office for few days...
Cheers,
Daniel
On 20/01/15 13:13, Daniel Tryba wrote:
> Trying to call a T.38 enabled endpoint B from an endpoint A that doesn't.
> This
> results
Trying to call a T.38 enabled endpoint B from an endpoint A that doesn't. This
results in a "488 Not Acceptable" from A.
The kamailio (4.0.3) in between with topoh enabled (with mask_callid set to 1.
Kamailio ACKs the 488 to A, but the ACK has the wrong (masked) Call-ID,
resulting in the ACK to
