sr-users April 2014

sr-users@lists.kamailio.org

100 participants
170 discussions

by Andrzej Ciupek

Yes. I want prepaid subscribers be able to create only one channel to prevent frauds for simultaneous calls. Greetings Andrzej Ciupek ________________________________ Od: Carlos Ruiz Díaz<mailto:carlos.ruizdiaz@gmail.com> Wysłano: ‎2014-‎04-‎26 16:42 Do: Andrzej Ciupek<mailto:andrzej.ciupek@hotmail.com> DW: Kamailio (SER) - Users Mailing List<mailto:sr-users@lists.sip-router.org> Temat: Re: [SR-Users] cnxcc Hi Andrzej, are you trying to setup cnxcc to check both credit and maximum simultaneous calls? Regards, On Sat, Apr 26, 2014 at 9:26 AM, Andrzej Ciupek <andrzej.ciupek(a)hotmail.com>wrote: > Hello > > I’am using default config with options from an example. It looks like > event route isn’t execuded after hangup. > > Apr 26 16:26:14 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:15 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:16 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:17 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:18 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:19 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:20 kamailio /usr/local/sbin/kamailio[4611]: INFO: <script>: > 1000 has 1 call(s) > Apr 26 16:26:20 kamailio /usr/local/sbin/kamailio[4604]: INFO: <script>: > Setting up money based credit control > Apr 26 16:26:20 kamailio /usr/local/sbin/kamailio[4604]: INFO: <script>: > Setting up channel based credit control > Apr 26 16:26:20 kamailio /usr/local/sbin/kamailio[4604]: INFO: <script>: > CNXCC ROUTE: 1000 has 2 call(s) > > kamailio.cfg > … > … > # ----- prepaid call controll ----- > > #!define DLG_FLAG 28 > #!define CC_FLAG 29 > > loadmodule "dialog.so" > > modparam("dialog", "hash_size", 2048) > modparam("dialog", "default_timeout", 3600) > modparam("dialog", "db_mode", 0) > modparam("dialog", "dlg_flag", DLG_FLAG) > > modparam("rtimer", "timer", "name=ta;interval=1;mode=1;") > modparam("rtimer", "exec", "timer=ta;route=SHOW_CHANNEL_COUNT") > > loadmodule "cnxcc.so" > > modparam("cnxcc", "dlg_flag", CC_FLAG) > modparam("cnxcc", "credit_check_period", 1) #check every 1 second > > … > … > … > route { > … > … > if (!allow_source_address("2") and !allow_source_address("1")){ > route(CNXCC); > route(PSTN); > } > … > } > > route[CNXCC] > { > > $var(client) = "1000"; > > xlog("L_INFO", "Setting up money based credit control"); > > $var(credit) = "10"; # 10$ of credit > $var(cost_per_sec) = "1"; # 1$ per sec > $var(i_pulse) = "1"; # 1$ to establish the call > $var(f_pulse) = "1"; # 1$ per second > > # if only one call is established, that call should last 9 seconds. > > if (!cnxcc_set_max_credit("$var(client)", > "$var(credit)", > "$var(cost_per_sec)", > "$var(i_pulse)", > "$var(f_pulse)")) { > xlog("Error setting up credit control"); > return; > } > $var(count) = -1; > > if (!cnxcc_get_channel_count("$var(client)", "$var(count)")) { > xlog("Error getting customer's channel count"); > } > > xlog("L_INFO", "CNXCC ROUTE: $var(client) has $var(count) > call(s)"); > > if ($var(retcode) < -1) { > xlog("Too many channels for customer"); > sl_send_reply(403, "Forbidden"); > > if (!cnxcc_terminate_all("$var(client)")) { > xlog("Error terminating customer's calls"); > } else { > xlog("Terminating customer's call"); > } > > exit; > } > } > > route[SHOW_CHANNEL_COUNT] > { > $var(count) = @cnxcc.channels["1000"].count; > xlog("L_INFO", "1000 has $var(count) call(s)"); > } > > event_route[dialog:failed] > { > xlog("dialog failed"); > } > > event_route[cnxcc:call-shutdown] > { > xlog("L_INFO", "Shutting down channel by callcontroll"); > xlog("L_INFO", "[$ci]: call killed"); > $var(count) = $var(count)-1; > if (!cnxcc_get_channel_count("$var(client)", "$var(count)")) { > xlog("Error getting customer's channel count"); > } > xlog("L_INFO", "CNXCC ROUTE: $var(client) has $var(count) > call(s)"); > # perform some kind of notification, database update, email > sending, etc > } > > Greetings > Andrzej Ciupek > > *Od:* Carlos Ruiz Díaz <carlos.ruizdiaz(a)gmail.com> > *Wysłano:* ‎sobota‎, ‎26‎ ‎kwietnia‎ ‎2014 ‎15‎:‎19 > *Do:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org>, > Andrzej Ciupek <andrzej.ciupek(a)hotmail.com> > > Hi, > > sorry guys, I forgot about this. I will make my own tests and post the > results. > > Andrzej, can you post the configuration file you are using? > > Regards, > Carlos > > > On Sat, Apr 26, 2014 at 4:15 AM, Kelvin Chua <kelchy(a)gmail.com> wrote: > >> No, I have not yet found the solution for this issue on my setup. >> >> Maybe Carlos can help us out >> On Apr 26, 2014 5:10 PM, "Andrzej Ciupek" <andrzej.ciupek(a)hotmail.com> >> wrote: >> >>> Hello >>> >>> Have You solved this issue ? >>> I’am using Kamailio 4.1.3 and I’am getting the same results. >>> >>> Greetings >>> Andrzej Ciupek >>> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > > > -- > Carlos > http://caruizdiaz.com > http://ngvoice.com > +52 55 3048 3303 > -- Carlos http://caruizdiaz.com http://ngvoice.com +52 55 3048 3303

