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

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 05 Jul 2006 16:55:08 +0300

Hi all,

An updated version of the "The Session Initiation Protocol (SIP) Dialog
Correlation" is available at:

http://tools.ietf.org/wg/sipping/draft-loreto-sipping-dialog-correlation-01.txt

The new version from the draft has been written according to the last
meeting and mailing list discussion. The most notable differences are:

- added an appendix about the difference between 3pcc and the
same-session header, it discusses in particular that 3pcc works in a
much more complex way. 

- highlighted that Same-Session Header solves the SIP lack, underlined
in the SIP Session Mobility draft, of a standard way to associate
multiple sessions as part of a single call in SIP.

- added an explanation about how a user server receiving a request with
a same-session header should reply

regards
Sal

On Fri, 2006-03-31 at 16:31 -0500, Paul Kyzivat wrote:
> 
> Adam Roach wrote:
> > Cullen Jennings wrote:
> > 
> > 
> >>I generally prefer the architecture in 1. The architecture in 2 results in A
> >>having all the limitations of a B2BUA with a media relay.
> >>
> > 
> > 
> > No; the diagram is *signaling* relationships, not *media* relationships.
> > A no more needs to relay media for C than a Media Gateway Controller
> > needs to relay media for the Media Gateway(s) it is controlling.
> > 
> > A key issue -- for me at least -- is that the ability for *me* to use
> > multiple devices in a call should be predicated on the capabilities of
> > *my* *own* devices, not the capabilities of whomever I'm calling.
> 
> Yes, this is key for me as well.
> 
> > Approach 1 has such a characteristic. Approach 2 does not.
> 
> How does that follow? IMO the converse is true.
> 
> 	Paul
> 
> > /a
> > 
> > 
> >>Take the case
> >>below for example: If A is an 802.11 wireless audio only phone, now all the
> >>video needs to flow across the wireless network, twice. I'm not saying that
> >>no one will ever implement 2 (my employer does for example), I'm just saying
> >>there are situations where 1 has many advantages over 2.
> >>
> >>And either way A and C might need some coordination protocol but that seem
> >>like an orthogonal issue.
> >>
> >>On 3/24/06 12:24 PM, "Paul Kyzivat" <[email-masked]> wrote:
> >>
> >> 
> >>
> >>
> >>>We can get hung up on what protocols are used, but fundamentally there
> >>>are two different architectures for this situation:
> >>>
> >>>1) A ------------------ B
> >>>                   |
> >>>C -------------------|
> >>>
> >>>2) A ------------------ B
> >>>|
> >>>C
> >>>
> >>>In the above, A is the node that wants to use a camera, C is the camera,
> >>>and B is the other participant in the call, and largely a passive bystander.
> >>>
> >>>It is architecture (1) that is advocated by this draft. I have suggested
> >>>that (2) is a better architecture that can be achieved using sip 3pcc.
> >>>Adam is, I think, suggesting (2) using mbus for the A-C link.
> >>>
> >>>A key difference is how much is expected of B to make this work. I hear
> >>>some say that this is really easy for B to do. But I'm not so sure that
> >>>is true. For instance, suppose that C is included using approach (1),
> >>>and then B decides to transfer "the call" to node D. Is it the
> >>>responsibility of B to transfer both A and C, or only A. If it is
> >>>expected to transfer both A and C, then the complexity for B has been
> >>>increased.
> >>>
> >>>I also don't see how A uses approach (1) if A and B are in session and B
> >>>sends a reinvite to A proposing to add video to the existing session.
> >>>
> >>>Paul
> >>>
> >>>
> >>>Adam Roach wrote:
> >>>   
> >>>
> >>>
> >>>>Even, Roni wrote:
> >>>>
> >>>>
> >>>>     
> >>>>
> >>>>
> >>>>>Hi Gonzalo,
> >>>>>The example in the email thread
> >>>>>"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."
> >>>>>Is a good example. I am aware that using a phone for audio and a separate
> >>>>>appliance or web camera for video is available in real products. The
> >>>>>correlation is done in a central entity and you cannot easily achieve the
> >>>>>scenario you describe in the above example being of ad-hoc relationship. The
> >>>>>need to the correlation in this case is important, for example, for
> >>>>>lip-synch or in multipoint for voice activated video switch.
> >>>>>
> >>>>>
> >>>>>       
> >>>>>
> >>>>
> >>>>I think you're right. It sounds like we need "a light-weight
> >>>>message-oriented coordination protocol for group communication between
> >>>>application components." To support this specific use case in a
> >>>>transparent fashion, it sounds like it need to provide "automatic
> >>>>location of communication peers."
> >>>>
> >>>>Text in quotes is not my own. I attribute it to the abstract of
> >>>>http://www.ietf.org/rfc/rfc3259.txt
> >>>>
> >>>>My point being: we solved this problem already. We're hearing from
> >>>>multiple people that we need multi-device coordination. Let's leverage
> >>>>the wheel that we've already invented instead of starting from scratch.
> >>>>
> >>>>/a
> >>>>
> >>>>_______________________________________________
> >>>>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
> >>>   
> >>>
> >>
> >> 
> >>
> > 
> > 
> 
> _______________________________________________
> 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: Wed, 05 Jul 2006 19:04:56 -0400

