Subject: RE: [Simple] Handling of incoming INVITE request for different MSRP session

From: <[email-masked]>
Date: Fri, 28 Apr 2006 13:23:05 +0530

Hi Miguel,

If SDP offer/answer m-line ulr does not contain session id,as session ID
is a optional param, Is it mean that the offerer/answerer does not
support MSRP session multiplexing for sharing the same TCP connection? 

Regards,
Amit 

-----Original Message-----
From: Sudha [mailto:[email-masked]] 
Sent: Friday, April 28, 2006 1:02 PM
To: Miguel Garcia
Cc: Goel Amitkumar (IFIN SW WS); [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Simple] Handling of incoming INVITE request for different
MSRP session

Thanks Miguel.
Inline discussion

On Fri, 28 Apr 2006 11:46:42 +0530, Miguel Garcia
<[email-masked]> wrote:

> Inline discussion.
>
> Sudha wrote:
>> Hi Miguel,
>> -Does "m=" lines have different port numbers?
>>     If so, it would result in 2 TCP Connections and hence 2 MSRP 
>> Sessions. This would naturally result in two "a=path:" attributes 
>> which would complicate the message parsing.
>>     else if the media lines have the same port numbers it is like 
>> duplication of the previous media line and it doesnt carry any
meaning.
>
> Different m= lines will have the same port number, because they will 
> be sharing the same TCP connection. There is nothing new here, the 
> MSRP draft already discusses the TCP sharing in Sections 5.1 and 8.1.
>
> What we say in our draft is that each file transfer is identified with

> a different MSRP session. We can discuss if we need to share the same 
> session, but at the moment the draft says each m= line has a unique 
> MSRP sessionId. Still the port number used for the TCP connection is
the same.

With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt
the format of the m= line is:
m=<media> <port> <protocol> <format list> The format list field MUST be
set to "*".
The media doesn't accomadate for the MSRP sessionId.
The SessionId is specified in the url of the "a=path" attribute. Can the
session Id be specified in the format list?

>>  -How to distinguish between which media line is for normal MSRP Chat

>> and MSRP File Transfer.
>
> MSRP for File Transfer will have a file selector in the SDP. The file 
> selector is described in Section 6.1 of the File Transfer draft.
>
>>  -In the previous mail you had stated that, "Each m=message 
>> represents an MSRP media stream. Both can use the same MSRP session 
>> (TCP connection + session-id in MSRP), but they are different media 
>> streams, just multiplexed over the same TCP connection and MSRP 
>> session."
>>
>
> Note that sharing the same MSRP session is not correct, at least,  
> according to what we have in the draft now, my apologies.
>
>> It is possible to mutliplex MSRP Sessions(Identified by the session
Id)  
>> over the same TCP Connection. But I am not very clear with what you  
>> meant here by "MSRP media stream". Can you please give some info on
how  
>> to identify the media streams in the "m=" lines.
>
> That is probably the main point, we need a unique identifier, and that

> is the session Id in MSRP. That is the reason why the session ID has
to  
> be different.
>
>
> BR,
>
>          Miguel
>
>>  Regds,
>> Sudha.
>>   On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia  
>> <[email-masked]> wrote:
>>
>>> Hi Sudha:
>>>
>>> Inline discussion.
>>>
>>> Sudha wrote:
>>>> Hi all,
>>>> Is it valid to have two m= lines in a single INVITE?
>>>
>>> Yes, of course.
>>>
>>>> If such is a case, Is it valid to have two MSRP sessions created
for  
>>>> each of the media line?
>>>
>>> yes, why not?
>>>
>>>> As per the draft on File transfer using MSRP, once the File
transfer  
>>>> is completed, the MSRP Session associated with it will be closed.
So  
>>>> it should be apt to have 2 sessions for each of the media line.
>>>
>>> I am not sure what you mean with "2 sessions fr each of the media  
>>> line". Each m=message represents an MSRP media stream. Both can use

