sr-users September 2014

sr-users@lists.kamailio.org

96 participants
170 discussions

Re: [SR-Users] Crash Kamailio 4.1.4
by Igor Potjevlesch 10 Oct '14

10 Oct '14

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

2 24

Unconditional Call forwarding
by Rajesh Sharma 10 Oct '14

10 Oct '14

Hi . I have installed Kamailio 4.1.6 and basic registration and proxy server functionalities are working fine. Now I want to simulate a Unconditional call forwarding scenario with 181-Call is being forwarded is reported to originator from server. Thanks

3 3

Kamailio With RTP proxy BYE not receiving
by balu 10 Oct '14

10 Oct '14

Hi I am using kamailio with rtp proxy module. I have 2 questions /issues . 1. When caller or callee ends the call the other end call is not disocnnecting . UA is pjsip based and behind NAT router. Present call flow is pjsipUA (LAN_ip)----->Router (Publicip)-------->Kamailio_with_RTP proxy----> ThridParty SIP Server UA local ip : 192.168.2.11 UA public IP : 89.78.92.23 Kamailio Public ip: 94.50.203.32 Third party Sip server : 76.42.89.25 Here When I disconnect call from either side , it is not disconnecting other side . 2. My second requirement is , how can I define port of third party server . for example if have 3 or 4 sip servers with different sip registration ports other tahn 5060 How can I route registration requests coming from UAs to different ports of third party servers. Please bear my ignorance I am new to kamailio .Hope some experts will help me here . Attached kamailio config and SIP trace taken from kamailio server Thank you

2 1

cr_next_domain not found
by mark＠brightvoip.co.uk 10 Oct '14

10 Oct '14

Hi, I am trying to use the carrierfailureroute table functionality via the cr_next_domain carrierroute function. I am getting the message: "failed to find command cr_next_domain" when I try to start Kamailio I am compiling Kamailio from latest 4.1.6 source, using: make include_modules"db_mysql carrierroute" cfg make group_include="db mysql standard" all make install I have installed libconfuse-devel and the tm module is loaded. Would welcome any helpful suggestions. Thanks, Mark Hall --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

2 1

dlg_set_timeout_by_profile not working on kamailio 4.1.5
by Jose Ferreira 10 Oct '14

10 Oct '14

I'm trying to use dlg_set_timeout_by_profile and it doesn't do nothing on Kamailio 4.1.5 If i try to use the dlg_set_timeout, it also doesn't work, but it gives the following error CRITICAL: dialog [dlg_timer.c:205]: update_dlg_timer(): Trying to update a bogus dlg tl=0x7f9825ac6880 tl->next=(nil) tl->prev=(nil) ERROR: dialog [dlg_hash.c:1094]: update_dlg_timeout(): failed to update dialog lifetime If i set the timeout with the $avp, it only works before dlg_manage(), but also with a Warning WARNING: dialog [dlg_handlers.c:1245]: dlg_onroute(): inconsitent dlg timer data on dlg 0x7f9da0dc7f08 [4066:9857] with clid 'bba73ace3ee94b95bf5b1782406047bd' and tags '6460df6b8b3947ba96b1cf65330bf524' 'm2pmrUpHN06Fc' The dialog module configurations are: modparam("dialog", "db_url", DBURL) modparam("dialog", "dlg_flag", FLT_DLG) modparam("dialog", "db_mode", 0) modparam("dialog", "enable_stats", 1) modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "profiles_with_value", "user ; domain ; permissions") modparam("dialog", "profiles_no_value", "inbound ; outbound ; all") modparam("dialog", "send_bye", 1) modparam("dialog", "default_timeout", 21600) modparam("dialog", "ka_timer", 0) modparam("dialog", "ka_interval", 0) modparam("dialog", "timeout_avp", "$avp(dlgtimeout)") I'm very interested to use dlg_set_timeout_by_profile, any idea about what is wrong with that ? Regards, *José Ferreira | Technical Manager* M. +351 91 775 7166 | jferreira(a)wavecom.pt Wavecom, Soluções Rádio, SA Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 234 919 190 | F. +351 234 919 191 *www.wavecom.pt <http://www.wavecom.pt/>* [image: WavecomSignature]

2 1

rtpengine with rejected re-invites to new RTP ports
by Jeff Pyle 08 Oct '14

08 Oct '14

Hello, Given the following scenario with Kamailio and rtpengine in the middle: - call establishes with G.711 RTP - b-leg re-invites to T.38, indicating a different port number then he is using for G.711 - a-leg refuses the re-invite with a 488 - call continues using G.711 on original port numbers as if re-invite never happened Will Kamailio and rtpengine handle it? Today I have a functional configuration with rtpproxy on another SIP proxy. It handles every scenario I have tried except this one. rtpproxy sees the new ports in the re-invite and adjusts its session accordingly. If the re-invite is rejected, the old media ports are no longer valid through rtpproxy, and the call fails. Is there an approach I can take with Kamailio and rtpengine to allow this scenario to succeed? Regards, Jeff

2 2

RFC: updating default values
by Daniel-Constantin Mierla 02 Oct '14

02 Oct '14

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

3 6

Relaying ACK to Asterisk
by Igor Potjevlesch 01 Oct '14

01 Oct '14

