sr-users June 2014

sr-users@lists.kamailio.org

86 participants
144 discussions

Kamailio: MI Command: 'trusted_dump' and 'trusted_reload'

by José Luis Millán

Hi, I'm using 'allow_trusted()' from Permissions module without a problem in a Kamailio 4.0 routing logic. It does just work, but the MI command 'trusted_dump' tells me that the module is not in use: ''' server:/home/jmillan# kamctl fifo trusted_dump 500 Trusted-module not in use ''' Doing a 'trusted_reload' does neither make any query to database to retrieve the data. Other MI commands of same module do work correctly. ie: 'address_reload' or 'address_dump' Note: I have tested in a Kamailio 1.5 and the result is the same. Regards. -- José Luis Millán

9 years

File transferring issue

by Wingsravi R

Dear Kamailio'ns, I am working on kamailio Server (V 4.0) installed on Ubuntu 12.04 system. Currently i am trying file transfer feature using IMSDroid SIP clients. file transferring is fine between two IMSDroid clients but at the receiving end (file recipient) i cont see the sender identity/ sender name. it is just displaying as 'null' (Screen shot is attached). But the full file is transferring to destination address without any problem. I have configured MSRP module related script in my kamailio configuration file (find the attachment). but i guess it is not invoking anyway when file transferring and the file transferring is negotiating client-to-client basis. And also find Sip capture of file transfer (ngrep based) for better understanding. What could be the problem? Why at the file recipient side it is not displaying sender's identity (instead it is 'null')? how can i resolve this issue? Anyone please help me in resolving this issue. Any help will greatly appreciate. Regards, Ravi.

9 years, 1 month

Fwd: Need a support for Siremis and kamailio server

by Gaurav Rai

Hi I am using a siremis and *kamailio * hosted server with lylix.net and they give a link for getting a support about Siremis. I need a support to how to make OUT call on PSTN with registered subscriber on Softphone. Currently we have registered user on subscriber table with their location and can make a PEER to PEER audio call and text messaging also. To make OUT call on PSTN we had create a LCR gateway and LCR rule with Prefix but still can not make a OUT call getting a error 404 can u please help me out to make a PSTN call Waiting for your reply Thanks Gaurav Rai +919716238804

9 years, 3 months

CNXCC PrePaid module

by Rene Montilva

Hi list I don't understand prepaid logic calculation, because when my credit is 0 or lees than cost per second, the call is established equal $var(i_pulse) and $var(f_pulse) how this works????

9 years, 4 months

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error

by vivi

Hi all.. I have solve the problem . Cheers, vivi From: vivi [mailto:vivi.hilton@gmail.com] Sent: Saturday, June 06, 2009 11:29 PM To: 'users(a)lists.kamailio.org' Subject: /usr/local/sbin/kamdbctl create error Hi all I have specify the wanted db type (DBENGINE=MYSQL) in the /usr/local/etc/kamailio/kamctlrc then I using "/usr/local/sbin/kamdbctl create" to create MySQL database, but I got this error: ERROR: database engine not specified, please setup one in the config script root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim /usr/local/etc/kamailio/kamctlrc root@acer:/usr/local/src/kamailio-1.5.0/sip-server# /usr/local/sbin/kamdbctl create MySQL password for root: INFO: test server charset ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database openser ... ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR: Creating core database and grant privileges failed! Cheers, vivi

9 years, 5 months

Hash Table capacity

by Ricardo Martinez

Hello list. I have a question about the HTABLE module. Suppose that I have a mysql database with 2 million of records. Is possible to load this table as a hash table compatible with Kamailio!? Hope someone can help me. Thanks, Ricardo Martinez.-

9 years, 6 months

Re: [SR-Users] Crash Kamailio 4.1.4

by Igor Potjevlesch

