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

Daniel-Constantin Mierla miconda at gmail.com
Thu Mar 28 14:51:51 CET 2019


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

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




More information about the sr-users mailing list