Subject: [Simple] How to identify the session

From: venu Y <[email-masked]>
Date: Fri, 12 Oct 2012 10:37:09 +0530

Hi,

For file transfer we can uniquely identify the session, based on
'a=file-selector' attribute.

But for IM/MMS/Screen sharing... it's very unpredictable.

Will it solve all the problem if instead of m=message, if we have

m=im
m=screen-share
m=ftp

etc.,

or

Using 'SIP Tags' in the OFFER will solve most of the issues.. but will the
order of the Tags and 'm=' line are in sync or not is the issue?

On 10/10/12 5:54 PM, Adrian Georgescu wrote:
> 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

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

Thanks and Regards
-Venu

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Oct 2012 22:07:26 -0400

> Will it solve all the problem if instead of m=message, if we have

IMO the above are all terrible ideas.

> etc.,
>
> or
>
> Using 'SIP Tags' in the OFFER will solve most of the issues.. but will
> the order of the Tags and 'm=' line are in sync or not is the issue?

This seems to be abusing layering.

Why is there a problem at all with IM vs. screen sharing?
For one thing, why would you use MSRP for screen sharing when there are 
numerous other protocols for that purpose???

Or do you really mean just "URL sharing"?

In any case, could you not simply distinguish your screen images (or 
whatever they are) by media type?

If you want to discuss this in more depth, please take some time to 
explain more about the overall architecture in which you are 
encountering this problem.

	Thanks,
	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?
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple
>

---

From: Adrian Georgescu <[email-masked]>
Date: Sat, 13 Oct 2012 09:36:02 +0200

> For one thing, why would you use MSRP for screen sharing when there are numerous other protocols for that purpose???

MSRP can be used as a reliable transport to carry VNC protocol over it.  It works fine for end-points behind NAT by using a standard MSRP relay. 

Adrian