Subject: Re: [Sipping] Re: I-D ACTION:draft-loreto-sipping-dialog-correlation-00.txt

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Fri, 03 Mar 2006 11:24:04 +0200

I don't think Same-Session header is redundant.

the same draft-shacham-sipping-session-mobility-00 claims "there is
currently no standard way to associate multiple session as part of a
single call in SIP", and it just describes a method to overcome this
problem.
However the user of multi-device system described in Session Mobility
draft works for splitting a session to multiple device,
but it should not work in all the situations if we want add a new
service to an ongoing service. 
e.g. the new service needs a different path (sip route) from the one of
the on-going session.

Sal

On Mon, 2006-02-27 at 18:59 -0500, Paul Kyzivat wrote:
> This seems to be redundant with just adding a media stream to the 
> existing dialog.
> 
> Also, see draft-shacham-sipping-session-mobility-00 which is closely 
> related.
> 
> 	Paul
> 
> [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > 
> > 
> > 	Title		: The Session Initiation Protocol (SIP) Same-Session Header Field
> > 	Author(s)	: S. Loreto, G. Camarillo
> > 	Filename	: draft-loreto-sipping-dialog-correlation-00.txt
> > 	Pages		: 12
> > 	Date		: 2006-2-27
> > 	
> > This document defines a new header field for use with SIP.  The Same-
> > Session header field is used to logically correlate an existing SIP
> > dialog with a new SIP dialog when the media sessions established by
> > both dialogs can be considered a single logical session.  This
> > mechanism can be used to share the user interface and other resources
> > between all the media streams from both sessions.
> > 
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-loreto-sipping-dialog-correlation-00.txt
> > 
> > To remove yourself from the I-D Announcement list, send a message to 
> > [email-masked] with the word unsubscribe in the body of the message.  
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-loreto-sipping-dialog-correlation-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-loreto-sipping-dialog-correlation-00.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Mar 2006 10:08:34 -0500

Sal - comments below.

	Paul

> e.g. the new service needs a different path (sip route) from the one of

IMO there are already *two* mechanisms that can achieve the effect you 
are after. You are discounting both of them, but you have the burden of 
demonstrating why they aren't sufficient. So far you haven't convinced me.

1) Your draft mentions Join, and says it doesn't apply. But I disagree 
with you on that. Join establishes a conference at the SIP level. That 
conference could include many different media stream types. If initially 
there is only a two party call involving just voice, and another 
participant joins with only video, there is clearly no expectation that 
the video should be mixed with the audio. Instead, if the focus is 
capable, I would expect that the preexisting participants would be 
reinvited, offering a video stream in addition to their existing audio 
stream. This remains true if the focus is one of the participants.

This approach could even work for UAs that don't support conference 
mixing at all. It would simply mean that they would only support Join 
when it doesn't require any mixing.

This approach *does* require the target UA to have some new 
capabilities. But then so does your proposal. In the end they amount to 
the same thing, just using different syntax.

2) draft-shacham-sipping-session-mobility-00 moves the burden to the 
node that has the idea of combining multiple sources into one session. 
To the peer UA this appears simply as another media stream in the 
existing sip session. Thus there is much more likelihood that this can 
work with an arbitrary peer.

You don't really say, but perhaps you are assuming that these different 
"services" have different terminations at *both* ends, as in:

	Alice                        Bob
	 |       =====SIP======       |
	 |-Phone<              >Phone-|
	 |       ----audio-----       |
	 |                            |
	 |                            |
	 |         ====SIP====        |
	 |-Camera/<           >Camera-|
	 | TV      ---video--- TV     |

If so, then the correlation is only useful if the services are embodied 
in different UAs in the same device. If so, then IMO a better answer is 
to treat these different "services" as simply different capabilities of 
a single UA. Then you don't need multiple sip sessions to do the same 
thing, and you don't need another header to specify the correlation.

If the model above is what you have in mind, then what are you going to 
do when you get a call offering both audio and video in the same sip 
session? Are you going to make the caller call you twice, once for audio 
and again for video, and include the proposed correlation header to tie 
them together?

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Mar 2006 15:21:06 +0200

Hi Jonathan,

> I think the problem being addressed is that the media resources for a 
> session are dsitributed; my camera is in one place, and my microphone is 
> in another place.

Yes, that is the problem being addressed.

> We seem to constantly be coming back around to this 
> problem, and I still think that management of distributed endpoints
> (where a SIP endpoint is comprised of a bunch of distributed components 
> - a signaling component, RTP component, audio and video device 
> components, etc) is not best solved by SIP itself...

the proposal in this draft is quite different from previous attempts to 
remote control user agents using SIP. This proposal does not introduce 
any new remote control capabilities.

I agree with you that SIP does not do a good job remote controlling user 
agents. But this draft is not about managing distributed endpoints. This 
draft simply provides a means to correlate two sessions at the other 
end. We are talking about very loose coupling here.

Some use cases that are quite complex when implemented using 3pcc and 
session mobility (e.g., Replaces and REFER) become much simpler. For 
example, I walk into a meeting room while talking on my audio-only 
mobile terminal and I want to add video using the fixed camera and large 
screen in the meeting room.

Thanks,

Gonzalo

> Paul Kyzivat wrote:
>>> [email-masked] with the word unsubscribe in the body 
>>> of the message.  You can also visit 
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>>> subscription settings.
>>>
>>>
>>> http://www.ietf.org/shadow.html or 
>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>>     "FILE 
>>> /internet-drafts/draft-loreto-sipping-dialog-correlation-00.txt".

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Mar 2006 15:27:21 +0200

Hi Paul,

inline.

> when it doesn't require any mixing.

Overloading Join to do this just to avoid defining a new more explicit 
header field seems like a bad idea. If a UA can be the focus of a 
conference, it will announce support for Join. If a UA can correlate the 
media from two different SIP dialog, it will announce support for 
Same-Session. Overloading Join would make it impossible to trouble-shoot 
systems and to correlate sessions of the same media type (e.g., two 
audio streams) without mixing.

> work with an arbitrary peer.

As I pointed out in my previous email, the Same-Session header field 
simplifies scenarios that can get very complicated when using things 
like REFER, Replaces, etc...

Cheers,

Gonzalo

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 13 Mar 2006 17:48:00 -0800

Hi Gonzalo,

> audio streams) without mixing.

I don't see what the difference is.  If the UA can represent two or more
different SIP sessions as a single conversation, it can advertise Join.
There is a lengthy discussion in the SIP call control framework on the
definition of a conversation and why a distinct term is needed.

Let me ask a test question here.  If I have an IM session on my PC, an audio
session on my phone, a video session with a third appliance, and a
whiteboard session with an electronic whiteboard, which dialog-id is put in
the Same-Session header?  What happens if the user drops that particular
session?  I don't think these questions have been thought through well.

In the case of a Join, it is very clear that one of the UAs becomes a
focus.  Recall that the definition from the conferencing framework deals
with the control aspect of a focus, rather than any mixing.  Each UA that
wants to participate in the conversation sends an INVITE to the focus.  If
the media started by the focus is no longer needed, no problem.  The focus
can keep hosting the control for the conversation or it can find another
focus and move the focus there.

thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Mar 2006 22:23:38 -0500

what rohan said.

	Paul

Rohan Mahy wrote:
> Hi Gonzalo,
> 
> On 3/13/06, *Gonzalo Camarillo* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Paul,
> 
>     inline.
> 
> Let me ask a test question here.  If I have an IM session on my PC, an 
> audio session on my phone, a video session with a third appliance, and a 
> whiteboard session with an electronic whiteboard, which dialog-id is put 
> in the Same-Session header?  What happens if the user drops that 
> particular session?  I don't think these questions have been thought 
> through well.
> 
> with the control aspect of a focus, rather than any mixing.  Each UA 
> that wants to participate in the conversation sends an INVITE to the 
> focus.  If the media started by the focus is no longer needed, no 
> problem.  The focus can keep hosting the control for the conversation or 
> it can find another focus and move the focus there.
> 
> thanks,
> -rohan
> 
>      >>> [email-masked] <mailto:[email-masked]> wrote:
>      >>>
>      >>>> [email-masked]
>     <mailto:[email-masked]> with the word unsubscribe in
>     the body
>      >>>> Internet-Drafts are also available by anonymous FTP. Login
>     with the
>      >>>> username
>     <http://www.ietf.org/shadow.html> or
>      >>>>     [email-masked] <mailto:[email-masked]>.
>      >>>> In the body type:
>      >>>>     "FILE
>      >>>> /internet-drafts/draft- loreto-sipping-dialog-correlation-00.txt".
>      >>>>
>      >>>> NOTE:    The mail server at ietf.org <http://ietf.org> can
>     return the document in
>     <https://www1.ietf.org/mailman/listinfo/sipping>
>     Use [email-masked]
>     <mailto:[email-masked]> for questions on current sip
>     Use [email-masked] <mailto:[email-masked]> for new developments of core SIP
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 14 Mar 2006 09:10:34 +0200

Hi,

when the example does not include media streams of the same type, using 
Join works because the endpoint cannot attempt to mix anything. However, 
if there are streams of the same type (e.g., audio video streams), a 
focus (i.e., the endpoint) will most certainly try to perform some mixing.