Hello, We updated this morning Kamailio in 4.1.4 with your patch. Kamailio crashed again this afternoon. here an extract from /var/log/messages : Jun 25 13:49:01 /usr/local/sbin/kamailio[20259]: WARNING: <script>: time=[Wed Jun 25 13:49:01 2014] call id=[f4653f6fe909d3118f86009033290024(a)A.B.C.D] call seq=[929405] contact header=[<sip:0987654321@A.B.C.D:2057;transport=UDP>] from uri=[sip:0123456789@domain;user=phone] from tag=[16632949] request's method=[INVITE] request's uri=[sip:0123456789@domain;user=phone] to uri=[sip:0123456789@domain;user=phone] to tag=[<null>] sip message id=[46275] process id=[20259] ip source=[A.B.C.D] flags=[2] ua=[(innovaphone IP6010/9.00 hotfix24 [9.061271/9061271/300])], INVITE from 'untrusted' host Jun 25 13:49:01 /usr/local/sbin/kamailio[20259]: WARNING: <script>: time=[Wed Jun 25 13:49:01 2014] call id=[f4653f6fe909d3118f86009033290024(a)A.B.C.D] call seq=[929405] contact header=[<sip:0987654321@A.B.C.D:2057;transport=UDP>] from uri=[sip:0123456789@domain;user=phone] from tag=[16632949] request's method=[INVITE] request's uri=[sip:0123456789@domain;user=phone] to uri=[sip:0123456789@domain;user=phone] to tag=[<null>] sip message id=[46275] process id=[20259] ip source=[A.B.C.D] flags=[2], INVITE from an authorized SIP trunk Jun 25 13:49:01 /usr/local/sbin/kamailio[20259]: WARNING: <script>: time=[Wed Jun 25 13:49:01 2014] call id=[f4653f6fe909d3118f86009033290024(a)A.B.C.D] call seq=[929405] contact header=[<sip:0987654321@A.B.C.D:2057;transport=UDP>] from uri=[sip:0123456789@domain;user=phone] from tag=[16632949] request's method=[INVITE] request's uri=[sip:0123456789@domain;user=phone] to uri=[sip:0123456789@domain;user=phone] to tag=[<null>] sip message id=[46275] process id=[20259] ip source=[A.B.C.D] flags=[2], INVITE from an authorized SDA for current SIP trunk Jun 25 13:49:01 /usr/local/sbin/kamailio[20259]: INFO: carrierroute [cr_func.c:710]: cr_do_route(): uri 0123456789 was rewritten to sip:0123456789@GW, carrier 1, domain 1 Jun 25 13:49:02 /usr/local/sbin/kamailio[20259]: : <core> [mem/q_malloc.c:140]: qm_debug_frag(): BUG: qm_*: fragm. 0x7f12803cb450 (address 0x7f12803cb480) beginning overwritten(abcdefed)! And this is the btfull : #0 0x0000003d6f6328a5 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x0000003d6f634085 in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x0000000000546d3c in qm_debug_frag (qm=0x7f1280275010, f=0x7f12803cb450) at mem/q_malloc.c:142 #3 0x0000000000548b26 in qm_free (qm=0x7f1280275010, p=0x7f12803cb480, file=0x6276a0 "<core>: parser/parse_ppi_pai.c", func=0x627a00 "free_pai_ppi_body", line=102) at mem/q_malloc.c:464 #4 0x000000000056e5e6 in free_pai_ppi_body (pid_b=0x7f12803cb480) at parser/parse_ppi_pai.c:102 #5 0x000000000054fee0 in clean_hdr_field (hf=0x7f1274c3c238) at parser/hf.c:126 #6 0x00007f127cb6dde6 in acc_onreply (t=0x7f1274c157f0, req=0x7f1274c3ac08, reply=0x7f12804a6d70, code=200) at acc_logic.c:501 #7 0x00007f127cb6e30a in tmcb_func (t=0x7f1274c157f0, type=512, ps=0x7fff0b015580) at acc_logic.c:573 #8 0x00007f127ed68478 in run_trans_callbacks_internal (cb_lst=0x7f1274c15860, type=512, trans=0x7f1274c157f0, params=0x7fff0b015580) at t_hooks.c:290 #9 0x00007f127ed6868a in run_trans_callbacks_with_buf (type=512, rbuf=0x7f1274c158b0, req=0x7f1274c3ac08, repl=0x7f12804a6d70, flags=200) at t_hooks.c:336 #10 0x00007f127ed9ac06 in relay_reply (t=0x7f1274c157f0, p_msg=0x7f12804a6d70, branch=0, msg_status=200, cancel_data=0x7fff0b0158e0, do_put_on_wait=1) at t_reply.c:2001 #11 0x00007f127ed9d0b7 in reply_received (p_msg=0x7f12804a6d70) at t_reply.c:2499 #12 0x000000000045d837 in do_forward_reply (msg=0x7f12804a6d70, mode=0) at forward.c:777 #13 0x000000000045e0f8 in forward_reply (msg=0x7f12804a6d70) at forward.c:860 #14 0x00000000004a58e7 in receive_msg (buf=0x924600 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP A.B.C.D;branch=z9hG4bK512b.82b197888826f6b60c0c63b79801294d.0;received=A.B.C.D\r\nVia: SIP/2.0/UDP A.B.C.D:2057;branch=z9hG4bK-129F259C;rport=2057\r\nCall-ID: cb0"..., len=1124, rcv_info=0x7fff0b015c60) at receive.c:273 #15 0x000000000053c9a8 in udp_rcv_loop () at udp_server.c:536 #16 0x000000000046d42b in main_loop () at main.c:1617 #17 0x0000000000470533 in main (argc=7, argv=0x7fff0b015f98) at main.c:2545 It seems to be the same problem but in a different source. Can you help me? Regards, Igor. 2014-06-12 17:46 GMT+02:00 Igor Potjevlesch <igor.potjevlesch(a)gmail.com>: > Hello, > > we didn't set the early media parameter . its '0' by default, isn't it? > > regards, > > Igor > > > > > 2014-06-12 17:03 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com>: > > Hello, >> >> if you get a record for 180 response, then you have also the early_media >> parameter set for acc module, isn't it? >> >> In the morning I pushed a patch that should fix this issue. Use latest >> release 4.1.4 and see if works fine. Report the results to know that it is >> gone or not. >> >> Cheers, >> Daniel >> >> >> On 12/06/14 16:55, Igor Potjevlesch wrote: >> >> Hello, >> >> We don't use $ai in xlog nor in other process. only in ACC. >> >> parameters for ACC are : >> modparam("acc", "db_flag", FLT_ACC) >> modparam("acc", "db_missed_flag", 3) >> modparam("acc", "db_url", DBURLWO) >> modparam("acc", "db_extra", >> "src_user=$fU;username=$Au;src_domain=$fd;src_ip=$si;src_pai=$ai;" >> "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") >> >> For the 3781-4b1-572014182635-OGNAJ-1-A.B.C.D there is a code 180 >> ringing in the INVITE in ACC table. >> >> regards, >> >> Igor >> >> >> 2014-06-11 23:01 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com>: >> >>> Few more things... >>> >>> Are you recording 1xx events? Can you check to see if there is another >>> record in acc table for the same call? You can search by call-id >>> 3781-4b1-572014182635-OGNAJ-1-A.B.C.D >>> >>> Eventually, send also the parameters you set for acc module. >>> >>> Cheers, >>> Daniel >>> >>> >>> On 11/06/14 19:25, Daniel-Constantin Mierla wrote: >>> >>> Hello, >>> >>> so you don't print $ai in xlog() statements nor use it in any >>> assignments or other functions besides acc parameter? >>> >>> Cheers, >>> Daniel >>> >>> On 11/06/14 19:19, Igor Potjevlesch wrote: >>> >>> Hello, >>> >>> We do not access to the P-asserted-identity in our configuration but >>> we added the field PAI in the db base ACC ( for INVITE, ACK and BYE) . >>> I dont know if it's in request_route, failure_route or branch_route . >>> >>> This is the print : >>> >>> (gdb) p mem_block >>> $3 = (struct qm_block *) 0x7f6a6bef1010 >>> (gdb) p shm_block >>> $4 = (struct qm_block *) 0x7f6a5666a000 >>> >>> Regards, >>> >>> Igor >>> >>> >>> 2014-06-11 18:02 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com>: >>> >>>> Hello, >>>> >>>> cloning to shm for tm seems ok. Can you tell where you access >>>> P-Asserted-Identity header, via variables? Does it happen in request_route, >>>> failure_route or branch_route? >>>> >>>> Can you print from gdb, any frame: >>>> >>>> p mem_block >>>> p shm_block >>>> >>>> I want to see if parsed filed point to shm or pkg memory. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 11/06/14 17:37, Daniel-Constantin Mierla wrote: >>>> >>>> Hello, >>>> >>>> at least I narrowed it down a bit. It is empty also in the clone stored >>>> in transaction, so it happens either during cloning or before. I will have >>>> to check these parts. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> On 11/06/14 17:00, Igor Potjevlesch wrote: >>>> >>>> Hello, >>>> >>>> This is the result, always for frame 5 : >>>> >>>> (gdb) p *t->uas.request->pai >>>> $1 = {type = HDR_PAI_T, name = { >>>> s = 0x7f6a60cd34b8 "P-Asserted-Identity: \"0987654321\" >>>> <sip:0987654321@A.B.C.D>\r\nContact: <sip:0987654321@A.B.C.D:5060>\r\nAllow: >>>> INVITE, BYE, REGISTER, ACK, OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, >>>> REFER, UPD"..., len = 19}, body = { >>>> s = 0x7f6a60cd34cd "\"0987654321\"<sip:0987654321@A.B.C.D>\r\nContact: >>>> <sip:0987654321@A.B.C.D:5060>\r\nAllow: INVITE, BYE, REGISTER, ACK, >>>> OPTIONS, CANCEL, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE\r\nSupported: >>>> path,"..., len = 43}, len = 66, parsed = 0x7f6a6d81da88, next = >>>> 0x7f6a60cd3f10} >>>> >>>> (gdb) p *((p_id_body_t*)(t->uas.request->pai->parsed)) >>>> $2 = {id = 0x0, num_ids = 0, next = 0x0} >>>> >>>> *Did *you find one thing in common between the 2 occurrences? Do you >>>> have any ideas about what is the cause of this pai reset? >>>> >>>> Regards, >>>> >>>> Igor >>>> >>>> >>>> >>>> >>>> 2014-06-11 16:09 GMT+02:00 Daniel-Constantin Mierla <miconda(a)gmail.com> >>>> : >>>> >>>>> Hello, >>>>> >>>>> in the same frame 5, can yo get: >>>>> >>>>> p *t->uas.request->pai >>>>> p *((p_id_body_t*)(t->uas.request->pai->parsed)) >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>> On 10/06/14 18:35, Igor Potjevlesch wrote: >>>>> >>>>> Hello, >>>>> >>>>> Here is the results : >>>>> >>>>> (gdb) frame 5 >>>>> #5 0x00007f6a687e9b43 in acc_onreply (t=0x7f6a60d16ff8, >>>>> req=0x7f6a60cd2c10, reply=0x7f6a6c119aa8, code=200) at acc_logic.c:471 >>>>> 471 acc_db_request(req); >>>>> >>>>> >>>>> >>>>> -- >>>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>>> >>>>> >>>> >>>> -- >>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>> >>>> >>>> -- >>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>>> >>>> >>> >>> -- >>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>> >>> >>> -- >>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >>> >>> >> >> -- >> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> >> >

