Am Donnerstag, 28. März 2019, 22:04:55 CEST schrieb Daniel-Constantin Mierla:
trying to think a bit more about it, I guess that what happens there is the following:
- re-invite comes it
- loose_route() is executed and by that uac module has the callback
for updating To/From executed
- you update the sdp and then call apply changes, which updates also
the headers
- transaction is created with the new values for From/To headers
If my assumption is right, then the solution would be to do the updates and apply changes before calling loose_route().
Hi Daniel,
to conclude this thread - your guess was right and your suggestion fixed the problem. I will add a comment to the docs to explain this corner case.
Best regards,
Henning
On 28.03.19 19:39, Henning Westerholt wrote:
Hi Daniel,
Thank you. That was a really good Idea, this workaround seems to work just fine.
Best regards,
Henning
Am 28. März 2019 14:51:51 MEZ schrieb Daniel-Constantin Mierla
Hello,
didn't get the chance to look at it yet, being out of the office and the little spare time I got these days I tried to look into libssl/libcrypto 1.1 for the blocking issue reported recently.
I haven't run uac replace with dialog, but as you said, it should not be an impact of that.
When you run with debug=3, couldn't you spot any hint about what can go wrong there?
As for a workaround until it gets fixed, try sending 100 trying with sl module and set the flag for no automatic 100 from tm.
Cheers, Daniel
On 28.03.19 07:19, Henning Westerholt wrote:
Hello,
did you had a chance to have a quick look? Any sugestions are
welcome.
Best regards,
Henning
Am 26. März 2019 08:13:20 MEZ schrieb Henning Westerholt
Am Dienstag, 26. März 2019, 02:27:17 CET schrieb Daniel-Constantin
Mierla:
> I am currently debugging a strange issue related to the usage of > uac_replace_from/to() after msg_apply_changes(). It works all
fine,
but in
> a Re-INVITE case it inserts the wrong headers for the 100 - Trying
case.
> The calle
did you mean caller or callee? What side is sending the re-INVITE
with
the troubles?
Is uac using the record-route param to store the info about
From/To?
Or
is via dialog variables?
Hi Daniel,
storage is with dialog variables, but in the 100 - Trying case this
is
internally done with the uac TM callbacks (If I understood the code correctly). If I remove the msg_apply_changes() in the Re-INVITE
case,
all works fine.
Call flow (A is a SIP client, B a PSTN destination):
A -> B INVITE, 100, 18x, 200, ACK: all fine A -> B first Re-INVITE, 100: the 100 - Trying is broken A -> B second Re-INVINTE, 100: the 100 - Trying is broken ... more Re-INVINTEs A -> B BYE: all fine
I have attached a trace, see below the 100 - Trying examples:
This is ok: Kamailio-IP.sip > A-SIDE-IP.na-localise: SIP, length: 405
SIP/2.0 100 trying -- your call is important to usVia: SIP/2.0/UDP A-SIDE-IP:5062;rport=5062;branch=z9hG4bKPjh2a4HyDf1ApI7kWK5ShgL7I7w9.LvoeI;received =A->>
SIDE-IP
From:
sip:A-Number@Kamailio-IP;tag=Ho4cXwV4Q-LBW0n4guPOQwvi6GbiylqO
To: sip:B-Number@Kamailio-IP Call-ID: po-DL6LvwksnKK56D3lF8HB4wwo6F.GS CSeq: 6764 INVITE Server: Carrier-Name SIP Voice Gateway Content-Length: 0This is not OK:
12:42:59.336930 IP (tos 0x10, ttl 64, id 61398, offset 0, flags
[none],
proto UDP (17), length 461)
Kamailio-IP.sip > A-SIDE-IP.na-localise: SIP, length: 433
SIP/2.0 100 trying -- your call is important to usVia: SIP/2.0/UDP
A-SIDE-IP:5062;rport=5062;branch=z9hG4bKPj3jfO6Fuk5-
SJQ2EXOIEeYJk1amH.xKvp;received=A-SIDE-IP
From:
sip:+Rewritten-Number@sip.voice.Carrier-Name.net;tag=Ho4cXwV4Q-
LBW0n4guPOQwvi6GbiylqO
To: sip:+B-Number@Carrier-IP:5060;tag=7N2BS4K70tZ9Q Call-ID: po-DL6LvwksnKK56D3lF8HB4wwo6F.GS CSeq: 6765 INVITE Server: Carrier-Name SIP Voice Gateway Content-Length: 0