You could keep your focus from mixing in this case, but if you also 
support mixing, how do you distinguish between the case where you will 
mix and the case where you will not mix? Or if you do not support mixing 
but nevertheless advertise support for Join, people joining your 
"conference" are not going to get any mixing.

Note that I agree with you that the use case is very similar to the Join 
use case and that, if nothing else is available, we could make it work 
using Join. However, I believe that having a means to signal this 
explicitly would be useful.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>> I don't see what the difference is.  If the UA can represent two or 
>> more different SIP sessions as a single conversation, it can advertise 
>> Join.  There is a lengthy discussion in the SIP call control framework 
>> on the definition of a conversation and why a distinct term is needed.
>>
>> audio session on my phone, a video session with a third appliance, and 
>> a whiteboard session with an electronic whiteboard, which dialog-id is 
>> put in the Same-Session header?  What happens if the user drops that 
>> focus.  Recall that the definition from the conferencing framework 
>> deals with the control aspect of a focus, rather than any mixing.  
>> Each UA that wants to participate in the conversation sends an INVITE 
>> to the focus.  If the media started by the focus is no longer needed, 
>> no problem.  The focus can keep hosting the control for the 
>> conversation or it can find another focus and move the focus there.
>>
>> thanks,
>> -rohan
>>
>>      >>>> A New Internet-Draft is available from the on-line 
>> Internet-Drafts
>>      >>>> directories.
>>      >>>>
>>      >>>>
>>      >>>>     Filename    : 
>> draft-loreto-sipping-dialog-correlation-00.txt
>>      >>>>     Pages        : 12
>>      >>>>     Date        : 2006-2-27
>>      >>>>
>>      >>>> /internet-drafts/draft- 
>> loreto-sipping-dialog-correlation-00.txt".
>>      >>>>
>>      >>>>     a MIME-compliant mail reader.  Different MIME-compliant 
>> mail
>>      >>>> readers

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Tue, 14 Mar 2006 11:35:49 +0200

Hi,

suppose I have an IM session on my PC and then I want start an audio
session on my Phone.
If I use Join header to correlate the IM session with the audio session
the UA receiving an Invite with a Join header will become a Focus.
Then the Focus will try to send a re-Invite to the UA on my PC in order
to add the audio to the on-going session. 
That one thing we are trying to avoid using the SameSession header.

Cheers
Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Mar 2006 02:51:28 -0500

> "conference" are not going to get any mixing.

Well, what do you do in this new proposal if the correlated dialogs have 
media of the same type?

I would think you would *want* them mixed.

If you don't, then probably some of the same stream tagging that has 
been proposed for conferencing could be used to indicate that these 
streams of the same type have different semantics and should not be mixed.

>>> more different SIP sessions as a single conversation, it can 
>>> advertise Join.  There is a lengthy discussion in the SIP call 
>>> control framework on the definition of a conversation and why a 
>>> distinct term is needed.
>>>
>>> Let me ask a test question here.  If I have an IM session on my PC, 
>>> an audio session on my phone, a video session with a third appliance, 
>>> and a whiteboard session with an electronic whiteboard, which 
>>> dialog-id is put in the Same-Session header?  What happens if the 
>>> user drops that particular session?  I don't think these questions 
>>> have been thought through well.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Mar 2006 03:01:00 -0500

> suppose I have an IM session on my PC and then I want start an audio

What is doing the correlation that is aware if both dialogs? What is the 
point of correlating them in this case?

> That one thing we are trying to avoid using the SameSession header.

That seems like a good thing, not a bad thing. I would expect that you 
wouldn't even be doing this if the IM application also supported voice. 
So it will refuse the voice and all will be as you expect.

This highlights one of my objections to this approach. It assumes that 
you need a separate UA for each media type. I see that as a backup 
scenario for those cases when you can't do better, rather than a 
desirable state of affairs. And when you need two devices or UAs to 
handle two media, it doesn't mean that the other party in the call also 
does. They should be able to have the media in a single call. So use 
something at your end to assemble the pieces you have into a multimedia UA.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 15 Mar 2006 10:32:38 +0200

Hi Paul,

> desirable state of affairs.

Not really. My mobile phone has a screen and a camera and it can do 
video, but if I am in a meeting room with a high quality camera and a 
giant screen, I will prefer to use the meeting room's camera and screen 
while I am there. Maybe I even want to use the speakers in the meeting 
room while still using the microphone on my terminal.

My point is that there are cases when folks may *want* to use different 
devices for a single session.

In any case, in order to summarize the discussions so far, we are 
talking about a conference with a different media mixing policy (i.e., 
no mixing). The open issue is how to signal this to the remote endpoint, 
which acts as the focus of the conference.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Mar 2006 22:49:37 -0500

> devices for a single session.

