Subject: RE: 3GPP analysis

From: <[email-masked]>
Date: Thu, 20 Feb 2003 15:58:26 +0200

Hello, Suresh!

Firstly, sorry for the long delay in my reply... :-(

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 14 February, 2003 16:11

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.

 JW: Yep, that's true. 3GPP architecture is taken as given in this exercise.

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.

 JW: Right, I see... But anyway, the first priority of IMS scenario 1 is to analyze "IPv4-only SIP client (registered to IPv4-only SIP server) <-> IPv6-only IMS UE" case

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.

JW: I think we cannot force the translation to be made on the edge of the IMS, and we can just give short solution guidelines in our document. In your proposal, do you mean allocating a public IPv4 address to every UE connected to IMS? If that is so, it's good to remember that there's a big number of UEs in a 3GPP network. Moreover, I guess that when the destination SIP server is dual stack and IPv4-only nodes are allowed to register to it, then it might be reasonable to assume that the destination domain will be able to perform IPv4-IPv6 translation...  Anyway, I try to address these points a bit more in the next revision (-02) I'm planning to make by the end of next week.

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.

 JW: I have heard some discussion (I think it was in 3GPP/IETF meeting in San Francisco) on SIP v4/v6 studies to be started in sipping (?) wg. Let's see whether we get more information on that in the next IETF meeting.

Best Regards,
		-Juha W.-

---

From: [email-masked]
Date: Thu, 20 Feb 2003 16:02:13 +0100

Juha,

Thanks for the reply.
In the solution I described the IPv4 addresses wouldn't be allocated permanently. At session setup time they are added to the SDP, if in the answer it turns out the peer node supports IPv6 this IPv4 address can be released and allocated to another session. Very similar to NAT. Furthermore the I-CSCF could a first filtering based on the SIP-URL to decide if this interworking is needed, this could be done by storing a list of known IMS domain parts in the  S-CSCF. Once more and more non-IMS user start supporting IPv6 this feature could be disabled.
Anyhow I guess the exact mechanism for SIP interworking would be handled in the SIPPING or SIP group.

Greetings,
    Suresh