9 years, 6 months

RFC: updating default values

by Daniel-Constantin Mierla

Hello, I am opening this discussion to decide if there is need to adjust some of the default values we have in Kamailio. Many of them were set even like 10 years ago, so they might not be very actual anymore. The main goal is to get the best possible settings for common usage. To start with, here are some values that should be reviewed: - default private memory is 4MB - if the config is not that small, it might not be sufficient free pkg to play with (e.g., for sql_query() result, storage of $var(...) values). Should it be increased to 8MB or other value? Debian/Centos have startup script that sets its value to 8 via command line - default shared memory is 32MB - for a decent deployment with tm, location, lcr/dispatcher, permissions, and anti-flood, it might leave not much free space. Should we double it or set to a different value - usrloc - db_ops_ruid should enabled (1) - seems stable, without it there are problems updating/deleting location records when UA changes the call-id for same contact address. - usrloc - hash_size - now is 9, which results in 512 slots, meaning is ok for few thousands of registered users, for more, performance will decrease when doing save/lookup location -- should it be made 10 (1024 slots for internal hash table)? - auth_db - load_credentials defaults to 'rpid', meaning that the query to get the password will retrieve also the rpid column. I haven't see rpid being used that much lately (replaced by PAI/PPI). I would make this parameter empty by default to avoid querying for an extra column that is likely to be empty. Perhaps there are more, I just wanted to get started. Reply with your comments to above list as well as add new items you thinks their default values should be adjusted. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

