RE: 3GPP analysis

[<juha.wiljakka@nokia.com>]

Hi, Suresh!

Thanks for your questions and comments on our document!

Firstly, I think that the best way would be to enable IPv6 on end nodes (I see in your questions that you have considered dual stack SIP server in the destination network) and just use IPv6 for SIP/IMS communications. This is the final goal in all IMS communications! But until that has happened we will have to live with this kind of solution in those cases where communications with (legacy) IPv4 nodes are needed.

(Another thing is that we have to develop the solution according to 3GPP (Rel5) IMS specifications, i.e. remembering that IMS is IPv6-only. We are not supposed to propose / make any changes in 3GPP specifications.)

I try to further analyze your questions below:

-----Original Message-----
From: ext suresh.leroy@alcatel.be [mailto:suresh.leroy@alcatel.be]
Sent: 12 February, 2003 17:22

1) If the destination is an IPv4 node registered to a dual stack SIP
server, is the interworking  then by default handled outside the IMS
operator's network or are there ways to keep the control whithin the IMS
operator's network.

=> When an IPv6 UE connected to IMS tries to reach the external IPv4 node it sends the INVITE request to the SIP proxy at the IMS. Then the SIP proxy at the IMS contacts the DNS to find out the IP address of the SIP proxy where the IPv4-only destination node is registered (so in this case it probably gets both IPv4 and IPv6 addresses as it is dual stack), and after this DNS resolution the originating SIP proxy at the IMS forwards (proxies) the INVITE request to the destination SIP proxy. This procedure does not involve the IP address of the destination SIP client, so the decision to use IPv4 or IPv6 routing for the outgoing INVITE request is based on the addresses returned for the destination SIP proxy and following the address selection policy configured in the IMS, independently of the type of client (IPv4-only in this case) that is registered to the destination SIP proxy.

So there are two different possibilities: If the IMS decides to use IPv4 instead of IPv6 (from the edge of the IMS to the destination) to reach the destination SIP proxy, then no further IPv4-IPv6 interworking is needed outside the IMS domain, as IPv6 to IPv4 translation will be performed on the edge of the IMS. If the IMS decides to use IPv6, then protocol translation needs to be performed in the destination network. This decision can be based on the type of SIP proxy (dual stack in this case).

I think quite natural place for the translation is on the edge of the IPv6-only IMS. SIP/SDP ALG is needed for SIP/SDP translation and user traffic translation is handled in a translator (e.g. NAT-PT; can also be a subset of NAT-PT, NAT64, etc.).

2) How is the SIP-ALG added in the path for outgoing SIP calls (assuming
the SIP-ALG is only in the path when needed). Is it a configuration in
the S-CSCF, e.g. if DNS resolve only returns a IPv4 address then forward
SIP messages to SIP-ALG, SIP-ALG then resends again the same DNS query
to find the next 'IPv4' hop.

=> At least these two options exist:
- The SIP-ALG is implemented together with the NAT-PT in the same box. This allows the SIP-ALG easily control the NAT-PT bindings. However, this may lower the translator performance as more tasks are needed within the one single box.
- The SIP-ALG and NAT-PT are in separate boxes and some kind of protocol (e.g. MEGACO) is used to remotely control NAT-PT bindings.

3) For incomming SIP sessions how is decided if the call should go to
the I-CSCF or the SIP-ALG. Is this done based on DNS information in the
IMS operator network, IPv6 address corresponding to I-CSCF, IPv4 address
to SIP-ALG.
This would result in external IPv6 SIP server sending their messages to
the I-CSCF and IPv4 servers forwarding SIP to the SIP-ALG.
How about external SIP server that are dual stack, where does it forward
SIP messages to.

=> Yep, DNS information could be used. And clear rules should exist what to do in the case of ds SIP server... Just thinking, can we know what IP version the peer node is using?

Wouldn't it be easier if the ALG functionality for IMS would be
integrated in the I-CSCF or S-CSCF although there was heavy resistance
for this in 3GPP.

=> I was not personally active in 3GPP when those discussions were held. However, I would respect 3GPP opinions and as I commented previously, we are not anyhow making changes in 3GPP specifications.

Best Regards,
	         -Juha W.-