>>> the same MSRP session (TCP connection + session-id in MSRP), but
they  
>>> are different media streams, just multiplexed over the same TCP  
>>> connection and MSRP session.
>>>
>>> BR,
>>>
>>>        Miguel
>>>
>>>
>>>>  Regds,
>>>> Sudha
>>>>  On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia  
>>>> <[email-masked]> wrote:
>>>>
>>>>> Hi Amit:
>>>>>
>>>>> As you correctly mentioned, the spirit of the file transfer draft
is  
>>>>> to reuse existing MSRP sessions, if they are available. But we  
>>>>> always signal them in different m= lines. Notice that in the
example  
>>>>> you provided below there is only one m= line (for file transfer),
so  
>>>>> if you wanted to have chat and file transfer, you should have two

>>>>> m=message lines, one is a regular MSRP (chat), the other specific

>>>>> for file transfer.
>>>>>
>>>>> So, your question... "how do we handle a case where we receive a
SIP
>>>>> INVITE with a SDP offer containing both types of attributes (for  
>>>>> text messaging and file transfer) in a single m-line? " seems to
be  
>>>>> not applicable. We will have two m=message line, each one can have

>>>>> its own direction attribute if needed.
>>>>>
>>>>> BR,
>>>>>
>>>>>         Miguel
>>>>>
>>>>>
>>>>> [email-masked] wrote:
>>>>>> Hi Garcia, Ben and all,
>>>>>>  draft-garcia-sipping-file-transfer-mech-00.txt mandates that
there
>>>>>> should be separate msrp session (separate m-line) for the file  
>>>>>> transfer.
>>>>>> But draft-ietf-simple-message-sessions-14.txt does not really
>>>>>> differentiate between normal chat session and file transfer
session.
>>>>>> Also, it also does not mention the direction attribute. So User
can  
>>>>>> also
>>>>>> have uni directional MSRP session.  If user wants to create a  
>>>>>> session for chat and file transfer in the
>>>>>> single SIP INVITE. Considering the above mentioned drafts, our
>>>>>> understanding is that we will get two different m-lines in SDP  
>>>>>> offer for
>>>>>> msrp sessions.  In such a scenario, how do we handle a case where

>>>>>> we receive a SIP
>>>>>> INVITE with a SDP offer containing both types of attributes (for

>>>>>> text
>>>>>> messaging and file transfer) in a single m-line? For example if
we
>>>>>> receive an OFFER.
>>>>>>      v=0
>>>>>>       o=alice 2890844526 2890844526 IN IP4
host.atlanta.example.com
>>>>>>       s=
>>>>>>       c=IN IP4 host.atlanta.example.com
>>>>>>       t=0 0
>>>>>>       m=message 7654 TCP/MSRP *
>>>>>>     a=sendonly
>>>>>>       a=accept-types:text/plain *
>>>>>>       a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
>>>>>>       a=filename:My cool picture.jpg
>>>>>>       a=filetype:image/jpeg
>>>>>>       a=disposition:inline
>>>>>>       a=filesize:32349
>>>>>>       a=icon:cid:[email-masked]
>>>>>>       a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
>>>>>>  Regards,
>>>>>> Amit
>>>>>>  _______________________________________________
>>>>>> Simple mailing list
>>>>>> [email-masked]
>>>>>> https://www1.ietf.org/mailman/listinfo/simple
>>>>>>
>>>>>
>>>>    --Best Regards,
>>>> Sudha V.S
>>>
>>    --Best Regards,
>> Sudha V.S
>

-- 
Best Regards,
Sudha V.S

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Apr 2006 10:59:00 +0300

Hi,

note that the policy we currently use is not to cross-post to the SIP, 
SIPPING, and SIMPLE mailing lists. A particular discussion should take 
place in one and only one of those lists.

In any case, in the last IETF it was decided that this draft will be 
discussed in MMUSIC. I have cc:ed the MMUSIC mailing list in this 
message. Please, remove the SIPPING and SIMPLE mailing lists in your 
replies from now on.

Thanks,

Gonzalo
SIPPING co-chair

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo