Help. Please remove me from this mail list. Thanks<br><br>在2010-02-27 19:00:01，[email protected] 写道： >Send Users mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Users digest..." > > >Today's Topics: > > 1. remove parameter (Elgar Onel) > 2. Exotic case (but real) in which RtpProxy doesn't work > (I?aki Baz Castillo) > 3. Re: Exotic case (but real) in which RtpProxy doesn't work > (Daniel-Constantin Mierla) > 4. Re: Exotic case (but real) in which RtpProxy doesn't work > (I?aki Baz Castillo) > 5. Re: Exotic case (but real) in which RtpProxy doesn't work > (Daniel-Constantin Mierla) > 6. Re: Exotic case (but real) in which RtpProxy doesn't work > (I?aki Baz Castillo) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 26 Feb 2010 03:00:25 -0800 (PST) >From: Elgar Onel <[email protected]> >Subject: [Kamailio-Users] remove parameter >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset="us-ascii" > >Dear friends, > >how to remove parameters from INVITE sip address? > >tia, e. > > > > >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ><http://lists.kamailio.org/pipermail/users/attachments/20100226/bb3d7c60/attachment.html> > >------------------------------ > >Message: 2 >Date: Fri, 26 Feb 2010 14:08:36 +0100 >From: I?aki Baz Castillo <[email protected]> >Subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy > doesn't work >To: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset="utf-8" > >Hi, I've a problem with an Alcatel PBX in the way it performs transference: > >- Alcatel (behind NAT) sends INVITE to 111 and Kamailio forces RtpProxy. Let's >assume the selected UDP port for RtpProxy is 1000. > >- Alcatel sends INVITE to 222 and Kamailio forces RtpProxy. Let's assume the >selected UDP port for RtpProxy is 2000. > >Then Alcatel performs the transference as follows: > >- It sends a re-INVITE for 111 to Kamailio by setting the SDP to the IP or >RtpProxy and port 2000. > >- It also sends a re-INVITE for 222 to Kamailio by setting the SDP to the IP >or RtpProxy and port 1000. > >This is, Alcatel wants that the provider (me) sends the RTP to itself, while >mantaining the original SIP dialogs established (so it's ok at signalling >level, but at RTP level it cannot work as RtpProxy shoud send RTP to itself). > >I'm thinking on how to solve it but find no solution. Any suggestion? >Thanks. > >-- >I?aki Baz Castillo <[email protected]> > > > >------------------------------ > >Message: 3 >Date: Fri, 26 Feb 2010 15:04:36 +0100 >From: Daniel-Constantin Mierla <[email protected]> >Subject: Re: [Kamailio-Users] Exotic case (but real) in which RtpProxy > doesn't work >To: I?aki Baz Castillo <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=UTF-8; format=flowed > >Hello, > >On 02/26/2010 02:08 PM, I?aki Baz Castillo wrote: >> Hi, I've a problem with an Alcatel PBX in the way it performs transference: >> >> - Alcatel (behind NAT) sends INVITE to 111 and Kamailio forces RtpProxy. >> Let's >> assume the selected UDP port for RtpProxy is 1000. >> >> - Alcatel sends INVITE to 222 and Kamailio forces RtpProxy. Let's assume the >> selected UDP port for RtpProxy is 2000. >> >> Then Alcatel performs the transference as follows: >> >> - It sends a re-INVITE for 111 to Kamailio by setting the SDP to the IP or >> RtpProxy and port 2000. >> >> - It also sends a re-INVITE for 222 to Kamailio by setting the SDP to the IP >> or RtpProxy and port 1000. >> >> This is, Alcatel wants that the provider (me) sends the RTP to itself, while >> mantaining the original SIP dialogs established (so it's ok at signalling >> level, but at RTP level it cannot work as RtpProxy shoud send RTP to itself). >> >> I'm thinking on how to solve it but find no solution. Any suggestion? > >Do you re-engage rtpproxy for re-INVITEs? Also, have you played with >force rtp proxy flags to trust public addresses? > >Cheers, >Daniel > >-- >Daniel-Constantin Mierla >Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010 >* http://www.asipto.com/index.php/sip-router-masterclass/ > > > > >------------------------------ > >Message: 4 >Date: Fri, 26 Feb 2010 15:09:08 +0100 >From: I?aki Baz Castillo <[email protected]> >Subject: Re: [Kamailio-Users] Exotic case (but real) in which RtpProxy > doesn't work >To: [email protected] >Message-ID: <[email protected]> >Content-Type: Text/Plain; charset="utf-8" > >El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribi?: > >> Do you re-engage rtpproxy for re-INVITEs? > >Yes, the client is behind NAT so I must use RtpProxy for initial INVITE. >Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive RTP >in already working ports but from a different source, so RtpProxy would >reject/ignore such RTP traffic. > > >> Also, have you played with >> force rtp proxy flags to trust public addresses? > >But that wouldn't solve the problem, am I wrong? > >Thanks. > >-- >I?aki Baz Castillo <[email protected]> > > > >------------------------------ > >Message: 5 >Date: Fri, 26 Feb 2010 18:39:41 +0100 >From: Daniel-Constantin Mierla <[email protected]> >Subject: Re: [Kamailio-Users] Exotic case (but real) in which RtpProxy > doesn't work >To: I?aki Baz Castillo <[email protected]> >Cc: [email protected] >Message-ID: <[email protected]> >Content-Type: text/plain; charset=UTF-8; format=flowed > > > >On 02/26/2010 03:09 PM, I?aki Baz Castillo wrote: >> El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribi?: >> >> >>> Do you re-engage rtpproxy for re-INVITEs? >>> >> Yes, the client is behind NAT so I must use RtpProxy for initial INVITE. >> Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive RTP >> in already working ports but from a different source, so RtpProxy would >> reject/ignore such RTP traffic. >> >> >> >>> Also, have you played with >>> force rtp proxy flags to trust public addresses? >>> >> But that wouldn't solve the problem, am I wrong? >> >there is a deadlock when chaining two rtpproxy. In learning mode >rtpproxy waits for the other side to send first packet to know the ip >and port. iirc it is r flag to avoid this. > >Cheers, >Daniel > >-- >Daniel-Constantin Mierla >Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010 >* http://www.asipto.com/index.php/sip-router-masterclass/ > > > > >------------------------------ > >Message: 6 >Date: Fri, 26 Feb 2010 19:07:48 +0100 >From: I?aki Baz Castillo <[email protected]> >Subject: Re: [Kamailio-Users] Exotic case (but real) in which RtpProxy > doesn't work >To: [email protected] >Message-ID: <[email protected]> >Content-Type: Text/Plain; charset="utf-8" > >El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribi?: >> On 02/26/2010 03:09 PM, I?aki Baz Castillo wrote: >> > El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribi?: >> >> Do you re-engage rtpproxy for re-INVITEs? >> > >> > Yes, the client is behind NAT so I must use RtpProxy for initial INVITE. >> > Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive >> > RTP in already working ports but from a different source, so RtpProxy >> > would reject/ignore such RTP traffic. >> > >> >> Also, have you played with >> >> force rtp proxy flags to trust public addresses? >> > >> > But that wouldn't solve the problem, am I wrong? >> >> there is a deadlock when chaining two rtpproxy. In learning mode >> rtpproxy waits for the other side to send first packet to know the ip >> and port. iirc it is r flag to avoid this. > >Interesting, I'll try it and will comment the result. > >Thanks. > > >-- >I?aki Baz Castillo <[email protected]> > > > >------------------------------ > >_______________________________________________ >Users mailing list >[email protected] >http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > >End of Users Digest, Vol 57, Issue 85 >*************************************
_______________________________________________ Kamailio (OpenSER) - Users mailing list [email protected] http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
