Re: [MMUSIC] MSRP File transfer mechanism query

[Miguel Garcia <Miguel.Garcia at nsn.com>]

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