sr-users December 2019

sr-users@lists.kamailio.org

63 participants
81 discussions

ul.dump empty
by Liu, Charles 07 Dec '19

07 Dec '19

Hi All, I am running Kamailio v5.2.4 with P/S/I-cscf instances on 3 different machines with default IMS example configurations. Kamcmd ul.dump show empty, but I can make calls... any idea what is the problem? root@pcscf:/# kamcmd ulpcscf.status { Domain: location Size: 512 AoRs: { Stats: { Records: 7 Max-Slots: 6 } } } root@pcscf:/# kamcmd ul.dump { Domains: { } } CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.

1 1

Pike module never release IP
by Andrew Chen 06 Dec '19

06 Dec '19

Hi all, Have anyone ever experienced pike module not releasing the IP after "remove_latency" period? We ran a load test and this is what happened to one of the two paired nodes and I had to restart kamailio process to release it. I'm running Kam 5.2.5 Thanks. -- Andy Chen Sr. Telephony Lead Engineer achen@ <achen(a)thinkingphones.com>fuze.com -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

2 6

How can I make calls between the two domains?
by Yanko 06 Dec '19

06 Dec '19

Hello: I have two virtual machines with two kamailo domains VM1: Domain: 172.16.16.1 Users:2000, 2001, 2002... VM2: Domain: 172.16.16.2 Users:3000, 3001, 3002... In each domain I can make calls. For example, user 2000 can call 2001. User 3000 can call 3001. How can I make calls between the two domains? What modules do I need to load? How to configure the kamailio.cfg file? Thanks, YANKO.

2 1

Scripts still valid?
by David Villasmil 05 Dec '19

05 Dec '19

Hello guys, Is this still valid? https://github.com/kamailio/kamailio/blob/master/misc/examples/scripts/ctd.… Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

3 4

call disconnected between 15 to 45 minutes
by Liu, Charles 05 Dec '19

05 Dec '19