9 years, 10 months

Kamailio and MSILO with TLS AORs

by Roberto Fichera

Hi All, I've started to play with MSILO module on kamailio v4.1.2, but it seems that all the stored messages aren't delivered to the give user even if, looking at the debug log, the given messages are found and queued for shipping. Another info I can add is that all the users are connected in TLS. The relevant conf is below. Doe anyone can suggest a working setup for TLS users? Thanks in advance, Roberto Fichera. # ----- msilo params ----- modparam("msilo", "db_url", DBURL) modparam("msilo", "from_address", "sip:$rU@test.net") modparam("msilo", "contact_hdr", "Contact: msilo@test.net:5060;msilo=yes\r\n") modparam("msilo", "content_type_hdr", "Content-Type: text/plain\r\n") # Handle SIP registrations route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } # MSILO - dumping user's offline messages if (m_dump()) { xlog("MSILO: offline messages dumped - if they were for user $fu\n"); } else { xlog("MSILO: no offline messages dumped\n"); } exit; } } and in the route[LOCATION] I've this snippet xlog( "Checking the destination user $rU exists\n"); if(avp_db_query("select username from subscriber where username='$rU'")) { xlog("MESSAGE received $ru -> storing using MSILO user=$rU\n"); if(m_store("$ru")) { xlog("MSILO: offline message stored\n"); if (!t_reply("202", "Accepted")) { sl_reply_error(); } } else { xlog("MSILO: offline message NOT stored\n"); if (!t_reply("503", "Service Unavailable")) { sl_reply_error(); } } # if the downstream UA doesn't support MESSAGE requests # go to failure_route[1] t_on_failure("1"); exit; } else { # The destination recipiend doen't exist xlog( "Unable to store message for $ru because the user doesn't exist" ); if (!t_reply("404", "Not Found")) { sl_reply_error(); } exit; } }

9 years, 10 months

TLS and SIP

by Fabian Borot

