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

[Daniel-Constantin Mierla]

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 
> <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
>
>
-- 
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