Daniel,
Becomes clear that the carrier's SIP knowledge is worse than mine... sorry
for wasting your time.
Regards,
Sergiu
On Tue, Apr 9, 2019 at 11:54 AM Daniel-Constantin Mierla
wrote:
> That's really strange, the CANCEL has the same direction as INVITE, not
> the opposite. Can you double
That's really strange, the CANCEL has the same direction as INVITE, not
the opposite. Can you double check if they really asked for such things.
This is very clear in terms of SIP specs and I doubt that someone
understood it wrong.
Cheers,
Daniel
On 09.04.19 14:08, Sergiu Pojoga wrote:
> Yes
Yes Daniel, that is precisely so.
On Tue, Apr 9, 2019, 7:10 AM Daniel-Constantin Mierla,
wrote:
> To be sure I understand properly: do they require to send a CANCEL back to
> them for calls that they initiate with the first INVITE and do not get
> 200ok, but 3xx/4xx/5xx?
>
> Cheers,
> Daniel
>
To be sure I understand properly: do they require to send a CANCEL back
to them for calls that they initiate with the first INVITE and do not
get 200ok, but 3xx/4xx/5xx?
Cheers,
Daniel
On 08.04.19 17:34, Sergiu Pojoga wrote:
> Looks like it's going to be another battle with a Metaswitch-based
>
Looks like it's going to be another battle with a Metaswitch-based
carrier... so far they are telling me 'we can't do anything about it. Send
us a CANCEL to tear down the call`
I know this is a `another story` question, but if I had to overcome this,
would *uac_req_send() *be my only option?
On 07.04.19 15:40, Sergiu Pojoga wrote:
> To simplify, the problem seems to come down to the following: how do
> you cancel/end an early state dialog between the caller and callee
> after `fr_inv_timeout` occurs? Kam self-generates a proper CANCEL
> towards the callee, while the caller gets a
Hi,
To-tags are only significant at the dialog layer. Replies are matched to
a transaction by Via `branch` parameter and CSeq. See RFC 3261 ยง 17.1.3
for details.
Consequently, the 503 response should be matched to the initial INVITE
transaction on that basis alone.
-- Alex
On Sun, Apr 07, 2019
To simplify, the problem seems to come down to the following: how do you
cancel/end an early state dialog between the caller and callee after
`fr_inv_timeout` occurs? Kam self-generates a proper CANCEL towards the
callee, while the caller gets a `408 Request Timeout' with a different
To-tag.
I've
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway. After
`fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call doesn't hang
up. This doesn't happen when the