Hi,

The discussion on -00 died down without ever being resolved, so there 
are a number of loose threads from that which we might need to pick up 
again. For those interested, there was a thread that began on 3-mar and 
ended on 30-mar.)

I will try to bring the ones that still make sense up again in separate 
messages to facilitate discussion. I'll just start up with one, 
rephrasing based on hindsight.

The example in your draft starts with a session involving only a single 
medium - voice. Then Alice's phone brings in Alice's video to handle 
video on its end, but with both targeted to Bob. That seems to require 
Bob to implement both media. But what if Bob is in the same situation, 
with audio and video on separate devices?

Conversely, using the same infrastructure from your scenario, what if 
Bob calls Alice, offering both audio and video? (This is natural for Bob 
since he handles both.)

At the very least, IMO there is clearly a need for a clearer explanation 
of the kinds of environments and scenarios there this mechanism is 
purported to be useful.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Jul 2006 19:14:18 -0400

Picking up a different point from the earlier (19-mar) thread...

Paul Kyzivat wrote:
> Gonzalo Camarillo wrote:
[snip]
>> My point is that there are cases when folks may *want* to use different 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.
[snip]
> 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: <[email-masked]>
Date: Thu, 6 Jul 2006 16:41:20 +0530

> The example in your draft starts with a session involving 
> only a single medium - voice. Then Alice's phone brings in 
> Alice's video to handle video on its end, but with both 
> targeted to Bob. That seems to require Bob to implement both 
> media. But what if Bob is in the same situation, with audio 
> and video on separate devices?

For covering this scenario I think it would be needed not reject 
a Dialog which has a Same-Session which does not match, but it should
be accepted saying "accepting the call, but did not match any other
Dialog".

This way calls to Bob can get forked to all his devices and which-ever
one 
has the facility to do Video will accept it. 
This way Alice need not know if Bob has a single device or multiple
devices.

Is there any downside not reject the call which does not have the
matching Same-Session but accept it and notify with some mechanism in
the 200OK, that such is the case.

Also, what does the "strictly-flag" indicate? I was not able to get it
by reading through the draft.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 4:35 AM
> To: Salvatore Loreto (JO/LMF)
> Cc: Cullen Jennings; Adam Roach; Adam Roach; Roni Even; 
> [email-masked]; sipping
> Subject: Re: [Sipping]Re: 
> I-DACTION:draft-loreto-sipping-dialog-correlation-00.txt
> 
> Hi,
> 
> The discussion on -00 died down without ever being resolved, 
> so there are a number of loose threads from that which we 
> might need to pick up again. For those interested, there was 
> a thread that began on 3-mar and ended on 30-mar.)
> 
> I will try to bring the ones that still make sense up again 
> in separate messages to facilitate discussion. I'll just 
> start up with one, rephrasing based on hindsight.
> 
> The example in your draft starts with a session involving 
> only a single medium - voice. Then Alice's phone brings in 
> Alice's video to handle video on its end, but with both 
> targeted to Bob. That seems to require Bob to implement both 
> media. But what if Bob is in the same situation, with audio 
> and video on separate devices?
> 
> Conversely, using the same infrastructure from your scenario, 
> what if Bob calls Alice, offering both audio and video? (This 
> is natural for Bob since he handles both.)
> 
> At the very least, IMO there is clearly a need for a clearer 
> explanation of the kinds of environments and scenarios there 
> this mechanism is purported to be useful.
> 
> 	Paul
> 
> > An updated version of the "The Session Initiation Protocol (SIP) 
> > Dialog Correlation" is available at:
> > 
> > 
> > 
> > - added an explanation about how a user server receiving a request 
> > with a same-session header should reply
> > 
> >  
> > regards
> > Sal
> > 
> > 
> > 
> >>>> I generally prefer the architecture in 1. The architecture in 2 
> >>>> results in A having all the limitations of a B2BUA with 
> a media relay.
> >>>>
> >>>
> >>> A key issue -- for me at least -- is that the ability for *me* to 
> >>> use multiple devices in a call should be predicated on the 
> >>> capabilities of
> >>>> below for example: If A is an 802.11 wireless audio only 
> phone, now 
> >>>> all the video needs to flow across the wireless network, 
> twice. I'm 
> >>>> not saying that no one will ever implement 2 (my 
> employer does for 
> >>>> example), I'm just saying there are situations where 1 
> has many advantages over 2.
> >>>>
> >>>> And either way A and C might need some coordination protocol but 
> >>>> that seem like an orthogonal issue.
> >>>>
> >>>>> We can get hung up on what protocols are used, but 
> fundamentally 
> >>>>> there are two different architectures for this situation:
> >>>>>
> >>>>> In the above, A is the node that wants to use a camera, 
> C is the 
> >>>>> camera, and B is the other participant in the call, and 
> largely a passive bystander.
> >>>>>
> >>>>> It is architecture (1) that is advocated by this draft. I have 
> >>>>> suggested that (2) is a better architecture that can be 
> achieved using sip 3pcc.
> >>>>> A key difference is how much is expected of B to make 
> this work. I 
> >>>>> hear some say that this is really easy for B to do. But 
> I'm not so 
> >>>>> sure that is true. For instance, suppose that C is 
> included using 
> >>>>> approach (1), and then B decides to transfer "the call" 
> to node D. 
> >>>>> Is it the responsibility of B to transfer both A and C, 
> or only A. 
> >>>>> If it is expected to transfer both A and C, then the complexity 
> >>>>> for B has been increased.
> >>>>>
> >>>>> I also don't see how A uses approach (1) if A and B are 
> in session 
> >>>>> and B sends a reinvite to A proposing to add video to 
> the existing session.
> >>>>>
> >>>>> Paul
> >>>>>
> >>>>>
> >>>>> Adam Roach wrote:
> >>>>>   
> >>>>>
> >>>>>
> >>>>>> Even, Roni wrote:
> >>>>>>
> >>>>>>
> >>>>>>     
> >>>>>>
> >>>>>>
> >>>>>>> Hi Gonzalo,
> >>>>>>> "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."
> >>>>>>> Is a good example. I am aware that using a phone for 
> audio and a 
> >>>>>>> separate appliance or web camera for video is 
> available in real 
> >>>>>>> products. The correlation is done in a central entity and you 
> >>>>>>> cannot easily achieve the scenario you describe in the above 
> >>>>>>> example being of ad-hoc relationship. The need to the 
> >>>>>>> correlation in this case is important, for example, 
> for lip-synch or in multipoint for voice activated video switch.
> >>>>>>>
> >>>>>>>
> >>>>>>>       
> >>>>>>>
> >>>>>> message-oriented coordination protocol for group communication 
> >>>>>> between application components." To support this specific use 
> >>>>>> case in a transparent fashion, it sounds like it need 
> to provide 
> >>>>>> "automatic location of communication peers."
> >>>>>>
> >>>>>> My point being: we solved this problem already. We're hearing 
> >>>>>> from multiple people that we need multi-device coordination. 
> >>>>>> Let's leverage the wheel that we've already invented 
> instead of starting from scratch.
> >>>>>>
> >>>>>> /a
> >>>>>>
> >>>>>> 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
> >>>>>   
> >>>>>
> >>>>
> >>>>
> >>>
> >> 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
> > 
> > 
> > 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
> > 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 Jul 2006 15:21:52 +0300

