[SR-Users] uac_replace_from/to, msg_apply_changes and Re-INVITE

[Henning Westerholt]

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 
<miconda at gmail.com>:
> >> 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 at kamailio.org>:
> >>>> 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 at Kamailio-IP;tag=Ho4cXwV4Q-LBW0n4guPOQwvi6GbiylqO
> >> 
> >>>>        To: sip:B-Number at 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 at sip.voice.Carrier-Name.net;tag=Ho4cXwV4Q-
> >> 
> >>>> LBW0n4guPOQwvi6GbiylqO
> >>>> 
> >>>>        To: sip:+B-Number at 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