Subject: [MMUSIC] RE: How to differentiate between different messaging session

From: "Claude Kawa" <[email-masked]>
Date: Thu, 4 May 2006 13:19:14 -0400

This interpretation is a stretch of the current "sendonly" and
"recvonly" definitions. The definitions refer to a "control protocol".
RTCP and RTP are considered to be 2 protocols and they use different
port numbers; whereas MSRP with its reporting function is one protocol
using only one port.  

I do not mind accepting this interpretation if it is the correct one.
But this issue should be addressed in the MMUSIC group for SDP and
SIMPLE for MSRP and the next versions of the two drafts should be
clarified unless it was already done and we have something written about
it.

Regards,

Claude

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 3:08 AM
To: [email-masked]
Cc: [email-masked]; Claude Kawa; Gonzalo Camarillo
Subject: Re: How to differentiate between different messaging session

So, it is clear that the a=sendonly attribute affects to the main 
"payload". In the case of RTP, you will be getting RTCP reports even 
when the a=sendonly applies.

If you extrapolate this to MSRP, an a=sendonly will apply to "SEND" 
requests that contain a regular payload. It wouldn't apply to REPORT 
requests, which are part of the "control" protocol. Similarly, if the 
SEND request is asking for a disposition report, it should be sent no 
matter on the a=sendonly attribute.

/Miguel

[email-masked] wrote:
> Hi Miquel,
>  
> Any comments from your side
>  
> Regards,
> Amit
> 
>
------------------------------------------------------------------------
> *From:* Claude Kawa [mailto:[email-masked]]
> *Sent:* Wednesday, May 03, 2006 7:31 PM
> *To:* [email-masked]
> *Subject:* Re: How to differentiate between different messaging
session
> 
> Hi all,
> 
>  
> 
> We still have to address the issue about using "sendonly". If we use 
> "sendonly" to describe the MSRP session how will the MSRP report get
to 
> the sender of the message?
> 
> "sendonly" describes a uni-directional session and to get a report, 
> shouldn't the session be "sendrecv"? An alternative would be to have
one 
> media path to send the message and another one to receive the report.
> 
>  
> 
> Here is what we have in the latest SDP draft about "sendonly" 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-26.txt :
> 
>  
> 
> a=sendonly
> 
>  
> 
>          This specifies that the tools should be started in send-only
> 
>          mode.  An example may be where a different unicast address is
> 
>          to be used for a traffic destination than for a traffic
source.
> 
>          In such a case, two media descriptions may be used, one
> 
>          sendonly and one recvonly.  It can be either a session or
media
> 
>          attribute, but would normally only be used as a media
> 
>          attribute.  It is not dependent on charset.  Note that
sendonly
> 
>          applies only to the media, and any associated control
protocol
> 
>          (e.g.  RTCP) SHOULD still be received and processed as
normal.
> Regards,
> Claude
------------------------------------------------------------------------
> 
>  
> 
>         1. Normal Messaging session (attribute line a=sendrecv (or
> sendonly) )
> NB: Normally sendrecv is used.
>         2. Pager mode session for large pager mode messages (>1300
> bytes) (attribute line a=sendonly)
> NB: The sendonly differentiates the pager mode session (recently
renamed 
> large message mode) from the normal session. Also the client (and may
be 
> the server) will tear down this session after the message is sent.
> 
>         3. Deferred mode session for deferred messages (attribute line
> a=sendonly)
> NB: The Deferred mode session for retrieval of the message is directed

> to the Deferred function on the Request-URI, so it is handled by this 
> particular function.
> 
>         4. File transfer session for file transfer via MSRP (attribute

> line a=sendonly)
> NB: All the new attributes defined for the file trasnfer like
a=filename 
> etc.. Are only used for file transfer
> 
>  
> 
>
------------------------------------------------------------------------
- 
> OMA - http://www.openmobilealliance.org Mailing List Archives are 
> available at http://mail.openmobilealliance.org
> 
> This message was delivered to you from the OMA-MWG-IM list on the OMA 
> Mailing List Server. If you wish to unsubscribe from this list please 
> send a message to: [email-masked] with the words

> SIGNOFF OMA-MWG-IM in the BODY of the message. 
>
------------------------------------------------------------------------
-
------------------------------------------------------------------------
- 
> OMA - http://www.openmobilealliance.org Mailing List Archives are 
> available at http://mail.openmobilealliance.org
> 
> This message was delivered to you from the OMA-MWG-IM list on the OMA 
> Mailing List Server. If you wish to unsubscribe from this list please 
> send a message to: [email-masked] with the words

> SIGNOFF OMA-MWG-IM in the BODY of the message. 
>
------------------------------------------------------------------------
-

-- 
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, 05 May 2006 09:20:05 +0300

I think a clarification should be added to the MSRP draft (SIMPLE). 
While RTP split the control protocol to RTCP, MSRP includes control 
messages (REPORT) in the protocol, so it isn't a straight forward issue.

I will recommend you to request this last-minute clarification in the 
SIMPLE mailing list copying the MSRP authors, it does not belong to 
MMUSIC any longer.

BR,

      Miguel