Yes, there are cases like that. But I don't see how this draft even 
addresses them. You are inflicting your desire to use multiple devices 
at *your* end on the party at the other end of the call. Just because 
*you* want to use multiple devices doesn't mean that *he* does. So why 
make him manage a correlation at his end?

draft-shacham-sipping-session-mobility-00.txt provides a way to do this 
on your end without especially troubling the other end.

> which acts as the focus of the conference.

Why can't each end take responsibility for how it wants to split up 
media among different devices. Then your only problem is coordinating 
the multiple devices at your own end.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Mar 2006 22:49:37 -0500

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Mar 2006 22:49:37 -0500

Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Mar 2006 19:42:08 -0800

I reread join and agree that the dialog-correlation sounds much different
that the semantics of JOIN. I imagine we could extent JOIN to cover this but
it seems like we need to do something to make this work - I don't see how to
anyone reading JOIN would end up implementing something that provided the
features needed here.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Mar 2006 09:36:17 -0500

> anyone reading JOIN would end up implementing something that provided the

If you already support JOIN (for conferencing) and you support both 
voice and video, and someone used JOIN for the scenario discussed in 
this draft, then it would end up doing the right thing. If the 
implementation was good, it would also realize that in this case it 
didn't need to do real mixing. If the focus outsources mixing to an 
external box, it could avoid using the external box in this case.

But my main issue with this is that the interconnect topology, and 
division of responsibility, is all wrong. It doesn't even cover the 
reciprocal case to the one in the draft - where a reinvite comes in 
offering both voice and video. I commented on that in another reply in 
this thread, so I won't repeat it here.

	Paul

>>>>>1) Your draft mentions Join, and says it doesn't apply. But I
>>>>
>>>>    disagree
>>>>
>>>>>with you on that. Join establishes a conference at the SIP level.
>>>>
>>>>    That
>>>>
>>>>>conference could include many different media stream types. If
>>>>
>>>>    initially
>>>>
>>>>>participant joins with only video, there is clearly no
>>>>
>>>>    expectation that
>>>>
>>>>>reinvited, offering a video stream in addition to their existing
>>>>
>>>>    audio
>>>>
>>>>>This approach could even work for UAs that don't support
>>>>
>>>>conference
>>>>
>>>>>mixing at all. It would simply mean that they would only
>>>>
>>>>support Join
>>>>
>>>>>2) draft-shacham-sipping-session-mobility-00 moves the burden
>>>>
>>>>to the
>>>>
>>>>>node that has the idea of combining multiple sources into one
>>>>
>>>>    session.
>>>>
>>>>>existing sip session. Thus there is much more likelihood that
>>>>
>>>>    this can
>>>>
>>>>>>>This seems to be redundant with just adding a media stream to
>>>>
>>>>the
>>>>
>>>>>>>existing dialog.
>>>>>>>
>>>>>>>Also, see draft-shacham-sipping-session-mobility-00 which is
>>>>
>>>>    closely
>>>>
>>>>>>>related.
>>>>>>>
>>>>>>>    Paul
>>>>>>>
>>>>>>>[email-masked] <mailto:[email-masked]>
>>>>
>>>>wrote:
>>>>
>>>>>>>>This document defines a new header field for use with
>>>>
>>>>    SIP.  The Same-
>>>>
>>>>>>>>Session header field is used to logically correlate an
>>>>
>>>>    existing SIP
>>>>
>>>>>>>>dialog with a new SIP dialog when the media sessions
>>>>
>>>>    established by
>>>>
>>>>>>>>mechanism can be used to share the user interface and other
>>>>
>>>>    resources
>>>>
>>>>>>>>To remove yourself from the I-D Announcement list, send a
>>>>
>>>>    message to
>>>>
>>>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce to
>>>>
>>>>change your
>>>>
>>>>>>>>subscription settings.
>>>>>>>>
>>>>>>>>
>>>>>>>>"anonymous" and a password of your e-mail address. After
>>>>
>>>>    logging in,
>>>>
>>>>>>>>    MIME-encoded form by using the "mpack" utility.  To use
>>>>
>>>>this
>>>>
>>>>>>>>    feature, insert the command "ENCODING mime" before the
>>>>
>>>>"FILE"
>>>>
>>>>>>>>    command.  To decode the response(s), you will need
>>>>
>>>>    "munpack" or
>>>>
>>>>>>>>    "multipart" MIME messages (i.e. documents which have been
>>>>
>>>>    split
>>>>
>>>>>>>>    up into multiple messages), so check your local
>>>>
>>>>    documentation on
>>>>
>>>>>>>>Below is the data which will enable a MIME compliant mail
>>>>
>>>>reader
>>>>
>>>>>>>>implementation to automatically retrieve the ASCII version
>>>>
>>>>of the
>>>>
>>>>>>>>Internet-Draft.
>>>>>>>>
>>>>