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

From: Miguel Garcia <[email-masked]>
Date: Fri, 28 Apr 2006 13:21:54 +0300

I guess (my guess), that the syntax allows it to identify, for example, 
an MSRP relay. Probably you would need to input the MSRP URL of your 
relay in your endpoint configuration. So from that point of view, it is 
syntactically valid to have an MSRP URL without a session-ID. But when 
you include MSRP URLs in SDP, then you really need the session-id, as 
the draft indicates.

/Miguel

[email-masked] wrote:
> Thanks Miguel for the clarification. 
> 
> The formal syntax  in section 9 of the MSRP draft mislead me. 
> 
> ...
> ...
> ...
>  MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport
>        ["/" session-id] ";" transport *( ";" url-parameter)
>                         ; userinfo as defined in RFC3986, except
>                         ; limited to unreserved.
>                         ; hostport as defined in RFC3261
> ...
> ...
> 
> Regards,
> Amit
> 
> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Friday, April 28, 2006 3:20 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
> 
> 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
> 
> [email-masked] wrote:
>> 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: <[email-masked]>
Date: Fri, 28 Apr 2006 15:36:08 +0530

...
...
...

Regards,
Amit

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Friday, April 28, 2006 3:20 PM
To: Goel Amitkumar (IFIN SW WS)
Cc: [email-masked]; [email-masked];

Amit:

    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 [email-masked] Sat Apr 29 07:51:41 2006
Content-Class: urn:content-classes:message
Date: Fri, 28 Apr 2006 15:36:08 +0530
From: <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [MMUSIC] RE: Handling of incoming INVITE request for different MSRP
	session

...
...
...

Regards,
Amit

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Friday, April 28, 2006 3:20 PM
To: Goel Amitkumar (IFIN SW WS)
Cc: [email-masked]; [email-masked];

Amit:

Regards,

          Miguel

multiplexing"...

connection?