Re: [MMUSIC] MSRP File transfer mechanism query

["Vikram Chhibber" <vikram.chhibber at gmail.com>]

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
On Tue, Feb 26, 2008 at 2:20 PM, Miguel Garcia <Miguel.Garcia at nsn.com> wrote:
> 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
>
>
>
>
>
>  Vikram Chhibber wrote:
>  > 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
>  > <vikram.chhibber at gmail.com> wrote:
>  >> 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
>  > mmusic at ietf.org
>  > http://www.ietf.org/mailman/listinfo/mmusic
>  >
>
>  --
>  Miguel A. Garcia           tel:+358-50-4804586
>  Nokia Siemens Networks     Espoo, Finland
>
>
_______________________________________________
mmusic mailing list
mmusic at ietf.org
http://www.ietf.org/mailman/listinfo/mmusic