Hi Paul,

thanks for following up on this point.

As the draft states, you could do everything using 3pcc, which does not 
require the other end to support anything new. It works. However, the 
complexity of the resulting call flows is much higher than the 
complexity of those when the header proposed in this draft is used, as 
described in the appendix of the draft.

I do not expect many UAs to implement the logic needed to orchestrate 
different devices using 3pcc. On the other hand, the implementation of 
the same-session header field would be a much simpler task.

So, if the remote UA supports this header, you can use it. If it does 
not support it, you are in the same situation as today.

Cheers,

Gonzalo

Paul Kyzivat wrote:
>> 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.
> [snip]
>> 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
> 
>>>>> results in A
>>>>>> suggested
>>>>>>>> audio-only
>>>>>>> between

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 Jul 2006 15:36:57 +0300

Hi Paul,

> The example in your draft starts with a session involving only a
> single medium - voice. Then Alice's phone brings in Alice's video to
> handle video on its end, but with both targeted to Bob. That seems to
> require Bob to implement both media. But what if Bob is in the same
> situation, with audio and video on separate devices?

the same-session header field resolves a simple scenario, as you point
out. If we want to resolve the more complex scenario, where every user
can use an arbitrary number of UAs to handle the different media streams
belonging to the same logical session, we will need a more complex solution.

For example, a UA would need to have a means to let the remote UA know
to which URI a new INVITE needs to be sent in order to add video to the
session. Additionally, the information needed to correlate those dialogs
would need to include more information (currently it includes Call-ID
and tags).

So, the question is: what are the requirements? Do we want to resolve
the complex scenario?

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jul 2006 14:59:54 -0400

Ravi,

Something along the lines you suggest might work. The devil is in the 
details. Seems to call at least for a use case and call flow showing how 
this would work.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jul 2006 15:04:06 -0400

> So, the question is: what are the requirements? Do we want to resolve

The case is not complex. It is the *same* scenario except inverting 
caller and callee. If that can't be accomodated, is it worth doing?

Consider that this requires Bob to implement support for the 
Same-Session header. What motivates Bob to do so? Does he get anything 
out of it? I think at least reciprocity in support of audio/video would 
be required for this to be worth doing.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Jul 2006 15:07:10 -0400

> the same-session header field would be a much simpler task.

Note that it need not be implemented by end user devices. It can be 
implemented by a server residing in the network. E.g. it could be 
implemented by an Application Server in an IMS network. Considering what 
IMS currently requires, including fairly complex B2BUA support, this 
should not be that much of a stretch.

	Paul

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 Jul 2006 15:45:24 +0300

Hi,

> by reading through the draft.

I had already told Salvatore about this. It seems that the xml source to 
create version 01 of the draft did not include some of the last fixes 
that were performed to version 00 before releasing it. This will be 
resolved in the next release of the draft. So, you can just ignore that 
flag.

Thanks,

Gonzalo

---

From: "Srivatsa Srinivasan" <[email-masked]>
Date: Thu, 6 Jul 2006 13:40:07 -0700

> can use an arbitrary number of UAs to handle the different media
> streams belonging to the same logical session, we will need a more
> complex solution.

[SS] Is it worth solving the simple scenario here? In the example shown,
what if session-mode IM was added from a different device with the video
device sending a REFER. Bob's client device will have to correlate all
three dialogs as one logical conversation. And it would have to do this
by correlating many dialog ID's instead of having just one single ID.

> session. Additionally, the information needed to correlate those
> dialogs would need to include more information (currently it includes
> Call-ID and tags).
> 

[SS] Not sure if this has been looked into or discussed on this list
before -- for session-mode or page-mode multi-party distributed IM
conversations, it's useful to have the concept of a conversation that
correlates many dialogs together using some single identifier. I can
think of a few ways to accomplish this. 

A simple mechanism is to use a globally unique Conversation-ID header to
propagate this information that Alice's phone generates and everyone
else uses. This approach needs to be well thought out in cases when
REFER is used. 

Another approach without the introduction of a new header, in the case
of dialogs is to use a unique GRUU+GRID to identify a specific
conversation. In the example shown in the draft, Bob would generate a
unique GRUU+GRID to identify this conversation. Alice's phone on
receiving this may REFER Alice's video to that specific GRUU+GRID
(recognizing that this is a GRUU). Bob on seeing the same GRID may then
correlate the different sessions together. Of course, this approach
requires further thought in negotiating Require/Supported as Bob may not
generate a GRUU+GRID for identifying a conversation (but may do so for
other reasons and to solve this Bob could include a isfocus-like feature
parameter to indicate this). On the down side, this mechanism deviates
from the current use of Contact headers and typically requires both
sides of the parties to understand what conversation URI's are (which is
somewhat true in the Same-Session case as well).

Srivatsa.

---

From: <[email-masked]>
Date: Fri, 7 Jul 2006 09:32:19 +0530

Comment inline.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 6:07 PM
> To: Paul Kyzivat
> Cc: Cullen Jennings; Adam Roach; Adam Roach; Roni Even; sipping
> the same-session header field resolves a simple scenario, as 
> you point out. If we want to resolve the more complex 
> scenario, where every user can use an arbitrary number of UAs 
> to handle the different media streams belonging to the same 
> logical session, we will need a more complex solution.
> 
> For example, a UA would need to have a means to let the 
> remote UA know to which URI a new INVITE needs to be sent in 
> order to add video to the session. 

I think this capability might already be coming in with the
Communication Session Identifier and Application Reference that is being
proposed in another draft in parallel. For example, if Alice's UA which
can support, can indicate that to the network, and Alice's Video device
can indicate its capability, there is no need for Bob to know the
details.

> Additionally, the 
> information needed to correlate those dialogs would need to 
> include more information (currently it includes Call-ID and tags).
> 
> So, the question is: what are the requirements? Do we want to 
> resolve the complex scenario?
> 
> Thanks,
> 
> Gonzalo
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Jul 2006 09:58:43 +0300

Hi,

> implemented by an Application Server in an IMS network. Considering
> what IMS currently requires, including fairly complex B2BUA support,
> this should not be that much of a stretch.

this solution is intended to be a general mechanism, not an IMS-only
mechanism. I do not like the idea of proposing a complex mechanism based
on B2BUAs as a better alternative than a simple end-to-end mechanism.

Cheers,

Gonzalo

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Fri, 07 Jul 2006 10:28:44 +0300

Hi Srivatsa

see in line

/sal

> by correlating many dialog ID's instead of having just one single ID.

An idea here could be use always the original (audio dialog ID in the
example) to correlate all the subsequent dialogs.

So, as in your example, the video device sending a REFER to a different
IM device SHOULD or MUST use the "original" dialog ID (the audio one) in
the Same-Session header

> think of a few ways to accomplish this. 

just out of curiosity:
are to thinking of a way to correlate the different dialogs between
users and focus, or a way to correlate dialog to a Conversation in a
time (e.g. I want continue the yesterday IM chat/discussion )?

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Jul 2006 16:16:44 +0300

Hi Paul,

> caller and callee. If that can't be accomodated, is it worth doing?

if we only invert the roles the scenario can be easily accommodated. The
callee rejects the video stream and sends a REFER to his video-only UA,
which will send an INVITE with a same-session header right away. In
short, this scenario can be easily transformed in the original scenario
where the distributed entity is the one initiating the call.

However, what I had in mind when I read your email was to have two
distributed endpoints. That is, you should send the INVITE for video to
a different URI. That was the case I thought it was more complex.

It is definitively worthwhile spending some time thinking of this
scenario and how it can be implemented.

> Same-Session header. What motivates Bob to do so? Does he get
> anything out of it? I think at least reciprocity in support of
> audio/video would be required for this to be worth doing.

If Bob implements the same-session header, he will be able to interact
with Alice (who is using the distributed endpoint) using voice and
video. If Bob does not support it, they will interact using audio only.

Thanks,

Gonzalo

---

From: "Srivatsa Srinivasan" <[email-masked]>
Date: Fri, 7 Jul 2006 09:10:34 -0700

Hi Salvatore,

More inline...

Thanks,
Srivatsa.