Hi I am using Kamailio 4.0.1 in front of an asterisk servers farm to handle TLS with our clients and providers. The idea is to have kamailio "talking" SIP/UDP/5060 and TLS/TCP/5061 with the customers and providers and regular SIP/UDP/5060 with our internal asterisk servers. So far at least for the customers it looks like it can work. But I have a problem, when the call is established and the called person hangs up, the BYE from the called person to the calling person is ignored. Only when the calling person hangs up first the call is terminated properly. This is what I have been able to see: 1- Customer starts the TLS handshake/connection. 2- Kamailio authenticate it, then routes the call to the asterisk server using regular SIP/UDP/5060 but I see that it is inserting 2 Record Routes in the INVITE: Record-Route: <sip:192.168.1.58;r2=on;lr=on> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> 3- The Contact on that INVITE to the asterisk also comes like this: Contact: <sip:94167032@172.31.196.21:53325;transport=tls> 4- The ACK sent to the asterisk once it accepts the call (200 OK) also has those 2 Record-Routes: Record-Route: <sip:192.168.1.58;r2=on;lr=on> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> 5- The call is established, once the called person decides to hang up the BYE looks like this: BYE sip:94167032@172.31.196.21:53325;transport=tls SIP/2.0 Via: SIP/2.0/UDP 192.168.1.59:5060;branch=z9hG4bK40fa1c23;rport Route: <sip:192.168.1.58;r2=on;lr=on>,<sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> Max-Forwards: 70 From: <sip:3030500@1.2.3.4>;tag=as37953869 To: "kamailio" <sip:kamailio@1.2.3.4>;tag=788cd7c892df40f3b1967112395e2ca4 Call-ID: f9fe65daf1074219be26cb0c224339f1 CSeq: 102 BYE User-Agent: Asterisk PBX 11.3.0 X-Asterisk-HangupCause: Normal Clearing X-Asterisk-HangupCauseCode: 16 Content-Length: 0 My kamailio TLS config is shown below: enable_tls=yes loadmodule "tls.so" # ----- tls params ----- modparam("tls", "config", "/usr/local/kamailio-4.1//etc/kamailio/tls.cfg") modparam("tls", "private_key", "./privkey.pem") modparam("tls", "certificate", "./kamailio1_cert.pem") modparam("tls", "ca_list", "./calist.pem") modparam("tls", "verify_certificate", 1) modparam("tls", "require_certificate", 1) The TLS client that I am using is called Blink.At this point I don't know whether kamailio is sending the BYE using TLS to the customer and waiting for the 200 OK from the customer or whether kamailio does not like something in the BYE and that is why is ignoring it. I see some encrypted packets from kamailio to the client but I don't know what is inside. Any help would be very appreciated. thank you fabian

9 years, 11 months

Realtime integration: Unregistered clients showing as registered?

by Olli Heiskanen

Hello, One of the tests I've been working with is Asterisk realtime integration according to Daniel's guide here: http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb Weird thing is the client looks registered but I'm not sure if it really is registered. If I'm not mistaken I should see the peers when I issue 'sip show peers' on asterisk cli. Instead I get this: *CLI> sip show peers Name/username Host Dyn Forcerport Comedia ACL Port Status Description Realtime 0 sip peers [Monitored: 0 online, 0 offline Unmonitored: 0 online, 0 offline] Also, calling between clients will fail; in Asterisk cli I get: *CLI> == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 -- Executing [661@default:1] NoOp("SIP/660-00000000", "Testing: Dialed 661") in new stack -- Executing [661@default:2] Dial("SIP/660-00000000", "SIP/661,3600,rt") in new stack == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 -- Called SIP/661 == Everyone is busy/congested at this time (1:0/0/1) -- Executing [661@default:3] Hangup("SIP/660-00000000", "") in new stack == Spawn extension (default, 661, 3) exited non-zero on 'SIP/660-00000000' In this setup I have SIP peers in an asterisk table added like this: INSERT INTO sippeers (name, defaultuser, host, sippasswd, fromuser, fromdomain) VALUES ('660', '660', 'dynamic', 'password', '660', 'testers.com '); I have Kamailio and Asterisk on the same machine where Kamailio listens port 5060 and Asterisk listens 5070. Things that differ from the guide are Kamailio and Asterisk versions, which in my case are newer. Also, for another testing case I have MULTIDOMAIN enabled in Kamailio, does this interfere with the realtime integration? I'm using only one domain though. Please let me know if any configs or traces I can provide will help figure out what's going on. cheers, Olli

9 years, 11 months

Proper way to make Asterisk recognize SIP trunk of incoming INVITE when IP is not available

by Alex Villacís Lasso

I am currently preparing a kamailio-asterisk combination. The asterisk installation uses realtime for SIP. The kamailio configuration (attached) was based on the reference at http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb but has been heavily modified. Currently asterisk runs on localhost and only listens on SIP/RTP at 127.0.0.1 . Therefore, all of the SIP traffic appears to come from localhost, from the point of view of asterisk. Currently I have a model on which internal SIP phones get identified by the authentication username, and then the contact names at From: and To: get massaged to incorporate the SIP domain, in order to emulate multiple-domain support. The 'sip' table in Asterisk defines all such contacts as SIP accounts of the form name_domain.com, and the SIP phones are configured to use 'name' as authentication username for domain 'domain.com'. However, SIP providers that register on the server with authentication names are left with their original names, since in the model, SIP trunks are available to all domains. Now I have to add support for SIP providers which are to be authorized on the basis of IP only. Apparently, the permissions.so (WITH_IPAUTH) is made for just this purpose, so I enabled it. After authentication, I need to route the INVITE to asterisk, and asterisk must somehow match the account for the SIP trunk from the available information on the INVITE request. A typical INVITE for this scenario looks like this, before being processed by kamailio: INVITE sip:6008010@172.28.161.218:5060;transport=udp;user=phone SIP/2.0 Via: SIP/2.0/UDP 200.25.144.58:5060;branch=z9hG4bK+676ea13f680e853fd847230512a347561+32e3da76+1 Call-ID: FBE75B3A@32e3da76 From: <sip:042294440@200.25.144.58:5060;user=phone>;tag=32e3da76+1+544c000c+52be771c To: <sip:6008010@172.28.161.218:5060;user=phone> CSeq: 975469826 INVITE Expires: 180 Organization: SetelGYE Min-SE: 90 Session-Expires: 18000 Supported: replaces, 100rel, timer Contact: <sip:042294440@200.25.144.58:5060;transport=udp;user=phone> Content-Length: 149 Content-Type: application/sdp Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, NOTIFY, PRACK, UPDATE, INFO, REFER v=0 o=- 0 0 IN IP4 201.217.79.3 s=- c=IN IP4 201.217.79.3 t=0 0 m=audio 5388 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Here, 6008010 is the phone number that was dialed at the provider in order to reach my system, and 042294440 is the provider-supplied Caller-ID, which I want to preserve all the way to Asterisk. In particular, 042294440 appears as the value that ends up as $fU (From: username) while being processed in kamailio. If I pass the SIP packet as-is to asterisk, asterisk first tries to match by the value of $fU, which obviously fails to match the trunk name. It then tries to match by incoming IP, which also fails because asterisk received this packet from 127.0.0.1 . Finally, asterisk sort of matches to the first record in the sip table, which is *not* the SIP account for this trunk, but some other random account. I have a partial solution that uses sqlops to make a query to the sip table, using the $si (source IP) and reads the trunk name in order to replace $fU. This works, as now $fU will have the trunk name and asterisk will now recognize the intended SIP account for the trunk. However, this has the unfortunate side effect of throwing out the Caller-ID information. What is the standard/proper way to deal with this situation? Is there a well-known way to make Asterisk match the trunk name, without overwriting the Caller-ID information? Before you ask, requesting the provider to modify its INVITEs is not an option. I believe there is a standard way to deal with this, since this scenario should also arise with a kamailio that faces the internet, and relays INVITEs (after authentication) to an asterisk in a local network. As far as I can tell, the fact that in my case the 'local network' is localhost should be irrelevant.

9 years, 11 months

Kamailio v4.0.5 crash - transformations related ?

by Dragos Oancea

Hi We experimented a crash with kamailio 4.0.5 , it looks like a memory corruption. After an analyse of the core file, it appears that it crashed while doing a str2int transformation (trying to convert the value of myvar to int): if (($(dlg_var("myvar"){s.int}) == 0) && some_other_condition ) { do_something(); } gdb output: (gdb) frame 4 #4 0x00000000004bcb77 in rval_get_btype (h=0x7fffd69713d0, msg=0x7ffc8a58a4d0, rv=0x7ffc8a3dfc18, val_cache=0x7fffd69706a0) at rvalue.c:418 418in rvalue.c (gdb) i loc r_avp = 0x7fffd69709b0 tmp_avp_val = {n = -1975661232, s = {s = 0x7ffc8a3dcd50 "\034\001", len = -1973902128}, re = 0x7ffc8a3dcd50} avpv = 0x7fffd6970928 tmp_pval = {rs = {s = 0x7ffc8a5b86e0 "route[MAIN]: call-id=52e8c2b553540db4 from=987654321 to=+1234567890 : ACK ip=10.0.x.x", len = -1975658024}, ri = -694745968, flags = 32767} pv = 0x7fffd69706a8 tmp = RV_NONE ptype = 0x7ffc8a58a4d0 __FUNCTION__ = "rval_get_btype" (gdb) p *pv $8 = {rs = {s = 0x7069736f58652820 <Address 0x7069736f58652820 out of bounds>, len = 775106354}, ri = 0, flags = 4} (gdb) p val_cache->c.pval $9 = {rs = {s = 0x7069736f58652820 <Address 0x7069736f58652820 out of bounds>, len = 775106354}, ri = 0, flags = 4} <- the value of s is invalid, it's a string from a SIP message. Full GDB backtrace and info locals here : kamailio 4.0.5 crash - memory corruption ? - Pastebin.com kamailio 4.0.5 crash - memory corruption ? - Pastebin.co... (gdb) bt full #0 0x00007ffc822851e8 in str2sint (_s=0x7fffd69706a8, _r=0x7fffd69706b8) at ../../ut.h:681 i = 0 sign = 1 View on pastebin.com Preview by Yahoo I still have the core file and I can help with further analysis . Regards, Dragos PS: Kamailio still rocks.

