Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-file-transfer-mech-07.txt

From: "Vikram Chhibber" <[email-masked]>
Date: Fri, 2 May 2008 13:14:08 +0530

Miguel, my only concern is that there are race-conditions between SIP
signaling and MSRP abort procedures which most likely could result in
491 invite response. These are likely to occur if we do not clarify
the behavior of the party receiving 413 MSPR respone or "#" character.

Thanks,
~Vikram

On Mon, Apr 28, 2008 at 4:00 PM,  <[email-masked]> wrote:
> Vikram:
>
>  Inline comments.
>
>
>  >-----Original Message-----
>  >From: [email-masked] [mailto:[email-masked]]
>  >On Behalf Of ext Vikram Chhibber
>  >Sent: 28 April 2008 09:00
>  >To: Jean-Francois Mule
>  >Cc: [email-masked]
>  >Subject: Re: [MMUSIC] WGLC on
>  >draft-ietf-mmusic-file-transfer-mech-07.txt
>  >
>  >There is one correction I see in section 8.4 "  A file
>  >receiver that wishes to abort an ongoing transfer first must
>  >   determine if the MSRP sender wishes to receive failure reports.  If
>  >   the current MSRP SEND request sets the Failure-Report header to a
>  >   value different than "no", then the file receiver generates an MSRP
>  >   413 response to the current MSRP SEND request (see Section 10.5 of
>  >   RFC 4975 [RFC4975]).  Then the file receiver SHOULD close the MSRP
>  >   session.  This is done by sending a new SDP offer that sets the port
>  >   number to zero in the related "m=" line that describes the file
>  >   transfer (see Section 8.2 of RFC 3264 [RFC3264]).  This SDP offer
>  >   MUST conform with the requirements expressed in Section 8.1.2.  The
>  >   'file-transfer-id' attribute MUST be the same that identifies the
>  >   ongoing transfer.  Then the file sender sends the SDP offer to the
>  >   file receiver."
>  >
>  >The last line should be: "Then the file sender sends the SDP
>  >answer to the file receiver."
>
>
>  No, no, it isn't like that. The whole paragraph is about creating an SDP
>  offer to abort a file. A file receiver creates the SDP offer and sends
>  to to the file sender, so, the last sentence should say "Then the file
>  receiver sends the SDP offer to the file sender".
>
>
>
>  >
>  >
>  >Also, what prevents the file sender to send re-INVITE with
>  >port 0 for file-transfer media description if it receives 413
>  >response? This may lead to crossing of re-INVITE requests
>  >resulting in 491 response. This can happen other way too when
>  >the sender aborts the file transfer, on receiving '#', the
>  >receiver can send re-INVITE with port 0. Do we emphasis that
>  >the "aborter" should only send re-INVITE?
>
>  Nothing prevents the file sender to send a re-INVITE at any time,
>  including the situation you describe.
>
>  But I think that the entity who aborts the file transfer should be
>  responsible for doing it at both the media and signaling level, but
>  nothing prevents for the other party to abort the signaling, once the
>  media has been aborted.
>
>  I'll take these comments into account when creating a new revision.
>
>  /Miguel
>
>
>
>
>  >
>  >
>  >
>  >On Wed, Apr 16, 2008 at 3:17 AM, Jean-Francois Mule
>  ><[email-masked]> wrote:
>  >> This is to announce a Working Group Last Call for comments on
>  >>  http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-07
>  >>
>  >>  Please provide your comments to the authors and the mmusic mailing
>  >> list  by April 30, 2008 (two weeks from today).
>  >>
>  >>  Thank you,
>  >>  Joerg and Jean-Francois.
>  >>
>  >>  _______________________________________________
>  >>  mmusic mailing list
>  >>  [email-masked]
>  >>  https://www.ietf.org/mailman/listinfo/mmusic
>  >>
>  >_______________________________________________
>  >mmusic mailing list
>  >[email-masked]
>  >https://www.ietf.org/mailman/listinfo/mmusic
>  >
>
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 07 May 2008 23:08:52 +0300

Hi Vikram:

Thanks for the comment.

We cannot avoid the race condition. If a UA receives a 491, then there 
are procedures in RFC 3261 to exit that condition.

Having said that, we can add some text to try to minimize the likelihood 
of occurrence of the race condition. I don't have this text in mind now, 
so, allow me a few days for it.

/Miguel

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