Hey Guys,
I was recently playing with gateway-ing IPv4-IPv6 and hit the following scenario: * AOR having contacts on both ipv4 and ipv6 and I wanted to do parallel forking.
RTPProxy bridging works without any issue on a normal setup, however the problem shows up when needing to make calls toward rtpproxy to return both sides of bridge or only one (ee and ie combinations). Did any of you experiment with this scenario?
EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6. The branch route looks the right place to call rtpproxy but when calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about which ports are we trying to cancel? One more issue would be with re-invite which must go out with the same ip of rtpproxy as original INVITE. Here we could store the bridge direction in some route parameter but unfortunately adding route params is not possible in branches.
So what do u think?
DanB
PS: The "normal" setup of forking calls only ipv4 or only ipv6 works smooth, so support of ipv6 in kamailio or rtpproxy is not questionable.
Hello,
On 4/13/11 2:10 PM, Dan-Cristian Bogos wrote:
Hey Guys,
I was recently playing with gateway-ing IPv4-IPv6 and hit the following scenario:
- AOR having contacts on both ipv4 and ipv6 and I wanted to do
parallel forking.
RTPProxy bridging works without any issue on a normal setup, however the problem shows up when needing to make calls toward rtpproxy to return both sides of bridge or only one (ee and ie combinations). Did any of you experiment with this scenario?
EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6. The branch route looks the right place to call rtpproxy but when calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about which ports are we trying to cancel? One more issue would be with re-invite which must go out with the same ip of rtpproxy as original INVITE. Here we could store the bridge direction in some route parameter but unfortunately adding route params is not possible in branches.
So what do u think?
interesting setup, indeed, but for sure to become very common in the near future, personally I haven't got to this scenario yet :-)
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
Cheers, Daniel
DanB
PS: The "normal" setup of forking calls only ipv4 or only ipv6 works smooth, so support of ipv6 in kamailio or rtpproxy is not questionable.
Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
That's a nice idea. Some time ago I tried the same setup and failed. Are there some easy methods to find out if a target is IPv4 or IPv6, e.g. something like
if ( is_ipv6("$rd") ) { ... }
regards Klaus
14 apr 2011 kl. 09.48 skrev Klaus Darilion:
Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
That's a nice idea. Some time ago I tried the same setup and failed. Are there some easy methods to find out if a target is IPv4 or IPv6, e.g. something like
if ( is_ipv6("$rd") ) { ... }
Now you have opened a can of worms. Let me start :-)
If I have a dual stack UA and registers with an IPv4 address - how do you know that I'm dual stack? I really don't need an RTP proxy.
The IETF thinks we should use SIP outbound and register twice. Kamailio doesn't support this as far as I remember and won't see that we have two locations for the very same UA.
Now, if you have a URI like "sip:board@kamailio.org" and that URI's domain has two priority levels of SRV records. The first level is only IPv4 and the second level includes IPv6 to indicate a preference to receive calls in IPv4 and an ability to receive them in IPv6 if that's preferred by the caller. Would Kamailio understand this?
There is work to be done here. /O
Am 14.04.2011 09:55, schrieb Olle E. Johansson:
14 apr 2011 kl. 09.48 skrev Klaus Darilion:
Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059
http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
That's a nice idea. Some time ago I tried the same setup and failed. Are there some easy methods to find out if a target is IPv4 or IPv6, e.g. something like
if ( is_ipv6("$rd") ) { ... }
Now you have opened a can of worms. Let me start :-)
If I have a dual stack UA and registers with an IPv4 address - how do you know that I'm dual stack? I really don't need an RTP proxy.
Maybe the rtpproxy is used anyway (NAT traversal, legal intercept ...)
The IETF thinks we should use SIP outbound and register twice. Kamailio doesn't support this as far as I remember and won't see that we have two locations for the very same UA.
Now, if you have a URI like "sip:board@kamailio.org" and that URI's domain has two priority levels of SRV records. The first level is only IPv4 and the second level includes IPv6 to indicate a preference to receive calls in IPv4 and an ability to receive them in IPv6 if that's preferred by the caller. Would Kamailio understand this?
No. Because in branch route you only see the domain, you will not know if the request will be forwarded via IPv4 or IPv6.
But to be pragmatic: for a service provider without "open SIP connectivity" it does not matter as the customers will use IP addresses and not domains for there clients.
regards Klaus
There is work to be done here. /O
_______________________________________________ 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
On 4/14/11 11:23 AM, Klaus Darilion wrote:
Am 14.04.2011 09:55, schrieb Olle E. Johansson:
14 apr 2011 kl. 09.48 skrev Klaus Darilion:
Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059
http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
That's a nice idea. Some time ago I tried the same setup and failed. Are there some easy methods to find out if a target is IPv4 or IPv6, e.g. something like
if ( is_ipv6("$rd") ) { ... }
Now you have opened a can of worms. Let me start :-)
If I have a dual stack UA and registers with an IPv4 address - how do you know that I'm dual stack? I really don't need an RTP proxy.
Maybe the rtpproxy is used anyway (NAT traversal, legal intercept ...)
The IETF thinks we should use SIP outbound and register twice. Kamailio doesn't support this as far as I remember and won't see that we have two locations for the very same UA.
Now, if you have a URI like "sip:board@kamailio.org" and that URI's domain has two priority levels of SRV records. The first level is only IPv4 and the second level includes IPv6 to indicate a preference to receive calls in IPv4 and an ability to receive them in IPv6 if that's preferred by the caller. Would Kamailio understand this?
No. Because in branch route you only see the domain, you will not know if the request will be forwarded via IPv4 or IPv6.
When dealing with domains, yes, since it is before the dns lookup. For the case of location records, you have the received ip/port/af stored so you can check it.
Now, since Kamailio is a lot about flexibility, of course there are workarounds, coming now to my mind: - you don't know if destination is IPv4 or IPv6, so you can create two branches for same domain, one will use rtpproxy for ipv4, the second for ipv6. Then based on the reply, you complete the rtp relaying session with the proper rtpproxy - second, assuming you try first ipv4 and the destination is ipv6 and cannot relay media to ipv4, I expect it will return quickly a specific reply code that can be handled in failure_route and create a new branch and use rtpproxy for ipv6 now.
Tricks with current version, for the future a dns resolver function can be used in the confing, considering we have internal caching for dns, that can be handy to avoid double queries to dns server for same record and same call.
Now, if the result is having both ipv4 and ipv6, then the higher priority will be used. Again, this is more like inter-domain peering, rather than calls through location service.
Cheers, Daniel
But to be pragmatic: for a service provider without "open SIP connectivity" it does not matter as the customers will use IP addresses and not domains for there clients.
regards Klaus
There is work to be done here. /O
_______________________________________________ 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
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
Hello,
On 4/14/11 9:55 AM, Olle E. Johansson wrote:
14 apr 2011 kl. 09.48 skrev Klaus Darilion:
Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
That's a nice idea. Some time ago I tried the same setup and failed. Are there some easy methods to find out if a target is IPv4 or IPv6, e.g. something like
if ( is_ipv6("$rd") ) { ... }
Now you have opened a can of worms. Let me start :-)
If I have a dual stack UA and registers with an IPv4 address - how do you know that I'm dual stack? I really don't need an RTP proxy.
The IETF thinks we should use SIP outbound and register twice. Kamailio doesn't support this as far as I remember and won't see that we have two locations for the very same UA.
well, in the worse case will be parallel forking, if it is with different q values, then can be turned into serial forking.
What IETF SIP outbound specs you are referring here? Since 3.0, coming via ser, the core has support for stun and keepalives according to some draft-xxx-sip-outbound, which might be a rfc by now.
Cheers, Daniel
Now, if you have a URI like "sip:board@kamailio.org" and that URI's domain has two priority levels of SRV records. The first level is only IPv4 and the second level includes IPv6 to indicate a preference to receive calls in IPv4 and an ability to receive them in IPv6 if that's preferred by the caller. Would Kamailio understand this?
There is work to be done here. /O
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
What IETF SIP outbound specs you are referring here? Since 3.0, coming via ser, the core has support for stun and keepalives according to some draft-xxx-sip-outbound, which might be a rfc by now.
On 4/14/11 9:48 AM, Klaus Darilion wrote:
Am 13.04.2011 15:55, schrieb Daniel-Constantin Mierla:
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
That's a nice idea. Some time ago I tried the same setup and failed. Are there some easy methods to find out if a target is IPv4 or IPv6, e.g. something like
if ( is_ipv6("$rd") ) { ... }
in onsend_route you can check the destination address family:
if(snd_af==INET6) { ... }
It might be too late for some specific processing, though.
Cheers, Daniel
Hey there Daniel,
Many thanks for so fast reply!
I will test the scenario recommended in our labs and come back to you asap. The only thing which is still not clear to me is how to "store" the used rtp set, so I can re-use it with INVITEs. The thing which I have experienced is that on INVITE it is easy to spot the right configuration since I know the address family of both originator(af param) and destination(based on location), however on re-invite it will help to have the setup loaded from somewhere. My idea was route parameters, but impossible to set them in branches right now. Another option will be to decide based on origination/termination address family, but the termination one is right now available only in onsend routes where the rtpproxy functions are not in.
Ta, DanB
On Wed, Apr 13, 2011 at 3:55 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 4/13/11 2:10 PM, Dan-Cristian Bogos wrote:
Hey Guys,
I was recently playing with gateway-ing IPv4-IPv6 and hit the following scenario: * AOR having contacts on both ipv4 and ipv6 and I wanted to do parallel forking.
RTPProxy bridging works without any issue on a normal setup, however the problem shows up when needing to make calls toward rtpproxy to return both sides of bridge or only one (ee and ie combinations). Did any of you experiment with this scenario?
EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6. The branch route looks the right place to call rtpproxy but when calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about which ports are we trying to cancel? One more issue would be with re-invite which must go out with the same ip of rtpproxy as original INVITE. Here we could store the bridge direction in some route parameter but unfortunately adding route params is not possible in branches.
So what do u think?
interesting setup, indeed, but for sure to become very common in the near future, personally I haven't got to this scenario yet :-)
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
Cheers, Daniel
DanB
PS: The "normal" setup of forking calls only ipv4 or only ipv6 works smooth, so support of ipv6 in kamailio or rtpproxy is not questionable.
-- Daniel-Constantin Mierla http://www.asipto.com
Hello,
On 4/18/11 3:21 PM, Dan-Cristian Bogos wrote:
Hey there Daniel,
Many thanks for so fast reply!
I will test the scenario recommended in our labs and come back to you asap. The only thing which is still not clear to me is how to "store" the used rtp set, so I can re-use it with INVITEs. The thing which I have experienced is that on INVITE it is easy to spot the right configuration since I know the address family of both originator(af param) and destination(based on location), however on re-invite it will help to have the setup loaded from somewhere. My idea was route parameters, but impossible to set them in branches right now. Another option will be to decide based on origination/termination address family, but the termination one is right now available only in onsend routes where the rtpproxy functions are not in.
if it is a ipv4-to-ipv6 bridging, there should be two record-route headers added by kamailio, thus two Route headers in re-INVITE. You can use $(hdr(Route)[0/1]) to check if one of them is IPv6. Alternative is to use htable to store per call-id the type of the call.
Cheers, Daniel
Ta, DanB
On Wed, Apr 13, 2011 at 3:55 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 4/13/11 2:10 PM, Dan-Cristian Bogos wrote:
Hey Guys,
I was recently playing with gateway-ing IPv4-IPv6 and hit the following scenario:
- AOR having contacts on both ipv4 and ipv6 and I wanted to do
parallel forking.
RTPProxy bridging works without any issue on a normal setup, however the problem shows up when needing to make calls toward rtpproxy to return both sides of bridge or only one (ee and ie combinations). Did any of you experiment with this scenario?
EG: Call comes from ipv4, you want to send it to both ipv4 and ipv6. The branch route looks the right place to call rtpproxy but when calling unforce_rtp_proxy() on CANCEL, will rtpproxy be aware about which ports are we trying to cancel? One more issue would be with re-invite which must go out with the same ip of rtpproxy as original INVITE. Here we could store the bridge direction in some route parameter but unfortunately adding route params is not possible in branches.
So what do u think?
interesting setup, indeed, but for sure to become very common in the near future, personally I haven't got to this scenario yet :-)
If does not work with one instance, I would use branch flags to mark the branch doing ipv4 to ipv6 translation and engage a dedicated rtpproxy for it. You can run two rtpproxy-es on the same server, in different sets: http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3012059 http://kamailio.org/docs/modules/stable/modules_k/rtpproxy.html#id3009496
So the branch doing ipv4-ipv6 will have a flag set and use a particular rtpproxy. On the 200ok, you can check the branch flag and engage again the proper rtpproxy.
Cheers, Daniel
DanB
PS: The "normal" setup of forking calls only ipv4 or only ipv6 works smooth, so support of ipv6 in kamailio or rtpproxy is not questionable.
-- Daniel-Constantin Mierla http://www.asipto.com
-
Dan-Cristian Bogos -
Daniel-Constantin Mierla -
Klaus Darilion -
Olle E. Johansson