9 years, 11 months

What does this script do?.

by VOIP Tests

Can someone let me know what this script does? avp_db_load("$ru/domain","i:/domain_preferences"); Thank you, Arun

9 years, 11 months

Limit the number of requests per second based on the user

by Sebastian Damm

Hi, I'm looking for a solution to limit the number of call initiations or OPTIONS packets or REGISTER packets per user. Neither pike, nor pipelimit or ratelimit give me the possibility to do this. Limiting it based on the source IP is not an option in our case. Is there a module I can use? Or is this generally a bad idea? Best Regards, Sebastian <http://www.sipgate.co.uk>

9 years, 11 months

How can I implement Asterisk as Media server?

by Patrik Kristel

Hello, I have Kamailio with websocket module and I want to connect Asterisk as media server. I'm trying to route calls from web JsSIP users to non-web users I would like to ask how can I implement it? Can i use the rtpproxy-ng Module and here setup IP of Asterisk? Or is there any other way to do it? Thank you for your help! Regards, Patrik Kristel

9 years, 11 months

BLF issue with Kamailio behind NAT

by Errol Samuels

Hello All, I have an integration with Kamailio and FusionPBX (Freeswitch) working great but I been trying to troubleshoot a BLF issue with Kamailio where the BLF seems to only work when Kamailio is on a Public IP rather than behind NAT. The BLF works fine when we register directly with Freeswitch either on a Public IP or behind NAT. Both Kamailio and FusionPBX (Freeswitch) are behind pfSense firewall on private IPs and registrations, Inbound and Outbound Calls etc are working fine. Just this BLF issue giving me some grief. The phone in question is a Yealink T20. I made some SIP Traces and I noticed the following: In the FS Message Header I see we have the SUBSCRIBE: ***** Begin Freeswitch trace**** Frame 13: 619 bytes on wire (4952 bits), 619 bytes captured (4952 bits) Internet Protocol Version 4, Src: 192.168.1.138 (192.168.1.138), Dst: 207.xx.xx.109 (207.xx.xx.109) User Datagram Protocol, Src Port: x11 (6062), Dst Port: ca-2 (5065) Session Initiation Protocol (REGISTER) Request-Line: REGISTER sip:testfs.mydomain.com:5065 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.138:6062;branch=z9hG4bK748715490 From: "302" <sip:302@testfs.mydomain.com:5065>;tag=530545144 To: "302" <sip:302@testfs.mydomain.com:5065> Call-ID: 2118669441(a)192.168.1.138 CSeq: 8 REGISTER Contact: <sip:302@192.168.1.138:6062> Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE Max-Forwards: 70 User-Agent: Yealink SIP-T20P 9.72.0.30 Expires: 300 Allow-Events: talk,hold,conference,refer,check-sync Content-Length: 0 Frame 14: 698 bytes on wire (5584 bits), 698 bytes captured (5584 bits) Internet Protocol Version 4, Src: 207.xx.xx.109 (207.xx.xx.109), Dst: 192.168.1.138 (192.168.1.138) User Datagram Protocol, Src Port: ca-2 (5065), Dst Port: x11 (6062) Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 192.168.1.138:6062 ;branch=z9hG4bK748715490;received=2.xx.xx.187;rport=6062 From: "302" <sip:302@testfs.mydomain.com:5065>;tag=530545144 To: "302" <sip:302@testfs.mydomain.com:5065>;tag=j71FeN5gcBjDe Call-ID: 2118669441(a)192.168.1.138 CSeq: 8 REGISTER Contact: <sip:302@192.168.1.138:6062 ;received=2.xx.xx.187:6062>;expires=300 Date: Thu, 24 Apr 2014 17:03:18 GMT User-Agent: FreeSWITCH-mod_sofia/1.2.23+git~20140419T040926Z~8a20da75ef~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Content-Length: 0 Frame 15: 509 bytes on wire (4072 bits), 509 bytes captured (4072 bits) Internet Protocol Version 4, Src: 192.168.1.138 (192.168.1.138), Dst: 10.22.110.9 (10.22.110.9) User Datagram Protocol, Src Port: x11 (6062), Dst Port: ca-2 (5065) Session Initiation Protocol (SUBSCRIBE) Request-Line: SUBSCRIBE sip:301@10.22.110.9:5065 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.138:6062;branch=z9hG4bK148600064 From: "302" <sip:302@testfs.mydomain.com:5065>;tag=2146254460 To: <sip:301@testfs.mydomain.com:5065>;tag=70uoBUVRvJyr Call-ID: 168472766(a)192.168.1.138 CSeq: 2 SUBSCRIBE Contact: <sip:302@192.168.1.138:6062> Accept: application/dialog-info+xml Max-Forwards: 70 User-Agent: Yealink SIP-T20P 9.72.0.30 Expires: 1800 Event: dialog Content-Length: 0 ****** End Freeswitch trace ******** In the Kamailio Header there is no SUBSCRIBE for the BLF. ***** Begin Kamailio trace**** Frame 17: 809 bytes on wire (6472 bits), 809 bytes captured (6472 bits) Internet Protocol Version 4, Src: 192.168.1.138 (192.168.1.138), Dst: 207.xx.xx.108 (207.xx.xx.108) User Datagram Protocol, Src Port: x11 (6062), Dst Port: sip (5060) Session Initiation Protocol (REGISTER) Request-Line: REGISTER sip:test.mydomain.com:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.138:6062;branch=z9hG4bK1572502835 From: "302" <sip:302@test.mydomain.com>;tag=1877226231 To: "302" <sip:302@test.mydomain.com> Call-ID: 887242692(a)192.168.1.138 CSeq: 3 REGISTER Contact: <sip:302@192.168.1.138:6062> Authorization: Digest username="302", realm="test.mydomain.com", nonce="U1lHHFNZRfB7/5Lyb/Rz3p/xu26B1lpE", uri="sip:test.mydomain.com:5060", response="7687c7d3141d1898e63a1cc9538f05d7", algorithm=MD5 Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE Max-Forwards: 70 User-Agent: Yealink SIP-T20P 9.72.0.30 Expires: 300 Allow-Events: talk,hold,conference,refer,check-sync Content-Length: 0 Frame 18: 496 bytes on wire (3968 bits), 496 bytes captured (3968 bits) Internet Protocol Version 4, Src: 207.xx.xx.108 (207.xx.xx.108), Dst: 192.168.1.138 (192.168.1.138) User Datagram Protocol, Src Port: sip (5060), Dst Port: x11 (6062) Session Initiation Protocol (200) Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 192.168.1.138:6062 ;branch=z9hG4bK1572502835;rport=6062;received=2.xx.xx.187 From: "302" <sip:302@test.mydomain.com>;tag=1877226231 To: "302" <sip:302@test.mydomain.com >;tag=ff6b32c6b28b8954915484dd79f46b1c.fcdc Call-ID: 887242692(a)192.168.1.138 CSeq: 3 REGISTER Contact: <sip:302@192.168.1.138:6062 >;expires=300;received="sip:2.xx.xx.187:6062" Server: kamailio (4.0.6 (x86_64/linux)) Content-Length: 0 Frame 19: 316 bytes on wire (2528 bits), 316 bytes captured (2528 bits) Internet Protocol Version 4, Src: 207.xx.xx.108 (207.xx.xx.108), Dst: 192.168.1.138 (192.168.1.138) User Datagram Protocol, Src Port: sip (5060), Dst Port: x11 (6062) Session Initiation Protocol (OPTIONS) Request-Line: OPTIONS sip:2.xx.xx.187:6062 SIP/2.0 Message Header Via: SIP/2.0/UDP 10.22.110.11:5060;branch=0 From: sip:pinger@kamailio.org ;tag=uloc-53579917-4e9-89-0b632cbb-a8aa99c To: sip:2.xx.xx.187:6062 Call-ID: f9749d7-2d0b0be7-c678c54(a)10.22.110.11 CSeq: 1 OPTIONS Content-Length: 0 ***** End Kamailio trace**** Anyone faced this issue or have any ideas? regards, Errol

9 years, 11 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 April 2014