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

From: <[email-masked]>
Date: Thu, 4 May 2006 10:24:14 +0530

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.
------------------------------------------------------------------------
- 

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

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 04 May 2006 10:08:06 +0300

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:
> *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 
> “sendonly” describes a uni-directional session and to get a report, 
> shouldn’t the session be “sendrecv”? An alternative would be to have one 
> Here is what we have in the latest SDP draft about “sendonly” 
> ------------------------------------------------------------------------- 
> OMA - http://www.openmobilealliance.org Mailing List Archives are 
> -------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------- 
> OMA - http://www.openmobilealliance.org Mailing List Archives are 
> -------------------------------------------------------------------------
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland