Re: 3GPP analysis

[suresh.leroy@alcatel.be]

Juha,

Thank you for the reply, I did clarify some things for me.
First of all I fully agree with you that we have to work with what 3GPP specified, if changes are needed they should be done towards 3GPP directly.
I just wanted to know if from a technical point of view it would facilitate things in ALGs and SIP servers would be integrated.

For the answer to the first question. If I correctly understood your proposal the decision for adding a SIP ALG in the IMS network would be based on the peer address carried in the first reply. One problem with this is that the destination SIP server will see the peer IP address of the IMS UE in the initial Invite is an IPv6 address and will therefor provide local interworking as the destination peer is IPv4 only.  In this case the IMS SIP server will never know the peer is in fact a IPv4 node as the returned address is that of a local NAT-PT box.
Personally I was thinking more of a solution where the IMS SIP ALG server would add an IPv4 address (of the NAT-PT) to the SDP in the SIP invite. In this case the SIP server at the destination network doesn't have to add any interworking boxes at the user plane. So it is a split of SDP and SIP interworking.
A drawback of this solution is that the IPv4 address is added to every SIP message also the ones that don't require interworking.

Do you know if work has been done regarding IPv4-IPv6 interworking for SIP in one of the SIP working groups. The only thing I've found sofar is how to carry IPv6 addresses in SIP and SDP, nothing about the processing or interpretation of these fields by the different SIP agents.

Regards and thanks again,
    Suresh


juha.wiljakka@nokia.com wrote:

> 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.-