Subject: [MMUSIC] MSRP File transfer mechanism query

From: "Vikram Chhibber" <[email-masked]>
Date: Sat, 23 Feb 2008 16:51:38 +0530

Hi,

I have this query on the MSRP file transfer mechanism when used with
SIP. Once the transfer completes or is aborted, is there a need to
send re-INVITE to accordingly update the SDP (Say setting port of the
file transfer media description to 0)? If the answer is yes, then
whether the receiver or the sender should initiate this re-INVITE in
both these cases?

In my opinion, in case of aborting the file transfer, I think the
aborting end should send this re-INVITE and in case of successful file
transfer, the receiver should initiate this re-INVITE as he knows for
sure of the complete of the file transfer.

Thanks in advance,
~Vikram
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: "Vikram Chhibber" <[email-masked]>
Date: Tue, 26 Feb 2008 12:06:46 +0530

Any inputs on this? I can not find this clearly mentioned in the
existing draft. The draft mentions about file-
   transfer-id which could be used to distinguish between
session-refresh and new file transfer requests, cancellation of an
existing file-transfer and replacing it with new one.

The query is for the cases where there are multiple sessions involved
in a SIP dialog. say call and file-transfer.

Thanks,
~Vikram
On Sat, Feb 23, 2008 at 4:51 PM, Vikram Chhibber

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 26 Feb 2008 10:50:11 +0200

Hi Vikram:

Let me see if this clear your concern. The draft says in the last 
paragraph of Section 8.6:

    Once the file transfer is completed, the file sender SHOULD close the
    MSRP session, and MUST behave according to the MSRP [RFC4975]
    procedures with respect closing MSRP sessions.

To close the the MSRP session, the endpoint creates a new SDP offer and 
sets the port number to zero. I believe this is described in the SDP 
offer/answer (RFC 3264).

As for your questions: If a file transfer has completed and you need to 
re-send SDP, then the text is covered in the last paragraph of Section 
8.3 of the file transfer mechanism draft.

    In another scenario, an endpoint that has successfully transferred a
    file wants to send an SDP due to other reasons than the transfer of a
    file.  The SDP offerer creates an SDP file description that maintains
    the media description line corresponding to the file transfer.  The
    SDP offerer MUST then set the port number to zero and MUST keep the
    same value of the 'file-transfer-id' attribute that the initial file
    transfer got.

With respect the abort case, I think the text is written in the 
penultimate paragraph in Section 8.3:

    Assume that
    two endpoints agree on a file transfer and the actual transfer of the
    file is taking place.  At some point in time in the middle of the
    file transfer, one endpoint sends a new SDP offer, equal to the
    initial one, except for the value of the 'file-transfer-id'
    attribute, which is a new value within the session.  This indicates
    that the offerer wants to abort the existing transfer and start a new
    one, according to the SDP parameters.  The SDP answerer SHOULD abort
    the ongoing file transfer, according to the procedures of the file
    transfer protocol (e.g., MSRP), and start sending file once more from
    the initial requested octet.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: "Vikram Chhibber" <[email-masked]>
Date: Tue, 26 Feb 2008 18:48:11 +0530

Thanks Miguel. The abort operation is still not clear yet in case
either party wants to abort the call without replacing the file
getting transfered with a new one.
Sender has following options:
1. send a re-INVITE with port 0 for the file-transfer
media-description and retaining the file-transfer-id.
2. send a MSRP chunk with "#" ending character.
3. Perform both

Receiver has following options:
1. send a re-INVITE with port 0 for the file-transfer
media-description and retaining the file-transfer-id.
2. send failure-report with status code 413 if failure-report is set
to yes or partial.
3. perform both if failure-report is yes or partial else perform (1).

Please correct me if I am wrong. In above mentioned cases, sending
re-invite is must and step (2) should be optional. Please let me know
your opinion.

Thanks,
~Vikram

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 27 Feb 2008 12:54:08 +0200

Hi Vikram:

Inline discussion.

> 2. send a MSRP chunk with "#" ending character.

You are basically correct. If the sender wants to abort the transfer and 
not send any other file, it first has to stop sending data over MSRP, 
and send a "#" character in the continuation field of the end-line. Then 
it should close the MSRP session by setting the port number to zero.

> 3. perform both if failure-report is yes or partial else perform (1).

I think the receiver should do 1): re-INVITE with port number set to zero.

/Miguel

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

---

From: "Vikram Chhibber" <[email-masked]>
Date: Wed, 27 Feb 2008 20:22:38 +0530

Thanks Miguel once again. Also, I request that this behavior should be
explicitly clarified in the draft. Like me, many more will have same
issues here.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 28 Feb 2008 10:57:17 +0200

Yes, reasonable request. I will prepare a new version when the blackout 
is over.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 29 Feb 2008 11:51:38 +0200

We discuss how to cancel an ongoing file transfer, and Adam pointed out 
(in a different thread/list) that MSRP provides a response code 413 for 
canceling an ongoing SEND request (Section 10.5 in RFC 4975).

Adam pointed that 413 will cancel an ongoing SEND request (a single SEND 
message or chunked), but will not affect other different SEND requests 
that are sent over the same MSRP session. If the recipient wanted to 
cancel the whole MSRP session then he should can set the port number to 
zero in SDP.

When we apply the 413 response to the file transfer, the effect is th 
same as canceling the whole MSRP session, because the file transfer 
draft requires that an MSRP session is used for a single file, so 
canceling the session only has effect on that file being sent.

We will clarify this in a future version of the file transfer draft.

/Miguel