Subject: [Simple] MSRP offerer role

From: Ron Shacham <[email-masked]>
Date: Fri, 10 Jun 2005 10:25:35 -0400 (EDT)

Hello,
The MSRP draft (5.4) specifies that the initiator of the messaging 
session (offerer) also opens the TCP connection,  and
this offerer must start the session by immediately sending out a SEND 
request.  Although the draft mentions motivations for allowing 
negotiaton of the first role, I wish to present another one that applies 
to all of the offerer roles.

We are working on specifying in our 
draft on Session Mobility, draft-shacham-sipping-session-mobility-00 the
call flows for transfering MSRP sessions between endpoints.  One of our 
models, which uses Third-party Call Control, requires such a negotiation 
mechanism.  Since the controller (Mobile Node) only has a SIP signaling 
relationship with the target device, and that device otherwise communicates 
directly with the remote party (Correspondent Node), as in the case of
continuous media, either the target device or the Corr. Node must be 
informed that it should take on the responsibilities of the "offerer", 
even though they are both, inherently, recipients of an offer.

On another note, has there been discussion on specifying MSRP capability
as part of callee-caps?  Is it widely supported enough right now for this?
This question also has applications to our draft.

Regards,
Ron

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jun 2005 11:13:16 -0400

Ron - comments inline.

	Paul

Ron Shacham wrote:
> We are working on specifying in our draft on Session Mobility, 
> draft-shacham-sipping-session-mobility-00 the
> relationship with the target device, and that device otherwise 
> communicates directly with the remote party (Correspondent Node), as in 
> the case of

I am not understanding the point you are making.

I think what you are saying is just the usual situation for 3pcc 
regardless of what media are being used. The controller in the middle 
wants to orchestrate an offer/answer exchange between the two parties it 
is coordinating.

To do so, it normally chooses one party to be the offerer, and initiates 
things by sending it an offerless invite.

The new issues introduced by MSRP seem to be:
- the endpoint will have to somehow decide that it should offer MSRP.
   this isn't unique to MSRP. It is an issue as soon as there is more
   that one medium that can be used with sip. The simple answer is
   that the endpoint should probably offer everything it is willing
   to use at the time.

- the endpoint chosen to be offerer will also have to be the
   active party in MSRP session establishment.

> This question also has applications to our draft.

When you ask "is *it* widely supported enough right now", what do you 
mean by "it"? callee-caps or MSRP? How much is enough?

It certainly shouldn't hurt to use callee caps to advertise support, 
even if nobody else supports it. Depending on others having used callee 
caps may be a bit dicy. But the situation may be better in the case of 
MSRP, because there is probably little or no support for it out there 
yet. You can probably establish a precedent and ensure that all MSRP 
implementations do advertise support via callee caps.

	Paul

---

From: Ron Shacham <[email-masked]>
Date: Fri, 10 Jun 2005 11:38:31 -0400 (EDT)

Paul,
Sorry for the ambiguity.  See the clarifications below.

Ron

On Fri, 10 Jun 2005, Paul Kyzivat wrote:

> Ron - comments inline.
>
> 	Paul
>
> Ron Shacham wrote:
>> Hello,
>> The MSRP draft (5.4) specifies that the initiator of the messaging session 
>> (offerer) also opens the TCP connection,  and
>> request.  Although the draft mentions motivations for allowing negotiaton 
>> of the first role, I wish to present another one that applies to all of the 
>> offerer roles.
>> 
>> informed that it should take on the responsibilities of the "offerer", even 
>> though they are both, inherently, recipients of an offer.
>
> I think what you are saying is just the usual situation for 3pcc regardless 
> of what media are being used. The controller in the middle wants to 
> orchestrate an offer/answer exchange between the two parties it is 
> coordinating.
>

The second point you make here is the issue I was raising.  There must be 
a way to negotiate the active party.  This role in the session is what 
makes MSRP different from other media we are supporting.

> When you ask "is *it* widely supported enough right now", what do you mean by 
> "it"? callee-caps or MSRP? How much is enough?

MSRP.

>
> It certainly shouldn't hurt to use callee caps to advertise support, even if 
> nobody else supports it. Depending on others having used callee caps may be a 
> bit dicy. But the situation may be better in the case of MSRP, because there 
> is probably little or no support for it out there yet. You can probably 
> establish a precedent and ensure that all MSRP implementations do advertise 
> support via callee caps.

Your point is well taken--that MSRP should be able to grow along with its 
callee-caps.  Is there interest in defining this in the MSRP draft?

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jun 2005 15:59:54 -0400

Ron Shacham wrote:
>>> negotiaton of the first role, I wish to present another one that 
>>> applies to all of the offerer roles.
>>>
>>> call flows for transfering MSRP sessions between endpoints.  One of 
>>> our models, which uses Third-party Call Control, requires such a 
>>> negotiation mechanism.  Since the controller (Mobile Node) only has a 
>>> SIP signaling relationship with the target device, and that device 
>>> otherwise communicates directly with the remote party (Correspondent 
>>> Node), as in the case of
>>> informed that it should take on the responsibilities of the 
>>> "offerer", even though they are both, inherently, recipients of an 
>>> offer.
>>
>>
>> wants to orchestrate an offer/answer exchange between the two parties 
>> it is coordinating.
>>
>> To do so, it normally chooses one party to be the offerer, and 
>> initiates things by sending it an offerless invite.
>>
> The second point you make here is the issue I was raising.  There must 
> be a way to negotiate the active party.  This role in the session is 
> what makes MSRP different from other media we are supporting.

Do you have a suggestion here?

There was an explicit decision to not get into the complexity that 
comedia has around negotiating this. (I am not convinced that is 
implementable.)

I believe all the cases where there an endpoint might have difficulty 
taking either role are dealt with by the endpoint using a relay.

>> even if nobody else supports it. Depending on others having used 
>> callee caps may be a bit dicy. But the situation may be better in the 
>> case of MSRP, because there is probably little or no support for it 
>> out there yet. You can probably establish a precedent and ensure that 
>> all MSRP implementations do advertise support via callee caps.
> 
> 
> Your point is well taken--that MSRP should be able to grow along with 
> its callee-caps.  Is there interest in defining this in the MSRP draft?

Since the way of signaling this in SDP is

	m=message ...

the callee caps way of representing it is:

	+sip.message