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 <[email protected]>: >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 ><[email protected]>: >>> 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:[email protected];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 -- Henning Westerholt https://skalatan.de/blog/ _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
