Subject: [dispatch] draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a dual stack UA?

From: "Adi Shachar(Even-Tzur)" <[email-masked]>
Date: Thu, 10 Dec 2009 08:17:17 +0200

Hi All,

As I understand this draft will become an RFC.

I would like to better understand the recommendation of the draft for
the mixed ipv4/ipv6 UA behavior.

My main concern is regarding the Offer out such a UA should create. 

The idea mentioned in the draft  is to enable communication both in ipv4
or ipv6, but the question is how exactly it should be done.

There are few options for  the OFFER out (assuming we have audio &
video):

1.       Include total of 2 'm' lines: one 'm' line for audio and one
'm' line for video (with 2 'c' lines each, one in ipv4 and one in ipv6).

2.       Include  total of 4 'm' lines: one 'm' line for audio with 'c'
line with ipv4,  one 'm' line for audio with 'c ' line with ipv6, one
'm' line for video with 'c' line with ipv4 and one 'm' line for video
with 'c ' line with ipv6 (RFC 4091).

3.       The draft refer that the problem should be solved using STUN
relay. As far as I know, the STUN server returns MY public address and
not the destination address, so how does the UA know from STUN response
what does the destination address support, ipv4 or ipv6? Should the
Offering UA, based on STUN relay, know whether to include only ipv4 or
ipv6 in the 'm' lines?

4.       Any other option?

thanks,

Adi.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Dec 2009 09:27:18 +0100

I would suggest you post this question to the MMUSIC list, but the quick answer is ICE/ICE-lite (previously ANAT, RFC 4091, which is being obsoleted by ICE).

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adi Shachar(Even-Tzur)
Sent: 10 December 2009 06:17
To: [email-masked]
Subject: [dispatch] draft-ietf-sipping-v6-transition-07 - what should be the Offer out of a dual stack UA?

Hi All,

I would like to better understand the recommendation of the draft for the mixed ipv4/ipv6 UA behavior.
My main concern is regarding the Offer out such a UA should create.
The idea mentioned in the draft  is to enable communication both in ipv4 or ipv6, but the question is how exactly it should be done.

There are few options for  the OFFER out (assuming we have audio & video):

1.       Include total of 2 'm' lines: one 'm' line for audio and one 'm' line for video (with 2 'c' lines each, one in ipv4 and one in ipv6).

2.       Include  total of 4 'm' lines: one 'm' line for audio with 'c' line with ipv4,  one 'm' line for audio with 'c ' line with ipv6, one 'm' line for video with 'c' line with ipv4 and one 'm' line for video with 'c ' line with ipv6 (RFC 4091).

3.       The draft refer that the problem should be solved using STUN relay. As far as I know, the STUN server returns MY public address and not the destination address, so how does the UA know from STUN response what does the destination address support, ipv4 or ipv6? Should the Offering UA, based on STUN relay, know whether to include only ipv4 or ipv6 in the 'm' lines?

4.       Any other option?

thanks,
Adi.