> > [SS] Is it worth solving the simple scenario here? In the example
> > shown, what if session-mode IM was added from a different device
with
> > the video device sending a REFER. Bob's client device will have to
> > correlate all three dialogs as one logical conversation. And it
would
> > have to do this by correlating many dialog ID's instead of having
> just one single ID.
> 
> IM device SHOULD or MUST use the "original" dialog ID (the audio one)
> in the Same-Session header

[SS] Using the original dialog ID and passing that along to a
third-party has security implications associated with it -- you don't
want a third-party to know of any dialog but their own. Alternatively,
you could use a unique ID in the Same-Session or compute a one-way hash
of the dialog-ID but that would be similar to introducing a new header
with a unique ID for that purpose (i.e. Conversation-ID). One could
argue that there are security implications with the Conversation-ID
approach as well -- but you could use a similar Referred-By like
verification scheme for certain cases and for certain other cases a
transitive trust architecture may be required (as in the Target-Dialog
proposal). 

> time (e.g. I want continue the yesterday IM chat/discussion )?

[SS] The user/focus case is less interesting as the focus identifies the
conversation. But, one requirement is to correlate these dialogs over
time for various reasons (one being tracking/monitoring). Consider the
case where a two-party conversation is escalated into a focus
conferencing scenario or the distributed multi-party IM case or the
three-device case we just discussed. In all these cases, dialogs may
initiate and terminate, however the conversation remains alive. 

> 
> >
> > A simple mechanism is to use a globally unique Conversation-ID
header
> > to propagate this information that Alice's phone generates and
> > everyone else uses. This approach needs to be well thought out in
> > cases when REFER is used.
> >
> > (recognizing that this is a GRUU). Bob on seeing the same GRID may
> > then correlate the different sessions together. Of course, this
> > approach requires further thought in negotiating Require/Supported
as
> > Bob may not generate a GRUU+GRID for identifying a conversation (but
> > may do so for other reasons and to solve this Bob could include a
> > isfocus-like feature parameter to indicate this). On the down side,
> > this mechanism deviates from the current use of Contact headers and
> > typically requires both sides of the parties to understand what
> > conversation URI's are (which is somewhat true in the Same-Session
> case as well).
> >
> > Srivatsa.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jul 2006 17:44:29 -0400

> where the distributed entity is the one initiating the call.

I can buy that I guess.

> a different URI. That was the case I thought it was more complex.

This seems important too. If this use case is relevant then having two 
distributed endpoints becomes likey and again reciprocity seems a 
requirement.

> video. If Bob does not support it, they will interact using audio only.

Or bob can tell alice to get a better video phone. :-)

In the end, the market will determine what is supported. But its 
probably easier if these distributed endpoints that use the new feature 
can talk to each other and thus establish a user base that can motivate 
others to support it.

I believe if this is adopted there is need for further clarification on 
what it means for two invite dialog usages to be part of the "same 
session". E.g. what happens if a transfer is attempted?

	Paul

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 10:11:45 +0530

Comment inline.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor

> Sent: Friday, July 07, 2006 6:47 PM
> To: Paul Kyzivat
> if we only invert the roles the scenario can be easily 
> accommodated. The callee rejects the video stream and sends a 
> REFER to his video-only UA, which will send an INVITE with a 
> same-session header right away. In short, this scenario can 
> be easily transformed in the original scenario where the 
> distributed entity is the one initiating the call.

In the above scenario, how will the callee's Video UA know 

1. that it should put in the same-session header (that it is going to be
part of already existing commmunication session)
2. what call-id etc to put in the same-session header

It might not be possible to get the above details from the REFER coming
from the callee's Audio UA.

> 
> However, what I had in mind when I read your email was to 
> have two distributed endpoints. That is, you should send the 
> INVITE for video to a different URI. That was the case I 
> thought it was more complex.
> 
> It is definitively worthwhile spending some time thinking of 
> this scenario and how it can be implemented.
> 
> > out of it? I think at least reciprocity in support of audio/video 
> > would be required for this to be worth doing.
> 
> If Bob implements the same-session header, he will be able to 
> interact with Alice (who is using the distributed endpoint) 
> using voice and video. If Bob does not support it, they will 
> interact using audio only.
> 
> Thanks,
> 
> Gonzalo
>