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

[Henning Westerholt]

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
>>>
>>> Cheers,
>>>
>>> Henning

-- 
Henning Westerholt
https://skalatan.de/blog/