Hi all, I am still looking for some help to debug why S-CSCF send BYE to caller and callee after a call was connected. from wireshark, I just saw S-CSCF send BYE to both caller and callee. That matched the S-CSCF debug output. But the question is why S-CSCF delete contact and send BYE to a active call? There was no timer expire or something like that in the log... Anyone can help? Thanks, --Charles 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb09413e6d0 alloc'ed from cdp: diameter_msg.c: AAATranslateMessage(484) 19(24) DEBUG: tm [t_lookup.c:1618]: t_lookup_ident(): transaction found 19(24) DEBUG: <core> [core/mem/q_malloc.c:367]: qm_malloc(): qm_malloc(0x7fb093db6000, 6872) called from core: core/sip_msg_clone.c: sip_msg_shm_clone(496) 19(24) DEBUG: <core> [core/mem/q_malloc.c:412]: qm_malloc(): qm_malloc(0x7fb093db6000, 6872) returns address 0x7fb09414d450 frag. 0x7fb09414d418 (size=6872) on 1 -th hit 19(24) ERROR: *** cfgtrace:failure_route=[REG_SAR_REPLY] c=[/etc/kamailio/kamailio.cfg] l=767 a=26 n=xlog 19(24) DEBUG: <script>: saa_return code is 1 19(24) ERROR: *** cfgtrace:failure_route=[REG_SAR_REPLY] c=[/etc/kamailio/kamailio.cfg] l=769 a=26 n=xlog 19(24) DEBUG: <script>: saa_return code (for scscf_save on register) is 1 19(24) ERROR: *** cfgtrace:failure_route=[REG_SAR_REPLY] c=[/etc/kamailio/kamailio.cfg] l=783 a=21 n=switch 19(24) ERROR: *** cfgtrace:failure_route=[REG_SAR_REPLY] c=[/etc/kamailio/kamailio.cfg] l=772 a=26 n=xlog 19(24) DEBUG: <script>: SAR success - 200 response sent from module 19(24) ERROR: *** cfgtrace:failure_route=[REG_SAR_REPLY] c=[/etc/kamailio/kamailio.cfg] l=773 a=2 n=exit 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb09414d450), called from tm: t_reply.c: free_faked_req(948) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb09414d418 alloc'ed from core: core/sip_msg_clone.c: sip_msg_shm_clone(496) 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb09413e978), called from ims_registrar_scscf: cxdx_sar.c: free_saved_transaction_data(94) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb09413e940 alloc'ed from ims_registrar_scscf: save.c: save(1414) 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb09413e0b0), called from ims_registrar_scscf: reply.c: free_contact_buf(830) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb09413e078 alloc'ed from ims_registrar_scscf: reply.c: build_contact(443) 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb094145218), called from ims_registrar_scscf: reply.c: free_contact_buf(835) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb0941451e0 alloc'ed from ims_registrar_scscf: reply.c: build_contact(435) 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb094147dc0), called from ims_registrar_scscf: cxdx_sar.c: free_saved_transaction_data(98) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb094147d88 alloc'ed from ims_registrar_scscf: save.c: save(1396) 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb09415b4c8), called from cdp: transaction.c: cdp_free_trans(182) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb09415b490 alloc'ed from cdp: transaction.c: cdp_add_trans(110) 19(24) DEBUG: <core> [core/mem/q_malloc.c:475]: qm_free(): qm_free(0x7fb093db6000, 0x7fb0941442a0), called from cdp: transaction.c: cdp_free_trans(183) 19(24) DEBUG: <core> [core/mem/q_malloc.c:519]: qm_free(): freeing frag. 0x7fb094144268 alloc'ed from cdp: transaction.c: cdp_add_trans(105) 13(18) DEBUG: ims_usrloc_scscf [ims_usrloc_scscf_mod.c:481]: timer(): Syncing cache 13(18) DEBUG: ims_usrloc_scscf [udomain.c:291]: mem_timer_udomain(): *** mem_timer_udomain - checking contacts - START *** 13(18) DEBUG: ims_usrloc_scscf [udomain.c:301]: mem_timer_udomain(): We have a [3gpp=0] contact in the new contact list in slot 95 = [sip:bob@ims.mnc001.mnc001.3gppnetwork.org] (sip:bob@192.168.164.248:50448;rinstance=989f943bd5098a11;transport=UDP) which expires in -60.000000 seconds and has a ref count of 0 (state: Contact with delayed delete) 13(18) DEBUG: ims_usrloc_scscf [udomain.c:309]: mem_timer_udomain(): contact in state CONTACT_DELATED_DELETE is about to be deleted13(18) DEBUG: ims_usrloc_scscf [udomain.c:301]: mem_timer_udomain(): We have a [3gpp=0] contact in the new contact list in slot 464 = [sip:alice@ims.mnc001.mnc001.3gppnetwork.org] (sip:alice@192.168.164.203:44640;rinstance=e35e9704884c3208;transport=UDP) which expires in 50.000000 seconds and has a ref count of 1 (state: Contact valid) 13(18) DEBUG: ims_usrloc_scscf [udomain.c:301]: mem_timer_udomain(): We have a [3gpp=0] contact in the new contact list in slot 478 = [sip:bob@ims.mnc001.mnc001.3gppnetwork.org] (sip:bob@192.168.164.248:50448;rinstance=9e742618a5f6bcae;transport=UDP) which expires in 56.000000 seconds and has a ref count of 1 (state: Contact valid) 13(18) DEBUG: ims_usrloc_scscf [udomain.c:353]: mem_timer_udomain(): *** mem_timer_udomain - checking contacts - FINISHED *** 13(18) DEBUG: ims_usrloc_scscf [udomain.c:359]: mem_timer_udomain(): *** mem_timer_udomain - checking IMPUs - START *** 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:372]: process_impurecord(): Checking validity of IMPU: <sip:alice@ims.mnc001.mnc001.3gppnetwork.org> registration subscriptions 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:404]: process_impurecord(): Public Identity sip:alice@ims.mnc001.mnc001.3gppnetwork.org, Barred: [0], State: [registered], contacts [1], 3gppcontacts [0] 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:441]: process_impurecord(): Contact #0 - sip:alice@192.168.164.203:44640;rinstance=e35e9704884c3208;transport=UDP, Ref [1] (expires in 50 seconds) (State: 0) 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:372]: process_impurecord(): Checking validity of IMPU: <sip:bob@ims.mnc001.mnc001.3gppnetwork.org> registration subscriptions 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:404]: process_impurecord(): Public Identity sip:bob@ims.mnc001.mnc001.3gppnetwork.org, Barred: [0], State: [registered], contacts [1], 3gppcontacts [0] 3(18) DEBUG: ims_usrloc_scscf [impurecord.c:441]: process_impurecord(): Contact #0 - sip:bob@192.168.164.248:50448;rinstance=9e742618a5f6bcae;transport=UDP, Ref [1] (expires in 56 seconds) (State: 0) 3(18) DEBUG: ims_usrloc_scscf [udomain.c:384]: mem_timer_udomain(): *** mem_timer_udomain - checking IMPUs - FINISHED *** 3(18) DEBUG: ims_usrloc_scscf [udomain.c:406]: mem_timer_udomain(): deleting contact [sip:bob@ims.mnc001.mnc001.3gppnetwork.org] 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:598]: delete_scontact(): Deleting contact: [sip:bob@192.168.164.248:50448;rinstance=989f943bd5098a11;transport=UDP] 13(18) DEBUG: ims_usrloc_scscf [usrloc_db.c:370]: db_delete_ucontact(): Deleting ucontact [sip:bob@192.168.164.248:50448;rinstance=989f943bd5098a11;transport=UDP] 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:310]: mem_delete_ucontact(): Checking if dialog_data is there and needs to be torn down 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:314]: mem_delete_ucontact(): first dialog is not 0 13(18) DEBUG: ims_usrloc_scscf [impurecord.c:317]: mem_delete_ucontact(): Going to tear down dialog with info h_entry [1694] h_id [3889] 13(18) DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fb09414ce40 with 1 -> 3 13(18) DEBUG: ims_dialog [dlg_hash.c:889]: lookup_dlg(): dialog id=3889 found on entry 1694 13(18) DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fb09414ce40 with 1 -> 2 13(18) DEBUG: ims_dialog [dlg_req_within.c:379]: dlg_terminate(): terminating confirmed dialog 13(18) DEBUG: <core> [core/mem/q_malloc.c:367]: qm_malloc(): qm_malloc(0x7fb09b5ae010, 18) called from ims_dialog: dlg_req_within.c: build_extra_hdr(229) 13(18) DEBUG: <core> [core/mem/q_malloc.c:412]: qm_malloc(): qm_malloc(0x7fb09b5ae010, 24) returns address 0x7fb09b640c30 frag. 0x7fb09b640bf8 (size=64) on 1 -th hit 13(18) DEBUG: <core> [core/mem/q_malloc.c:367]: qm_malloc(): qm_malloc(0x7fb09b5ae010, 248) called from ims_dialog: dlg_req_within.c: build_dlg_t(81) 13(18) DEBUG: <core> [core/mem/q_malloc.c:412]: qm_malloc(): qm_malloc(0x7fb09b5ae010, 248) returns address 0x7fb09b74b100 frag. 0x7fb09b74b0c8 (size=248) on 1 -th hit 13(18) DEBUG: <core> [core/mem/q_malloc.c:367]: qm_malloc(): qm_malloc(0x7fb09b5ae010, 72) called from core: core/parser/parse_rr.c: do_parse_rr_body(68) 13(18) DEBUG: <core> [core/mem/q_malloc.c:412]: qm_malloc(): qm_malloc(0x7fb09b5ae010, 72) returns address 0x7fb09b74b048 frag. 0x7fb09b74b010 (size=80) on 1 -th hit 13(18) DEBUG: ims_dialog [dlg_req_within.c:272]: send_bye(): sending BYE to caller 13(18) DEBUG: ims_dialog [dlg_hash.c:1047]: ref_dlg(): ref dlg 0x7fb09414ce40 with 1 -> 3 CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.