Hello, I'm having trouble with this scenario (Kamailio and Asterisk are working on the same server, Asterisk listens on 4060 instead of 5060): the UAC sends an ACK request with the following R-URI: sip:955*95%23@ <sip:955*95%23@%3cIP_ASTERISK/KAMAILIO%3e:4060> <IP_ASTERISK/KAMAILIO>:4060. When I'm doing a capture on loopback interface, I just see an ACK request from IP <IP_ASTERISK/KAMAILIO>:5060 to IP <IP_ASTERISK/KAMAILIO>:5060. So the ACK seems to loop inside Kamailio. What could explain that the good port defined by the UAC is deleted? Regards, Igor.

4 18

rtpengine alt stream question
by Alex Balashov 30 Sep '14

30 Sep '14

Hello, I recently encountered SDP attributes that look like this: Media Attribute (a): alt:1 3 : njfxofkg bavpjfxg 192.168.2.59 41978 Media Attribute (a): alt:2 2 : fpukfyaj dqmiarjx 192.168.111.1 41978 Media Attribute (a): alt:3 1 : euvrwenk jctmhavh 192.168.238.1 41978 I was not familiar with these. However, RFC 4796 says: alt: the media stream is taken from the alternative source. A typical use case for this is an event where the ambient sound is separated from the main sound. The alternative audio stream could be, for example, the sound of a jungle. Another example is the video of a conference room, while the main stream carries the video of the speaker. This is similar to the 'live' role in H.239. RFC 6064 http://tools.ietf.org/html/rfc6064#section-4.4 speaks to this a little as well. This does not really make any clearer to me what these mean in this scenario, and unfortunately I cannot find out from the user. My question is: I assume that rtpengine (both Kamailio and daemon-side) does not support this, correct? Are there any plans to in the future? Can anyone with more experience with video, perhaps, give some insight into the meaning and application of this attribute? Thanks! -- Alex -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906

1 0

R: Re: R: Re: RTPPROXY & BRANCH
by Marino Mileti 30 Sep '14

30 Sep '14

Unfortunately rtpengine doesn't work in this way. At the end of the calls this is the output log: Final packet stats: Tag 'Fw3D7R0', created 0:41 ago, in dialogue with 'TTPyT~Hdw' Media #1, port 30224 <> 192.168.10.20:7078 , 540 p, 92880 b, 0 e Media #1, port 30225 <> 192.168.10.20:7079 (RTCP), 3 p, 324 b, 0 e Media #2, port 30256 <> 192.168.10.20:9078 , 0 p, 0 b, 0 e Media #2, port 30257 <> 192.168.10.20:9079 (RTCP), 3 p, 264 b, 0 e Tag 'qWE6Gsh', created 0:41 ago, in dialogue with 'TTPyT~Hdw' Media #1, port 30140 <> 192.168.10.50:7078 , 533 p, 91068 b, 0 e Media #1, port 30141 <> 192.168.10.50:7079 (RTCP), 5 p, 444 b, 0 e Media #2, port 30170 <> 192.168.10.50:9078 , 0 p, 0 b, 0 e Media #2, port 30171 <> 192.168.10.50:9079 (RTCP), 1 p, 88 b, 0 e Tag 'TTPyT~Hdw', created 0:41 ago, in dialogue with 'Fw3D7R0' Media #1, port 30206 <> 172.20.11.208:7078 , 1070 p, 183736 b, 0 e Media #1, port 30207 <> 172.20.11.208:7079 (RTCP), 4 p, 496 b, 0 e Media #2, port 30240 <> 172.20.11.208:9078 , 4188 p, 1435946 b, 0 e Media #2, port 30241 <> 172.20.11.208:9079 (RTCP), 4 p, 400 b, 0 e 192.168.10.x clients are natted..it seems that rtpengine open 2 ports (for example video) for each receiver (30256 & 30170) and 1 port for the caller (30240). But on the INVITE of Kamailio only video port 30170 is offered to receivers, instead on caller side there are 2 distinct 183s message that offer 30190 & 30240. It's a little bit strange because some of these port doesn't appear in the log of rtpengine. At the end I can see video only on one receiver I don't know if the problem is on Kamailio (rtpproxy-ng module) or in the rtpengine :) > Without rtpproxy: > > - A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted > client so no needs of rtpproxy) > - B offers port b1,b2 (183) > - C offers port c1,c2 (182). > - A starts to send audio/video RTP to B on port b1,b2 > - A starts to send audio/video RTP to C on port c1,c2 > > With rtpproxy: > > - A offers port a1,a2 (audio video) in INVITE to Kamailio.... > - Kamailio contact rtpproxy because B&C are natted clients > - rtpproxy check callid and offer offers port k1,k2.... > - Kamailio sends INVITE to B offering k1,k2 > - Kamailio sends INVITE to C offering k1,k2 > - B offers port b1,b2 (183) > - C offers port c1,c2 (182) > - Kamailio sends 183 to A (for B leg) offering p1,p2 > - Kamailio sends 183 to A (for B leg) offering p3,p4 > - A starts to stream on p1,p2,p3,p4 but only one receiver can see the video > (B or C depends who will be the first:)) > > I don't know if it depends on that B & C receives same ports; i don't know > if rtpproxy is able to "duplicate" stream received from A to all "receiver" If A sends two streams, there is no need for duplication. A sending to p1 should be forwarded to B (b1) and A sending to p3 should be forwarded to C (c1). Both should be able to receive media sent by A. I believe that's what rtpengine does (but I haven't tested it). The reverse direction might be more confusing, but a final 200 OK with SDP should fix that. cheers _______________________________________________ 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

2 1

Jump to page:

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