On 12/21/18 2:34 PM, Roman Shpount wrote:
RFC  5057 is informational, not a standard. RFC 3261 specifies that dialog
established using an INVITE transaction can only be terminated using a BYE
message.

Specifically in https://tools.ietf.org/html/rfc3261#section-12.2.1.2:

If the response for a request within a dialog is a 481 (Call/Transaction
Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the
dialog.  A UAC SHOULD also terminate a dialog if no response at all is
received for the request (the client transaction would inform the TU about
the timeout.)

       For INVITE initiated dialogs, terminating the dialog consists of
sending a BYE.


This does not specify what happens when re-INVITE gets a 404 response,
since this is not something that should normally happen for the request
with the dialog. Getting 404 to a re-INVITE means something went horribly
wrong and terminating dialog by sending BYE is probably the right course of
action.

+1

There is a pretty good chance that you will also get a 404 response to the BYE, but you nevertheless need to send it.

        Thanks,
        Paul


Regards,
_____________
Roman Shpount


On Fri, Dec 21, 2018 at 2:23 PM Moy Amiga <moises.am...@c3ntro.com> wrote:

Thank you Roman.

But about the RFC 5057,  https://tools.ietf.org/html/rfc5057#section-5.1
And I dont know if this RFC is for the NOTIFY only or also include a
INVITE message.


For the failure responses with code 400 and greater, there are three
    common ways the failure can affect the transaction, usage, and dialog
    state.

    Transaction Only  The error affects only the transaction, not the
       usage or dialog the transaction occurs in (beyond affecting the
       local CSeq).  Any other usage of the dialog is unaffected.  The
       error is a complaint about this transaction, not the usage or
       dialog that the transaction occurs in.

    Destroys Usage  The error destroys the usage, but not the dialog.
       Any other usages sharing this dialog are not affected.

    Destroys Dialog  The error destroys the dialog and all usages sharing
       it.

    Table 1 and Table 2 display how the various codes affect transaction,
    usage, or dialog state.  Response code specific comments or
    exceptions follow the table.

         +----------------------+----------------+-----------------+
         |   Transaction Only   | Destroys Usage | Destroys Dialog |
         +----------------------+----------------+-----------------+
         | 400 (or unknown 4xx) |    405, 480    |  404, 410, 416  |
         |  401, 402, 403, 406  |    481, 489    |     482, 483    |
         |   407, 408, 412-415  |       501      |     484, 485    |
         |  417, 420, 421, 422  |                |     502, 604    |
         |     423, 428, 429    |                |                 |
         |   436-438, 486, 487  |                |                 |
         |  488, 491, 493, 494  |                |                 |
         | 500 (or unknown 5xx) |                |                 |
         |     503, 504, 505    |                |                 |
         |       513, 580       |                |                 |
         | 600 (or unknown 6xx) |                |                 |
         |       603, 606       |                |                 |
         +----------------------+----------------+-----------------+






--
*Moisés Amiga*

*Voice Operations*

*Mex T.* + 52 (55) 5147 8040  ext 1367
*Cel.* +521 55 2575 6848
  Llámame <http://callmenow.c3ntro.com/c3ntro1...@c3ntro.bicentel.net>

Paseo de las Palmas 215-304
Col. Lomas de Chapultepec,
México D.F. 11000





El vie., 21 de dic. de 2018 a la(s) 12:52, Roman Shpount (
ro...@telurix.com) escribió:

Sorry, BYE message. I blame this on consistent fat-fingering.

:)
_____________
Roman Shpount


On Fri, Dec 21, 2018 at 1:31 PM Alex Balashov <abalas...@evaristesys.com>
wrote:

BUY message? What is this, Broadsoft? :-)

On Fri, Dec 21, 2018 at 01:29:26PM -0500, Roman Shpount wrote:

You will need to send the BUY message. 404 response only cancels the
re-INVITE transaction, not the call. This being said, most SIP
implementations will hang up the call (send BUY) when they receive 404
response to a re-INVITE.

Regards,
_____________
Roman Shpount


On Fri, Dec 21, 2018 at 12:54 PM Moy Amiga <moises.am...@c3ntro.com>
wrote:

Hi.

I Have a question.
When I have a already established call, and we send a Re-Invite, if
this
Re-Invite was rejected with 404.
To finish the call, we need a BYE message or only with this reject
404  the
session is considered canceled?

Thank you and best regards


--
*Moisés Amiga*

*Voice Operations*
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to