2 2

Question regarding priority in dispatcher module
by Floimair Florian 05 Dec '19

05 Dec '19

Dear all! After reading the documentation on dispatcher module I still have a question that isn't really documented. Regarding the priority value of an entry in a dispatcher list: Is a lower numerical priority value regarded as higher priority or is it the other way around? Hopefully someone can help me to clarify this. With best regards FLORIAN FLOIMAIR Software Development Commend International GmbH Saalachstrasse 51 5020 Salzburg, Austria commend.com LG Salzburg / FN 178618z

2 2

Re: [SR-Users] RTPengine with rejected RE-INVITE when port is changing
by Daniel Tryba 05 Dec '19

05 Dec '19

On Thu, Dec 05, 2019 at 09:37:51AM +0000, Laurent Schweizer wrote: > Hello, > > I already see old post about this : > https://opensips.org/pipermail/users/2014-November/030451.html > > but I???m interested to know if now they is a solution ???? > > so the issue is a RE-INVITE rejected (415 Unsupported Media or 488 ) and the RTP port is changing. > Is that case the old RTP relay (I???m using RTPengine) is destroyed after 30sec. > Any way to restore them ? I'm confused: - opensips != kamailio - rtpproxy != rtpengine But RFC 3261 states (page 16): During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14. So if this happens with kamailio/rtpengine that is a bug in (I presume) rtpengine.

