Hi Daniel, Sammy, thanks for reply But as Andres pointed out http://lists.sip-router.org/pipermail/sr-users/2008-March/062795.html After the pre-filling state, rtpproxy can re-fill media address. I think it means that rtpproxy does not care about IP in U and L (Update, Lookup) commands, it only cares about IP in the first RTP packet.
So in my case A2, it can re-fill 2 times.Look at the main.c in rtpproxy source code, in the rxmit_packets() functions, it does the address filling /* * Update recorded address if it's necessary. Set "untrusted address" * flag in the session state, so that possible future address updates * from that client won't get address changed immediately to some * bogus one. */ On Thu, Aug 15, 2013 at 1:22 PM, SamyGo <govoi...@gmail.com> wrote: > Dear Khoa, > > As Daniel stated you need to see if your SIP phones are able to sense the > change in its network parameters and trigger a Re-INVITE to Kamailio with > new SDP to handle the audio. > > That's very important to do because once RTPproxy allocates the ports it > can't just start sending RTPs to the new A2 network IP on its own OR start > receiving RTPs from new IP to its already allocated port (that'll mean > anyone can send RTPs to an allocated port and insert media into someone > else's call). > > Please do share the network topology where the first network transition > worked, possibly it's Public IP remained the same and maybe your internal > network handled that somehow(NAT/PAT) !?? > > Now once the Re-INVITES are exchanged only then RTPproxy will be explored > to see if it handles the transparent Handover/updates or not. > > BR, > Sammy > > > > > > > On Wed, Aug 14, 2013 at 7:03 AM, Daniel-Constantin Mierla < > mico...@gmail.com> wrote: > >> Kamailio does not send any command to RTPProxy unless it handles some >> SIP messages, the U and L commands are typically for INVITEs and 200ok. >> >> Have you looked at sip traffic? You can run ngrep on kamailio server: >> >> ngrep -d any -qt -W byline port 5060 >> >> Cheers, >> Daniel >> >> >> On 8/14/13 1:40 PM, Khoa Pham wrote: >> >> I think it is related to so called IP address filling and trusted IP >> >> >> On Wed, Aug 14, 2013 at 4:09 PM, Khoa Pham <onmyway...@gmail.com> wrote: >> >>> Hi Daniel, >>> >>> My clients don't do anything when IP change occurs.From what I >>> inspect, it is because of rtpproxy does not accept the 2nd IP change. >>> The the rtpproxy protocol document >>> http://www.rtpproxy.org/wiki/RTPproxy/Protocol, the Update and Lookup >>> command have [arg] parameters. >>> U[args] callid addr port from_tag [to_tag [notify_socket [notify_args]]] >>> L[args] callid addr port from_tag to_tag >>> >>> I see Kamailio often send Uc and Lc to rtpproxy. I still can't find >>> out what these arg mean, but maybe it's the point >>> >>> >>> On Wed, Aug 14, 2013 at 3:31 PM, Daniel-Constantin Mierla < >>> mico...@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> >>>> On 8/13/13 5:56 AM, Khoa Pham wrote: >>>> >>>> I have SIP proxy (Kamailio) works in conjunction with >>>> rtpproxy<http://www.rtpproxy.org/> to >>>> support client communication. When SIP proxy sends command to rtpproxy to >>>> create new session, rtpproxy will create 2 ports (let's called them port1 >>>> and port2). rtpproxy has 1 listen interface >>>> >>>> Supposed A and B are 2 clients that use rtpproxy to relay RTP stream, >>>> and works fine. >>>> >>>> A <---> port1 [*rtpproxy*] port2 <---> B >>>> >>>> Now that A loses his current network, and enter network2 (imagine a >>>> network handover) to become A2. In this case, I see rtpproxy still works >>>> fine by relaying stream between A2 and B >>>> >>>> A2 <---> port1 [*rtpproxy*] port2 <---> B >>>> >>>> But when A2 lose his network2 and enters network3 to become A3, >>>> rtpproxy stills relay stream between A2 and B. It seems that A can change >>>> his network only once. >>>> >>>> A2 <---> port1 [*rtpproxy*] port2 <---> B >>>> >>>> A3 >>>> >>>> Why did the first handover succeed? How can I change rtpproxy behavior >>>> to support many handovers ? >>>> >>>> what I expect that happened between A and A2 is that the client >>>> application sent a re-INVITE with its new IP address. But then it didn't >>>> happen when going to A3. Rtpproxy itself can do nothing here. You should >>>> look at sip traffic to see what happens. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> -- >>>> Daniel-Constantin Mierla - >>>> http://www.asipto.comhttp://twitter.com/#!/miconda - >>>> http://www.linkedin.com/in/miconda >>>> >>>> >>>> _______________________________________________ >>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>> sr-users@lists.sip-router.org >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> >>> >>> >>> -- >>> Khoa Pham >>> HCMC University of Science >>> www.fantageek.com >>> >> >> >> >> -- >> Khoa Pham >> HCMC University of Science >> www.fantageek.com >> >> >> -- >> Daniel-Constantin Mierla - >> http://www.asipto.comhttp://twitter.com/#!/miconda - >> http://www.linkedin.com/in/miconda >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > -- Khoa Pham HCMC University of Science www.fantageek.com
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
