Subject: Re: [dispatch] Asking comments for draft-yang-dispatch-sip-connection-address-type

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Oct 2010 10:28:08 -0400

Lili,

I guess there is growing interest in involving a separate video device
in a call, because I have seen several different proposals for how to do it.

Regarding this draft - from a technical perspective, because it proposes
a change to SDP, it should probably be discussed in MMUSIC. But given
that it competes with other proposed mechanisms that are not entirely
SDP, perhaps dispatch is a good place for it.

I don't understand the premise of this draft - that the party sending
the offer doesn't know the address of the media stream - only the sip
URI, and that therefore the other party should use the sip address to
establish the media stream.

Some UA will presumably have to establish a separate sip dialog in order
to determine the media capabilities and address. The question is which
UA should it be. I see no advantage in delegating this responsibility
from the device that knows the SIP URI to the other unsuspecting party.
Doing so reduces the likelihood of a successful call by imposing
additional requirements on the other party.

I see no particular advantage to this approach over:
- Alice calls Anna's device sip:[email-masked]
- Alice discovers Anna's device video address and codecs
- Alice combines that video information with her own
  audio information into an offer to Bob.
(I'm glossing over the details here. But its well understood 3pcc.)

In that way, Bob's device need have no particular capabilities other
than the ability to support video and some video codec in common with
Anna's device.

	Thanks,
	Paul

On 10/26/2010 8:04 AM, Lili Yang_lili wrote:
> Hello Paul,
> 
> I am Lili Yang from Huawei.
> 
> Georg Mayer and I wrote an I-D 
> (http://tools.ietf.org/html/draft-yang-dispatch-sip-connection-address-type) 
> , which is related to a current 3GPP Rel-10 feature, namely 
> Inter-UE-Transfer for cases when a so-called collaborative session is 
> established during a SIP session establishment.
> 
> So far we did not receive any feed-back from IETF list on the draft and 
> we would like to hear your point of view.
> 
> I will attend the upcoming IETF#79 Beijing meeting, and it’s appreciated 
> if you have some time to discuss the draft during the meeting.
> 
> Looking forward to your feedback!
> 
> Thanks and best regards,
> 
> Lili
> 
> ------------------------------------------------------------------------
> 
> Lili Yang
> 华为技术有限公司Huawei Technologies Co., Ltd.
> Company_logo
> 
> Phone: +86-755-28422553
> Fax: +86-755-28420413
> Mobile:+86-13632632065
> Email: [email-masked]
> 地址：深圳市龙岗区坂田华为基地邮编：518129
> Huawei Technologies Co., Ltd.
> Bantian, Longgang District,Shenzhen 518129, P.R.China
> http://www.huawei.com
> 
> ------------------------------------------------------------------------
> 
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或 
> 群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发） 
> 本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from 
> HUAWEI, which
> is intended only for the person or entity whose address is listed above. 
> Any use of the
> information contained herein in any way (including, but not limited to, 
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the 
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender by
> phone or email immediately and delete it!
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2010 09:18:43 -0400

Lili - comments inline.

On 10/27/2010 3:46 AM, Lili Yang_lili wrote:
>
> Hello Paul,
>
> Thanks for your feedback!
>
> The premise of this draft is to fulfill the specific requirement in
> 3GPP. And it's a different case with the 3PCC as you mentioned.
>
> Concurrent with a normal session set-up towards a remote party, UE-1
> wants to establish a Collaborative Session, which is anchored at the
> SCC AS,
>

What is an SCC?

> with a new Media Flow-A on itself and a new Media Flow-B on another
> UE-2. Following is the information flow defined in 3GPP:
>

I'd like to see the intended o/a details for each of steps 1-6 above.

> And in step1, the ession setup request shall include enough
> information for the SCC AS to:
>
> - identify that Media-A shall be established in UE-1;
>
> - identify that Media-B shall be established in UE-2 and the requested
> media type associated with Media-B (e.g. video);
>
> Normally the UE-1 doesn’t know the IP address of the UE-2 but only the
> SIP address, hence we propose UE-1 sending the offer with the UE-2’s
> SIP address, to identify the requested media will be established in UE-2.
>

Having the above detail would allow a more informed discussion of the
possibilities.
(I don't have enough detail to know if this would work, but perhaps UE-1
could simply send a REFER to UE-2, with Refer-To of the SCC and a Join
header.)

I am much happier knowing that its the SCC, which is presumably a
resource under the control of UE-1, that is doing the heavy lifting,
rather than putting the burden on remote-party, which is an innocent
bystander.

Thanks,
Paul

> Hope this clarifies.
>
> Thanks and best regards,
>
> Lili
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 10:28 PM
> To: Lili Yang_lili
> Cc: Spencer Dawkins; 'Mayer Georg'; [email-masked]
> Subject: Re: Asking comments for
> draft-yang-dispatch-sip-connection-address-type
>
> Lili,
>
> > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人 或
>
> > 群组。禁
>
> > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散 发）
>
> > 本邮件中
>

---

From: Lili Yang_lili <[email-masked]>
Date: Thu, 28 Oct 2010 07:44:19 +0000

Hello Paul,
Please see inline.

Best regards,
Lili

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Wednesday, October 27, 2010 9:19 PM
To: Lili Yang_lili
Cc: [email-masked]
Subject: Re: Asking comments for draft-yang-dispatch-sip-connection-address-type

Lili - comments inline.

Hello Paul,

The premise of this draft is to fulfill the specific requirement in 3GPP. And it's a different case with the 3PCC as you mentioned.

Concurrent with a normal session set-up towards a remote party, UE-1 wants to establish a Collaborative Session, which is anchored at the SCC AS,

What is an SCC?
[Lili]: SCC AS is Service Centralization and Continuity Application Server, it anchors the session and executes transferring media in different UEs related procedures. And the other key word  is Collaborative Session: A set of two or more Access Legs and related media on two or more UEs having IMS subscriptions under the same operator that are presented as one Remote Leg by the SCC AS.

with a new Media Flow-A on itself and a new Media Flow-B on another UE-2. Following is the information flow defined in 3GPP:

[Lili]: Following are the details defined in 3GPP:
2.      The SCC AS sends a request to establish an Access Leg at UE-2 for Media-B.
3.      The SCC AS sends a session setup request to the remote party.
4.      The remote party sends a response with the SDP answer of Media-A and Media-B to the SCC AS.
5.      The SCC AS sends a response with the SDP answer of Media-A to UE-1 to establish Media-A in UE‑1.
6.      The SCC AS sends a response with the SDP answer of Media-B to UE-2 to establish Media-B in UE‑2.
After the above operation, a Collaborative Session is established, for which UE-1 becomes the Controller UE and UE‑2 becomes a Controllee UE. Media-A is established between Controller UE-1 and the remote party, and Media-B is established between Controllee UE-2 and the remote party.

And in step1, the ession setup request shall include enough information for the SCC AS to:

-        identify that Media-B shall be established in UE-2 and the requested media type associated with Media-B (e.g. video);

Normally the UE-1 doesn’t know the IP address of the UE-2 but only the SIP address, hence we propose UE-1 sending the offer with the UE-2’s SIP address, to identify the requested media will be established in UE-2.

Having the above detail would allow a more informed discussion of the possibilities.
(I don't have enough detail to know if this would work, but perhaps UE-1 could simply send a REFER to UE-2, with Refer-To of the SCC and a Join header.)

[Lili]: The case UE-1 sending REFER to UE-2 only happens when the UE-1 already had a session with remote UE-3. In this case, there is no session before step1.

I am much happier knowing that its the SCC, which is presumably a resource under the control of UE-1, that is doing the heavy lifting, rather than putting the burden on remote-party, which is an innocent bystander.
[Lili]: Yes, it’s the SCC AS should do the related specific procedures. There should be no impact on remote UE.

    Thanks,
    Paul

Hope this clarifies.

Thanks and best regards,

Lili

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, October 26, 2010 10:28 PM
To: Lili Yang_lili
Cc: Spencer Dawkins; 'Mayer Georg'; [email-masked]<mailto:[email-masked]>
Subject: Re: Asking comments for draft-yang-dispatch-sip-connection-address-type

Lili,

- Alice calls Anna's device sip:[email-masked]<mailto:sip:[email-masked]>

Anna's device.

         Thanks,

         Paul

> Email: [email-masked]<mailto:[email-masked]>