3 2

siputils: how does sip_p_charging_vector generate the header
by George Diamantopoulos 05 Dec '19

05 Dec '19

Hello, I've been looking at the sip_p_charging_vector() function of siputils. From the documentation it is not evident how the PCV header is generated. Are the exported $pcv pseudovariables writable, so that the function canl use those when generating the header? Thanks! BR, George

2 3

anycast + dmq_usrloc
by Nuno Miguel Reis 05 Dec '19

05 Dec '19

Hi guys. I'm setting up an anycast scenario with several kamailios sharing an active state and I've noticed that the dmq_usrloc module is not replication the usrloc socket_info attribute when a register comes in through one of the kamailio nodes. Is there a reason behind this? I'm thinking on adding the replication for that attribute in the code. Another way of address this woud be by having a modparam to replicate the socket. What do you think? This is what I'm seeing: *anycast node that actually gets the SIP REGISTER:* $ kamcmd ul.dump { Domains: { Domain: { Domain: location Size: 32768 AoRs: { Info: { AoR: 309(a)nmreis.test HashID: -35263718 Contacts: { Contact: { Address: sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test Expires: 585 Q: -1.000000 Call-ID: 6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0 CSeq: 4 User-Agent: Jitsi2.11.5602Linux Received: sip: 2.2.2.2:31171 Path: [not set] State: CS_SYNC Flags: 1 CFlags: 192 Socket: udp: 1.1.1.1:5060 Methods: -1 Ruid: uloc-5de8056d-22ab-f Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 1 Last-Keepalive: 1575487540 Last-Modified: 1575487540 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } *anycast node that gets the USRLOC update via KDMQ:* $ kamcmd ul.dump { Domains: { Domain: { Domain: location Size: 32768 AoRs: { Info: { AoR: 309(a)nmreis.test HashID: -35263718 Contacts: { Contact: { Address: sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test Expires: 574 Q: -1.000000 Call-ID: 6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0 CSeq: 4 User-Agent: Jitsi2.11.5602Linux Received: sip: 2.2.2.2:31171 Path: [not set] State: CS_SYNC Flags: 1 CFlags: 192 Socket: [not set] Methods: -1 Ruid: uloc-5de7ff7b-4617-3 Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 1 Last-Keepalive: 1575487540 Last-Modified: 1575487540 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } *the actual KDMQ message:* *KDMQ sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060> SIP/2.0 Via: SIP/2.0/UDP 10.100.100.22;branch=z9hG4bK6034.290e4186000000000000000000000000.0 To: <sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060>> From: <sip:usrloc@10.100.100.22:5060 <http://sip:usrloc@10.100.100.22:5060>>;tag=3393f0703fb0ccaca74109ff37de39f5-1e4c092b CSeq: 10 KDMQ Call-ID: 0cfde4d32a31addc-8875(a)127.0.0.1 <0cfde4d32a31addc-8875(a)127.0.0.1> Content-Length: 433 Max-Forwards: 1 Content-Type: application/json {"action":1,"aor":"309(a)nmreis.test","ruid":"uloc-5de8056d-22ab-f","c":"sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test","received":"sip:2.2.2.2:31171 <http://2.2.2.2:31171>","path":"","callid":"6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0","user_agent":"Jitsi2.11.5602Linux","instance":"","expires":1575487600,"cseq":2,"flags":1,"cflags":192,"q":-1,"last_modified":1575487000,"methods":4294967295,"reg_id":0,"server_id":0}* -- Nuno Miguel Reis Departamento de Engenharia Informática Faculdade de Ciências e Tecnologia Universidade de Coimbra mobile: +351 918519145 -- get my PGP key @ http://pgp.dei.uc.pt:11371/pks/lookup?op=get&search=0x750296EECEAD2B6D

2 2

anycast + dmq_usrloc
by Nuno Miguel Reis 04 Dec '19

04 Dec '19

Hi guys. I'm setting up an anycast scenario with several kamailios sharing an active state and I've noticed that the dmq_usrloc module is not replicating the usrloc socket_info attribute when a register comes in through one of the kamailio nodes. Is there a reason behind this? I'm thinking on adding the replication for that attribute in the code. Another way of address this woud be by having a modparam to replicate the socket. What do you think? This is what I'm seeing: anycast node that actually gets the SIP REGISTER: $ kamcmd ul.dump { Domains: { Domain: { Domain: location Size: 32768 AoRs: { Info: { AoR: 309(a)nmreis.test HashID: -35263718 Contacts: { Contact: { Address: sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test Expires: 585 Q: -1.000000 Call-ID: 6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0 CSeq: 4 User-Agent: Jitsi2.11.5602Linux Received: sip: 2.2.2.2:31171 [http://2.2.2.2:31171/] Path: [not set] State: CS_SYNC Flags: 1 CFlags: 192 Socket: udp: 1.1.1.1:5060 [http://1.1.1.1:5060/] Methods: -1 Ruid: uloc-5de8056d-22ab-f Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 1 Last-Keepalive: 1575487540 Last-Modified: 1575487540 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } anycast node that gets the USRLOC update via KDMQ: $ kamcmd ul.dump { Domains: { Domain: { Domain: location Size: 32768 AoRs: { Info: { AoR: 309(a)nmreis.test HashID: -35263718 Contacts: { Contact: { Address: sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test Expires: 574 Q: -1.000000 Call-ID: 6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0 CSeq: 4 User-Agent: Jitsi2.11.5602Linux Received: sip: 2.2.2.2:31171 [http://2.2.2.2:31171/] Path: [not set] State: CS_SYNC Flags: 1 CFlags: 192 Socket: [not set] Methods: -1 Ruid: uloc-5de7ff7b-4617-3 Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 1 Last-Keepalive: 1575487540 Last-Modified: 1575487540 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } the actual KDMQ message: KDMQ sip:usrloc@10.100.100.21:5060 [http://sip:usrloc@10.100.100.21:5060/] SIP/2.0 Via: SIP/2.0/UDP 10.100.100.22;branch= z9hG4bK6034.290e4186000000000000000000000000.0 To: < sip:usrloc@10.100.100.21:5060 [http://sip:usrloc@10.100.100.21:5060/] > From: < sip:usrloc@10.100.100.22:5060 [http://sip:usrloc@10.100.100.22:5060/] >;tag= 3393f0703fb0ccaca74109ff37de39f5-1e4c092b CSeq: 10 KDMQ Call-ID: 0cfde4d32a31addc-8875(a)127.0.0.1 [mailto:0cfde4d32a31addc-8875@127.0.0.1] Content-Length: 433 Max-Forwards: 1 Content-Type: application/json {"action":1,"aor":"309(a)nmreis.test","ruid":"uloc-5de8056d-22ab-f","c":"sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test","received":"sip: 2.2.2.2:31171 [http://2.2.2.2:31171/] ","path":"","callid":"6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0","user_agent":"Jitsi2.11.5602Linux","instance":"","expires":1575487600,"cseq":2,"flags":1,"cflags":192,"q":-1,"last_modified":1575487000,"methods":4294967295,"reg_id":0,"server_id":0} Looking forward to hear from you. BR, -- Nuno Miguel Reis Departamento de Engenharia Informática Faculdade de Ciências e Tecnologia Universidade de Coimbra

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2019