Hello, On 02.04.19 20:08, Henning Westerholt wrote: > 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.
good to know it was sorted out this way. Cheers, Daniel > > 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 > > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
