Subject: [Simple] How to identify application type of MSRP session.

From: Prasun Bheri <[email-masked]>
Date: Mon, 8 Oct 2012 12:41:58 +0530

Hello Group,
I would like to use MSRP for various applications such as IM/File
Transfer/Screen sharing etc.

What is the right way to identify, which MSRP session belongs to which
application?

Looking at SDP in SIP INVITE all applications could have same accept-types.

Thanks & Regards
Prasun

---

From: Adrian Georgescu <[email-masked]>
Date: Mon, 8 Oct 2012 09:17:29 +0200

Prasun,

The SDP is different between those media types, namely the a lines of the SDP. Some SIP trace examples for IM, FT and screen-sharing you can find here:

http://sylkserver.com/applications.phtml

Adrian

On Oct 8, 2012, at 9:11 AM, Prasun Bheri wrote:

> Hello Group, 
> I would like to use MSRP for various applications such as IM/File Transfer/Screen sharing etc.
> 
> What is the right way to identify, which MSRP session belongs to which application?
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Oct 2012 10:44:50 -0400

> Looking at SDP in SIP INVITE all applications could have same accept-types.

AFAIK there are no specific standards for this, but there are mechanisms 
you can use.

E.g. you may use the a=label attribute in sdp to associate an m-line 
with a label that is significant to an application.

	Thanks,
	Paul

---

From: Prasun Bheri <[email-masked]>
Date: Tue, 9 Oct 2012 10:46:08 +0530

Thanks Paul and Adrian.
Does it not create inter-op issues?
What is the best approach to inter-opp with other msrp implementations.

Thanks & Regards
Prasun

On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <[email-masked]> wrote:

> E.g. you may use the a=label attribute in sdp to associate an m-line with
> a label that is significant to an application.
>
>         Thanks,
>         Paul
>
>
> ______________________________**_________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/simple<https://www.ietf.org/mailman/listinfo/simple>
>

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 9 Oct 2012 08:48:24 +0200

Why do you think it creates interoperability issues?

Adrian

On Oct 9, 2012, at 7:16 AM, Prasun Bheri wrote:

> AFAIK there are no specific standards for this, but there are mechanisms you can use.
> 
> E.g. you may use the a=label attribute in sdp to associate an m-line with a label that is significant to an application.
> 
>         Thanks,
>         Paul
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Oct 2012 11:24:05 -0400

> What is the best approach to inter-opp with other msrp implementations.

Certainly it could.

The issue arises when you try to multiplex multiple "applications" on a 
single AOR and, I gather, a single dialog. Standardizing such usage 
would seem to require a new higher level application framework on top of 
sip. One such framework that comes to mind is IMS.

	Thanks,
	Paul

> Thanks & Regards
> Prasun
>
> On Mon, Oct 8, 2012 at 8:14 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     _________________________________________________
>     Simple mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/simple
>     <https://www.ietf.org/mailman/listinfo/simple>
>
>

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 10 Oct 2012 22:53:53 +0200

>> What is the best approach to inter-opp with other msrp implementations.

Can you please provide a real life example about how this can happen?

> The issue arises when you try to multiplex multiple "applications" on a single AOR and, I gather, a single dialog. Standardizing such usage would seem to require a new higher level application framework on top of sip. One such framework that comes to mind is IMS.

I am using such single dialog scenario with MSRP and I am not able to find any issue with it. Can you please expand what issue you are referring to.

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 17:22:13 -0400

> I am using such single dialog scenario with MSRP and I am not able to find any issue with it. Can you please expand what issue you are referring to.

Presumably you are encoding some "application identifier" somewhere, to 
distinguish between file transfer, screen sharing, etc. (E.g. you could 
be using a=label for this.)

This will work fine as long as you have control over the top level "meta 
application" at each end, and thus can assure that both ends agree on 
how to interpret which application is intended.

But it will stop working as soon as you bring in some different 
application at one end that doesn't understand your application identifiers.

So as long as you only want a proprietary solution there is no problem. 
When you want to open it up you can either convince everybody else to 
follow your defacto proprietary "standard", or you can come back here 
and create a real standard.

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 10 Oct 2012 23:54:14 +0200

Hi Paul,

I can see what you mean now. My understanding is that when interpreting the SDP one could do something like:

1. If one does not understand an m line, it will not use it and any a lines related to it
2. If one does understand an m line, will look necessarily at all a lines to figure out more details it understands and discard the ones it does not 

Are these assumptions good to have interoperability with other SDP end-points?

Adrian

On Oct 10, 2012, at 11:22 PM, Paul Kyzivat wrote:

> Presumably you are encoding some "application identifier" somewhere, to distinguish between file transfer, screen sharing, etc. (E.g. you could be using a=label for this.)
> This will work fine as long as you have control over the top level "meta application" at each end, and thus can assure that both ends agree on how to interpret which application is intended.
> 
> But it will stop working as soon as you bring in some different application at one end that doesn't understand your application identifiers.
> 
> So as long as you only want a proprietary solution there is no problem. When you want to open it up you can either convince everybody else to follow your defacto proprietary "standard", or you can come back here and create a real standard.
> 
> 	Thanks,
> 	Paul
> 
>> Adrian
>> 
>>> 
>>> 	Thanks,
>>> 	Paul
>>> 
>>>> Thanks & Regards
>>>> Prasun
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2012 18:48:27 -0400

> 1. If one does not understand an m line, it will not use it and any a lines related to it

Yes, that is what you are expected to do.
You would want to reject the m-line in the answer with a zero port.

> 2. If one does understand an m line, will look necessarily at all a lines to figure out more details it understands and discard the ones it does not

Yes, this is also the expectation.

> Are these assumptions good to have interoperability with other SDP end-points?

These are necessary but not sufficient for interoperability.

If one side puts in a proprietary a-line that must be understood to 
properly process the stream, and the other side doesn't understand that 
line, ignores it, and then handles the stream in a different way, then 
you still have an interoperability problem.

For instance, suppose you support both IM and screen sharing via MSRP. 
For one session you only intend to use screen sharing. You send off an 
offer with the MSRP m-lline and your indication that this is for screen 
sharing. The other side ignores that and assumes that this msrp session 
is for IM. It may then bring up a UI, and do all sorts of odd things.

You can probably avoid many problems just by which media types you 
support on the msrp session. In fact, you might be able to solve most of 
the problems you are trying to deal with by having unique media types 
for each of your applications. If not, then be careful.

If you aren't already aware of it, you should look at RFC 5547.

	Thanks,
	Paul