Am Dienstag, 26. März 2019, 02:27:17 CET schrieb Daniel-Constantin Mierla: but in case. with Or 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 us Via: 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: 0 This 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 us Via: 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 Cheers, Henning

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: welcome. <hw(a)kamailio.org>rg>: fine, From/To? is case, 5062;rport=5062;branch=z9hG4bKPjh2a4HyDf1ApI7kWK5ShgL7I7w9.LvoeI;received=A- sip:A-Number@Kamailio-IP;tag=Ho4cXwV4Q-LBW0n4guPOQwvi6GbiylqO [none], A-SIDE-IP:5062;rport=5062;branch=z9hG4bKPj3jfO6Fuk5- 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 >> >> Cheers, >> >> Henning

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().

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 >> >> <hw(a)kamailio.org>rg>: >>>> 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 us >> >>>> Via: 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: 0 >>>> >>>> This 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 us >>>> >>>> Via: 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