9 years, 6 months

XMLRPC problem

by Kelvin Chua

i am currently having problems on xmlrpc i am using node-xmlrpc and it fails when htable.dump returns more than 1 row. i raised this issue on the node-xmlrpc group and this is the explanation i got. Each <value> node inside <param> is supposed to only have one child node, so this looks like an invalid response. The<value> should (probably, i don't know your use case) contain an <array> with <data> wrapped around the structs. Seehttp://xmlrpc.scripting.com/spec.html does this mean kamailio is not following standards? here is the working response: <methodResponse> <params> <param> <value><struct><member><name>entry</name><value><int>6</int></value></member><member><name>size</name><value><int>1</int></value></member><member><name>slot</name><value><struct><member><name>item</name><value><struct><member><name>name</name><value><string>4::num</string></value></member><member><name>value</name><value><int>1</int></value></member></struct></value></member></struct></value></member></struct> </value> </param> </params> </methodResponse> here is the non-working response: <methodResponse> <params> <param> <value><struct><member><name>entry</name><value><int>6</int></value></member><member><name>size</name><value><int>1</int></value></member><member><name>slot</name><value><struct><member><name>item</name><value><struct><member><name>name</name><value><string>4::num</string></value></member><member><name>value</name><value><int>1</int></value></member></struct></value></member></struct></value></member></struct> <struct><member><name>entry</name><value><int>11</int></value></member><member><name>size</name><value><int>1</int></value></member><member><name>slot</name><value><struct><member><name>item</name><value><struct><member><name>name</name><value><string>3::num</string></value></member><member><name>value</name><value><int>1</int></value></member></struct></value></member></struct></value></member></struct> </value> </param> </params> </methodResponse> Kelvin Chua

9 years, 8 months

Kamailio with rtpproxy-ng and mediaproxy-ng: Error rewriting SDP

by Olli Heiskanen

Hello, I've been experimenting with Kamailio with ws and sip clients and could need a hand in getting a call between those two to work. I have Kamailio 4.1.2 (using rtpproxy-ng instead of rtpproxy) on a CentOS 6.5 and a mediaproxy-ng running. I have clients wsclient(a)testers.com and gsclient(a)testers.com and I try to make call from wsclient to gsclient. The wsclient is a jssip client running on chrome and gsclient is a grandstream desk phone. My config file is the default one enhanced by online examples. I use a html5 <audio> element for the media streams, and configured my jssip phone to accept audio options like this: var options = { 'eventHandlers': eventHandlers, 'mediaConstraints': {'audio': true, 'video': false } }; sipUA.call(callto, options); I used the instructions from here: http://www.slideshare.net/crocodilertc/webrtc-websockets What I get is gsclient ringing, and as I answer there is no audio and call hangs up in a few seconds. I guess this is a SDP problem, something between Kamailio and Mediaproxy-ng but SDP is not my strong point so I'd appreciate advice. Question is where's my misconfiguration/problem? I would like to learn why this problem occurs and how to fix it rather than getting a solution right away, but please bear in mind I don't know much about SDP. In Kamailio log I see: kamailio[27059]: ERROR: rtpproxy-ng [rtpproxy.c:1346]: rtpp_function_call(): proxy replied with error: Error rewriting SDP kamailio[27058]: ERROR: rtpproxy-ng [rtpproxy.c:1346]: rtpp_function_call(): proxy replied with error: Unknown call-id kamailio[27057]: ERROR: rtpproxy-ng [rtpproxy.c:1346]: rtpp_function_call(): proxy replied with error: Unknown call-id Following are the INVITEs and 200 OKs from my SIP trace (1.1.1.1 is the ip of my Kamailio & mediaproxy-ng box and 2.2.2.2 is the public ip behind which both my clients are). The gsclient has port 5066. ****************************************************************************** U 2014/04/01 20:03:41.060009 1.1.1.1:5060 -> 2.2.2.2:5066 INVITE sip:gsclient@192.168.0.106:5066;transport=udp SIP/2.0. Record-Route: <sip:1.1.1.1;r2=on;lr=on;nat=yes>. Record-Route: <sip:1.1.1.1;transport=ws;r2=on;lr=on;nat=yes>. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKb703.fbb259c1d8c17e163876ec760e086145.0. Via: SIP/2.0/WS kj59uak271em.invalid;rport=38986;received=2.2.2.2;branch=z9hG4bK9891267. Max-Forwards: 16. To: <sip:gsclient@testers.com>. From: <sip:wsclient@testers.com>;tag=hhcd99tmvm. Call-ID: 1dluvk38g1j22fn96t4b. CSeq: 7237 INVITE. Contact: <sip:wsclient@testers.com ;gr=urn:uuid:f6014564-88cb-4f57-9ae5-3b4336ef9db8;ob;alias=2.2.2.2~38986~5;alias=2.2.2.2~38986~5>. Allow: ACK,CANCEL,BYE,OPTIONS,INVITE. Content-Type: application/sdp. Supported: path, outbound, gruu. User-Agent: JsSIP 0.3.0. Content-Length: 2211. . v=0. o=- 4897716268503406223 2 IN IP4 1.1.1.1. s=-. t=0 0. a=group:BUNDLE audio. a=msid-semantic: WMS vMh5vhUEQzvVKJYdqRkAuCcXVa2blgbEXARZ. m=audio 30028 RTP/SAVPF 111 103 104 0 8 106 105 13 126. c=IN IP4 1.1.1.1. a=candidate:2999745851 1 udp 2113937151 192.168.56.1 63341 typ host generation 0. a=candidate:2999745851 2 udp 2113937151 192.168.56.1 63341 typ host generation 0. a=candidate:3350409123 1 udp 2113937151 192.168.0.101 63342 typ host generation 0. a=candidate:3350409123 2 udp 2113937151 192.168.0.101 63342 typ host generation 0. a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 0 typ host generation 0. a=candidate:4233069003 2 tcp 150995 T 2014/04/01 20:03:41.119806 2.2.2.2:38986 -> 1.1.1.1:5060 [A] ...... U 2014/04/01 20:03:41.159086 2.2.2.2:5066 -> 1.1.1.1:5060 SIP/2.0 488 Not Acceptable Here. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKb703.fbb259c1d8c17e163876ec760e086145.0. Via: SIP/2.0/WS kj59uak271em.invalid;rport=38986;received=2.2.2.2;branch=z9hG4bK9891267. Record-Route: <sip:1.1.1.1;r2=on;lr=on;nat=yes>. Record-Route: <sip:1.1.1.1;transport=ws;r2=on;lr=on;nat=yes>. From: <sip:wsclient@testers.com>;tag=hhcd99tmvm. To: <sip:gsclient@testers.com>;tag=7875f08763872c34. Call-ID: 1dluvk38g1j22fn96t4b. CSeq: 7237 INVITE. User-Agent: Grandstream GXP2000 1.2.2.26. Warning: 304 GS "Media type not available". Content-Length: 0. . U 2014/04/01 20:03:41.159392 1.1.1.1:5060 -> 2.2.2.2:5066 ACK sip:gsclient@192.168.0.106:5066;transport=udp SIP/2.0. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKb703.fbb259c1d8c17e163876ec760e086145.0. Max-Forwards: 16. To: <sip:gsclient@testers.com>;tag=7875f08763872c34. From: <sip:wsclient@testers.com>;tag=hhcd99tmvm. Call-ID: 1dluvk38g1j22fn96t4b. CSeq: 7237 ACK. Content-Length: 0. . U 2014/04/01 20:03:41.161085 1.1.1.1:5060 -> 2.2.2.2:5066 INVITE sip:gsclient@192.168.0.106:5066;transport=udp SIP/2.0. Record-Route: <sip:1.1.1.1;r2=on;lr=on;nat=yes>. Record-Route: <sip:1.1.1.1;transport=ws;r2=on;lr=on;nat=yes>. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKb703.fbb259c1d8c17e163876ec760e086145.1. Via: SIP/2.0/WS kj59uak271em.invalid;rport=38986;received=2.2.2.2;branch=z9hG4bK9891267. Max-Forwards: 16. To: <sip:gsclient@testers.com>. From: <sip:wsclient@testers.com>;tag=hhcd99tmvm. Call-ID: 1dluvk38g1j22fn96t4b. CSeq: 7237 INVITE. Contact: <sip:wsclient@testers.com ;gr=urn:uuid:f6014564-88cb-4f57-9ae5-3b4336ef9db8;ob;alias=2.2.2.2~38986~5;alias=2.2.2.2~38986~5>. Allow: ACK,CANCEL,BYE,OPTIONS,INVITE. Content-Type: application/sdp. Supported: path, outbound, gruu. User-Agent: JsSIP 0.3.0. Content-Length: 3136. . v=0. o=- 4897716268503406223 2 IN IP4 1.1.1.1. s=-. t=0 0. a=group:BUNDLE audio. a=msid-semantic: WMS vMh5vhUEQzvVKJYdqRkAuCcXVa2blgbEXARZ. m=audio 30028 RTP/AVP 111 103 104 0 8 106 105 13 126. c=IN IP4 1.1.1.1. a=fingerprint:sha-256 72:54:87:EC:D2:4C:D1:70:C2:FE:69:08:20:5C:92:1D:E0:EA:BD:45:09:E0:90:62:27:B6:34:60:54:E2:99:28. a=setup:actpass. a=mid:audio. a=sendrecv. a=rtpmap:111 opus/48000/2. a=fmtp:111 minptime=10. a=rtpmap:103 ISAC/16000. a=rtpmap:104 ISAC/32000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:106 CN/32000. a=rtpmap:105 CN/16000. a=rtpmap:13 CN/8000. a=rtpmap:126 telephone-event/8000. a=maxptime:60. a=ssrc:3298511848 cnam And here are the 200 OK messages when answering the call: U 2014/04/01 20:03:46.049711 2.2.2.2:5066 -> 1.1.1.1:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bKb703.fbb259c1d8c17e163876ec760e086145.1. Via: SIP/2.0/WS kj59uak271em.invalid;rport=38986;received=2.2.2.2;branch=z9hG4bK9891267. Record-Route: <sip:1.1.1.1;r2=on;lr=on;nat=yes>. Record-Route: <sip:1.1.1.1;transport=ws;r2=on;lr=on;nat=yes>. From: <sip:wsclient@testers.com>;tag=hhcd99tmvm. To: <sip:gsclient@testers.com>;tag=fb215901a251c9a0. Call-ID: 1dluvk38g1j22fn96t4b. CSeq: 7237 INVITE. User-Agent: Grandstream GXP2000 1.2.2.26. Contact: <sip:gsclient@192.168.0.106:5066;transport=udp>. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE. Content-Type: application/sdp. Supported: replaces, timer. Content-Length: 216. . v=0. o=gsclient 8000 8000 IN IP4 192.168.0.106. s=SIP Call. c=IN IP4 192.168.0.106. t=0 0. m=audio 5026 RTP/AVP 0 13. a=sendrecv. a=rtpmap:0 PCMU/8000. a=ptime:20. m=audio 0 RTP/SAVPF 111 103 104 0 8 106 105 13 126. T 2014/04/01 20:03:46.051127 1.1.1.1:5060 -> 2.2.2.2:38986 [AP] .~.dSIP/2.0 200 OK. Via: SIP/2.0/WS kj59uak271em.invalid;rport=38986;received=2.2.2.2;branch=z9hG4bK9891267. Record-Route: <sip:1.1.1.1;r2=on;lr=on;nat=yes>. Record-Route: <sip:1.1.1.1;transport=ws;r2=on;lr=on;nat=yes>. From: <sip:wsclient@testers.com>;tag=hhcd99tmvm. To: <sip:gsclient@testers.com>;tag=fb215901a251c9a0. Call-ID: 1dluvk38g1j22fn96t4b. CSeq: 7237 INVITE. User-Agent: Grandstream GXP2000 1.2.2.26. Contact: <sip:gsclient@192.168.0.106:5066;transport=udp>. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE. Content-Type: application/sdp. Supported: replaces, timer. Content-Length: 216. . v=0. o=gsclient 8000 8000 IN IP4 192.168.0.106. s=SIP Call. c=IN IP4 192.168.0.106. t=0 0. m=audio 5026 RTP/AVP 0 13. a=sendrecv. a=rtpmap:0 PCMU/8000. a=ptime:20. m=audio 0 RTP/SAVPF 111 103 104 0 8 106 105 13 126. ****************************************************************************** cheers, Olli

9 years, 8 months

Jump to page:

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