Re: How to identify the session

On 10/12/12 1:07 AM, venu Y wrote:
> 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

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

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