I have SIP proxy (Kamailio) works in conjunction with rtpproxyhttp://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 ?
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 <---> BNow 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 <---> BBut 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 A3Why 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
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 <miconda@gmail.com
wrote:
Hello,
On 8/13/13 5:56 AM, Khoa Pham wrote:
I have SIP proxy (Kamailio) works in conjunction with rtpproxyhttp://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
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 onmyway133@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 < miconda@gmail.com> wrote:
Hello,
On 8/13/13 5:56 AM, Khoa Pham wrote:
I have SIP proxy (Kamailio) works in conjunction with rtpproxyhttp://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
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 <onmyway133@gmail.com mailto:onmyway133@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 <miconda@gmail.com <mailto:miconda@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.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto: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 <http://www.fantageek.com>-- Khoa Pham HCMC University of Science www.fantageek.com http://www.fantageek.com
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 <miconda@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 onmyway133@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 < miconda@gmail.com> wrote:
Hello,
On 8/13/13 5:56 AM, Khoa Pham wrote:
I have SIP proxy (Kamailio) works in conjunction with rtpproxyhttp://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
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 govoiper@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 < miconda@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 onmyway133@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 < miconda@gmail.com> wrote:
Hello,
On 8/13/13 5:56 AM, Khoa Pham wrote:
I have SIP proxy (Kamailio) works in conjunction with rtpproxyhttp://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
I wish RTPproxy developers reply to this for further insightful details.
Read more about the draw backs of this on the same email as found out by Andres and the next reply is somewhat acceptable but in case of early media that is handled by RTPproxy when final 200 OK comes and RTPproxy handles it from within the Kamailio( as I imagine from using the rtpproxy_answer() function OR manage_rtpproxy() handles it automatically)
Now, early media is not our subject here. And Regardless of RTPproxy Auto-filling anything on its own you should really really consider the triggering of Re-INVITES, have those invites handled in kamailio.cfg and then use rtpproxy_manage() function and if everything goes well you can switch a dozen of networks within a call and it'll work every time.
Can you just use one-network-handover and then you'll face failures when a call had an early-media before answering so your "one-handover" "feature" was already used. So the right way is as Daniel said.
BR, Sammy
On Thu, Aug 15, 2013 at 12:13 AM, Khoa Pham onmyway133@gmail.com wrote:
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 govoiper@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 < miconda@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 onmyway133@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 < miconda@gmail.com> wrote:
Hello,
On 8/13/13 5:56 AM, Khoa Pham wrote:
I have SIP proxy (Kamailio) works in conjunction with rtpproxyhttp://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
-
Daniel-Constantin Mierla -
Khoa Pham -
SamyGo