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