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

From: <[email-masked]>
Date: Fri, 28 Apr 2006 14:57:51 +0530

Hi Miguel,

Consider the case  when we get sdp offer with two m-line (without
session id)and corresponding attributes.  

    c=IN IP4 atlanta.example.com
    m=message 7654 TCP/MSRP *
    a=accept-types:text/plain
    a=path:msrp://atlanta.example.com:7654;tcp   

    c=IN IP4 atlanta.example.com
    m=message 7654 TCP/MSRP *
    a=accept-types:*
    a=path:msrp://atlanta.example.com:7654;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

Here both the path attributes are without session id.
 
Using this offer, 2 MSRP sessions are created. When MSRP data is
received over the TCP connection, how will I demultiplex MSRP data? To
identify the recipient session for the received MSRP data, I think we
must add session id to the MSRP URL. Hope I am clear this time.

Thanks and Regards,
Amit Kumar Goel

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

Continuing the discussion in mmusic...

It is clear that the m= line does not contain the MSRP session-id, which
is only visible in the a=path line. For example:

    c=IN IP4 atlanta.example.com
    m=message 7654 TCP/MSRP *
    a=accept-types:text/plain
    a=path:msrp://atlanta.example.com:7654/jshA7we;tcp

I don't really understand your question below. MSRP multiplexing over
the same TCP connection is an essential feature of MSRP, and it is at
the discretion of the MSRP endpoint to decide whether to multiplex or
not (although it is recommended to multiplex, otherwise you are
bypassing the congestion control built into TCP).

So, I don't really see your question about "support for multiplexing"...

Perhaps you can enlight me.

/Miguel

[email-masked] wrote:
> 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
> 
>  
> 
>
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 28 Apr 2006 12:49:35 +0300

Amit:

You are arguing that that MSRP URLs that are included in a=path line may 
not contain session-ids, as you indicated in your example below.

I would argue that such idea is not possible. While it is true that you 
can create an MSRP URL that does not include the session-id, it is only 
valid as a way to refer to the endpoint. But here, in SDP, we are 
referring not to an endpoint, but to a media stream of MSRP traffic, 
thus, so the MSRP URL it has to be fully qualified with the session-id.

I would refer to Section 8.2 of the MSRP draft. It mandates the usage of 
session IDs:

    The rightmost URL in the path attribute MUST identify the endpoint
    that generated the SDP document, or some other location where that
    endpoint wishes to receive requests associated with the session.  It
    MUST be assigned for this particular session, and MUST NOT duplicate
    any URL in use for any other session in which the endpoint is
    currently participating.  It SHOULD be hard to guess, and protected
    from eavesdroppers.  This is discussed in more detail in Section 14.

So in my opinion your example below is not valid according to MSRP.

Regards,

          Miguel