[OpenSIPS-Users] unicode characters in dlg_list caller_contact field on re-invite
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Feb 26 12:34:33 UTC 2024
Denis,
I do not see any unicode chars to be present in the received contact
URIs. What you see in the dlg_list output looks like garbage to me -
maybe the update was not properly done and the len of the contact is
longer than the actual value, leading to to memory garbage to be printed
(printing out of buffer).
Do you use from script any functions that may change the contact, like
fix_nated_contact() or so ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 24.02.2024 05:35, Denis Lyubimov wrote:
> Hi,
>
> I will put here an example of what I get in caller_contact with re-INVITE.
>
> This is incoming INVITE:
> ------------------------
> INVITE sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>;transport=tcp SIP/2.0
> Via: SIP/2.0/TCP
> 172.17.17.55:49677;rport;branch=z9hG4bKPj0c5e8cf59ad645119867f42d06c77a9f;alias
> Max-Forwards: 70
> From: <sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>>;tag=b8b13e3376954c7dbaff8da68ee1d44a
> To: <sip:7654321 at 192.168.224.50 <mailto:sip%3A7654321 at 192.168.224.50>>
> Contact: <sip:1002 at 172.17.17.55:49677;transport=TCP;ob>
> Call-ID: 5e97161dba344eeeab00d40bc883e4e3
> CSeq: 17799 INVITE
> Route: <sip:4.4.4.2;transport=tcp;lr>
> ....
> ------------------------
> This is forwarded INVITE:
> ------------------------
> INVITE sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>;transport=tcp SIP/2.0
> Record-Route:
> <sip:192.168.224.91:5090;transport=tcp;r2=on;lr;ftag=b8b13e3376954c7dbaff8da
> 68ee1d44a;nat=yes;did=61f.b845fdd7>
> Record-Route:
> <sip:4.4.4.2:5060;transport=tcp;r2=on;lr;ftag=b8b13e3376954c7dbaff8da68ee1d4
> 4a;nat=yes;did=61f.b845fdd7>
> Via: SIP/2.0/TCP
> 192.168.224.91:5090;branch=z9hG4bK86c6.385ee382.0;i=a51f1803
> Via: SIP/2.0/TCP
> 172.17.17.55:49677;received=4.4.4.1;rport=49677;branch=z9hG4bKPj0c5e8cf59
> ad645119867f42d06c77a9f;alias
> Max-Forwards: 69
> From: <sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>>;tag=b8b13e3376954c7dbaff8da68ee1d44a
> To: <sip:7654321 at 192.168.224.50 <mailto:sip%3A7654321 at 192.168.224.50>>
> Contact: <sip:1002 at 4.4.4.1:49677;transport=TCP;ob>
> Call-ID: 5e97161dba344eeeab00d40bc883e4e3
> CSeq: 17799 INVITE
> ...
> ------------------------
> dlg_list:
> ------------------------
> {
> "Dialogs": [
> {
> "ID": "61f.b845fdd7",
> "db_id": "16589275485323",
> "state": 4,
> "user_flags": "DISPATCHED_FLG",
> "timestart": 1708744350,
> "datestart": "2024-02-24 06:12:30",
> "timeout": 1708787549,
> "dateout": "2024-02-24 18:12:29",
> "callid": "5e97161dba344eeeab00d40bc883e4e3",
> "from_uri": "sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>",
> "to_uri": "sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>",
> "caller_tag": "b8b13e3376954c7dbaff8da68ee1d44a",
> "caller_contact": "sip:1002 at 4.4.4.1:49677;transport=TCP;ob",
> "callee_cseq": "0",
> ...
> ------------------------
> For now caller_contact has the value
> "sip:1002 at 4.4.4.1:49677;transport=TCP;ob".
>
>
> Then i do re-INVITE from caller:
> ------------------------
> INVITE sip:192.168.224.50:5060;transport=tcp SIP/2.0
> Via: SIP/2.0/TCP
> 172.17.17.55:49677;rport;branch=z9hG4bKPjdfcc1bcad866428c8d43d1fbcfeaba54;alias
> Max-Forwards: 70
> From: <sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>>;tag=b8b13e3376954c7dbaff8da68ee1d44a
> To: <sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>>;tag=008162B2-5CFB-15D9-810C-32E0A8C0AA77-3
> Contact: <sip:1002 at 172.17.17.55:49677;transport=TCP;ob>
> Call-ID: 5e97161dba344eeeab00d40bc883e4e3
> CSeq: 17800 INVITE
> ...
> ------------------------
> forwarded re-INVITE:
> ------------------------
> INVITE sip:192.168.224.50:5060;transport=tcp SIP/2.0
> Via: SIP/2.0/TCP
> 192.168.224.91:5090;branch=z9hG4bKbb97.f5810342.0;i=a51f1803
> Via: SIP/2.0/TCP
> 172.17.17.55:49677;received=4.4.4.1;rport=49677;branch=z9hG4bKPjdfcc1bcad
> 866428c8d43d1fbcfeaba54;alias
> Max-Forwards: 69
> From: <sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>>;tag=b8b13e3376954c7dbaff8da68ee1d44a
> To: <sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>>;tag=008162B2-5CFB-15D9-810C-32E0A8C0AA77-3
> Contact: <sip:1002 at 4.4.4.1:49677;transport=TCP;ob>
> Call-ID: 5e97161dba344eeeab00d40bc883e4e3
> CSeq: 17800 INVITE
> ...
> ------------------------
> dlg_list:
> ------------------------
> {
> "Dialogs": [
> {
> "ID": "61f.b845fdd7",
> "db_id": "16589275485323",
> "state": 4,
> "user_flags": "DISPATCHED_FLG",
> "timestart": 1708744350,
> "datestart": "2024-02-24 06:12:30",
> "timeout": 1708787549,
> "dateout": "2024-02-24 18:12:29",
> "callid": "5e97161dba344eeeab00d40bc883e4e3",
> "from_uri": "sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>",
> "to_uri": "sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>",
> "caller_tag": "b8b13e3376954c7dbaff8da68ee1d44a",
> "caller_contact": "sip:1002 at 4.4.4.1
> <mailto:sip%3A1002 at 4.4.4.1>\ufffd",
> "callee_cseq": "0",
> ...
> }
> ------------------------
> Now caller_contact has the value "sip:1002 at 4.4.4.1
> <mailto:sip%3A1002 at 4.4.4.1>\ufffd".
>
> If i do re-INVITE from callee side:
> ------------------------
> INVITE sip:1002 at 4.4.4.1:49677;transport=TCP;ob SIP/2.0
> From: <sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>>;tag=008162B2-5CFB-15D9-810C-32E0A8C0AA77-3
> To: <sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>>;tag=b8b13e3376954c7dbaff8da68ee1d44a
> Call-ID: 5e97161dba344eeeab00d40bc883e4e3
> CSeq: 1 INVITE
> Content-Length: 310
> Content-Type: application/sdp
> Via: SIP/2.0/TCP
> 192.168.224.50:5060;branch=z9hG4bK008162BC-5CFB-15D9-810C-32E0A8C0AA77-7
> Contact: <sip:192.168.224.50:5060;transport=tcp>
> ------------------------
> forwarded re-INVITE:
> ------------------------
> INVITE sip:1002 at 4.4.4.1:49677;transport=TCP;ob SIP/2.0
> From: <sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>>;tag=008162B2-5CFB-15D9-810C-32E0A8C0AA77-3
> To: <sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>>;tag=b8b13e3376954c7dbaff8da68ee1d44a
> Call-ID: 5e97161dba344eeeab00d40bc883e4e3
> CSeq: 1 INVITE
> Content-Length: 302
> Content-Type: application/sdp
> Via: SIP/2.0/TCP 4.4.4.2:5060;branch=z9hG4bKd4ff.c838c3a3.0;i=881f1803
> Via: SIP/2.0/TCP
> 192.168.224.50:5060;rport=36702;received=192.168.224.50;branch=z9hG4bK008162BC-5CFB-15D9-810C-32E0A8C0AA77-7
> Contact: <sip:192.168.224.50:5060;transport=tcp>
> ------------------------
> dlg_list
> ------------------------
> {
> "Dialogs": [
> {
> "ID": "61f.b845fdd7",
> "db_id": "16589275485323",
> "state": 4,
> "user_flags": "DISPATCHED_FLG",
> "timestart": 1708744350,
> "datestart": "2024-02-24 06:12:30",
> "timeout": 1708787549,
> "dateout": "2024-02-24 18:12:29",
> "callid": "5e97161dba344eeeab00d40bc883e4e3",
> "from_uri": "sip:1002 at 192.168.224.50
> <mailto:sip%3A1002 at 192.168.224.50>",
> "to_uri": "sip:7654321 at 192.168.224.50
> <mailto:sip%3A7654321 at 192.168.224.50>",
> "caller_tag": "b8b13e3376954c7dbaff8da68ee1d44a",
> "caller_contact": "sip:1002 at 4.4.4.1:49677;transport=TCP;ob",
> "callee_cseq": "2",
> ...
> ------------------------
> caller_contact value in dlg_list starts to look like it should be:
> "sip:1002 at 4.4.4.1:49677;transport=TCP;ob" .
>
> пт, 23 февр. 2024 г. в 14:59, Bogdan-Andrei Iancu <bogdan at opensips.org>:
>
> Hi Denis,
>
> Could post the actual Contact hdr as received (network level like
> pcap or trace) by OpenSIPS from both caller and callee parties ?
>
> Regards
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
> https://www.opensips-solutions.com
> https://www.siphub.com
>
> On 22.02.2024 07:34, Denis Lyubimov wrote:
>> Hi all,
>>
>> My network scheme is
>> softphone <-nat-external network-nat-> opensips <-local network->
>> sip servers <-local network-> softphone
>> No b2b or topology_hiding modules are used.
>> Opensips versions I tried: 3.4.4-1 and 3.4.3-1.
>>
>> I make a call from a phone behind nat to sip server via opensips,
>> so I use the fix_contact function from
>> nat_traversal/fix_nated_contact from nathelper for each request.
>> On the first invite I get "caller_contact":
>> "sip:1002 at 3.3.3.1:49682;transport=TCP;ob" in "opensips-cli -x mi
>> dlg_list".
>> If caller side makes re-invite, then i see this "caller_contact":
>> "\u0001" for nat_traversal,
>> and this "caller_contact": "sip:1002 at 3.3.3.1
>> <mailto:sip%3A1002 at 3.3.3.1>\ufffd" with nathelper in dlg_list.
>> In that case dlg_send_sequential mi dialog function cannot be
>> used cause caller contact cannot be read.
>>
>> Also if i make a re-invite from the caller side then the
>> caller_contact field in dlg_list starts looking normal.
>>
>> Am I doing something wrong with fixing the nated contact field?
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240226/36af73e8/attachment.html>
More information about the Users
mailing list