Agreed, 487 is the best choice. I would also opine that SIP 491 should not
be a choice for this particular scenario where the intent is to tear down
the call. SIP 491 Request Pending means the other side should wait a random
amount of time to retry the reINVITE. Since the intent is to tear down the
> From: Leo Leo [lafa...@yahoo.com.br]
>
> There is something missing here, please explain it to me.
>
> If BYE only ends the dialog, what does the UA must to do with any
> other transaction within that dialog? As far as I know, the
> transactions within a dialog ara attached its existence.
Tran
>>> Interesting, never thought about it. So, if I send a re-INVITE for
>>> which I have no final reply yet and then I send a BYE, should the UAS
>>> reply 200 for the BYE and terminate the remaining re-INVITE
>>> transasction without sending a final response?
>
>>> Or should the UAS reply a "491 Re
unnecessarily.
>
> If I was not so clear, I meant "As the BYE terminates all transactions, " as
> "As the BYE terminates all transactions of the associated established dialog".
>
> Thanks.
>
>
> Leonardo
>
>
>
> De: Paul Kyzivat
> Para: sip-impl
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Leo Leo
Sent: Wednesday, August 03, 2011 2:57 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] BYE before call answer
Hi
rs@lists.cs.columbia.edu
Enviadas: Quarta-feira, 3 de Agosto de 2011 14:37
Assunto: Re: [Sip-implementors] BYE before call answer
On 7/27/11 8:29 AM, Leo Leo wrote:
>>> Interesting, never thought about it. So, if I send a re-INVITE for
>>> which I have no final reply yet and th
2011/8/3 Brett Tate :
> For reference, RFC 3261 section 15.1.2 recommends sending 487.
>
> "The UAS MUST still respond to any pending requests received for that
> dialog. It is RECOMMENDED that a 487 (Request Terminated) response
> be generated to those pending requests."
Thanks.
--
Iñaki
On 8/3/11 1:48 PM, Iñaki Baz Castillo wrote:
> 2011/8/3 Paul Kyzivat:
>> They BYE does *not* "terminate all transactions"!
>> Every transaction must follow its own state machine, independent of any
>> other transaction.
>>
>> You MUST attempt to send some final response to any outstanding
>> transa
-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
> Castillo
> Sent: Wednesday, August 03, 2011 1:48 PM
> To: Paul Kyzivat
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-im
2011/8/3 Paul Kyzivat :
> They BYE does *not* "terminate all transactions"!
> Every transaction must follow its own state machine, independent of any
> other transaction.
>
> You MUST attempt to send some final response to any outstanding
> transactions even if a BYE transaction has been completed.
nsaction has been completed.
The BYE only ends the Invite-dialog-usage.
Thanks,
Paul
> Leonardo
>
>
>
> De: Iñaki Baz Castillo
> Para: Leo Leo
> Cc:
> "sip-implementors@lists.cs.columbia.edu"
> Enviadas: Quarta
2011/8/2 Kevin P. Fleming :
> On 08/02/2011 07:11 AM, Bob Penfield wrote:
>> Text with normative language (i.e. MUST, SHOULD, RECOMMENED, etc. from RFC
>> 2119) always takes precedence. Therefore the "MUST" in section 12.1.1
>> applies when the 1xx creates a dialog. Table 2 should have "c" for Co
On 08/02/2011 07:11 AM, Bob Penfield wrote:
> Text with normative language (i.e. MUST, SHOULD, RECOMMENED, etc. from RFC
> 2119) always takes precedence. Therefore the "MUST" in section 12.1.1 applies
> when the 1xx creates a dialog. Table 2 should have "c" for Contact in 1XX
> responses. Maybe
2011/8/2 Bob Penfield :
> Text with normative language (i.e. MUST, SHOULD, RECOMMENED, etc. from RFC
> 2119) always takes precedence. Therefore the "MUST" in section 12.1.1 applies
> when the 1xx creates a dialog. Table 2 should have "c" for Contact in 1XX
> responses. Maybe we should file an er
te
Subject: Re: [Sip-implementors] BYE before call answer
2011/8/2 Romel Khan :
> By the way, we are seeing cases where BYE being used terminating early
> dialog without requiring reliable 1XX handling (ie no 100rel option, no
> PRACK) in production environment.
But that is just possible in case
2011/8/2 Romel Khan :
> By the way, we are seeing cases where BYE being used terminating early
> dialog without requiring reliable 1XX handling (ie no 100rel option, no
> PRACK) in production environment.
But that is just possible in case the 1XX contains Contact and
mirrored Record-Route, somethi
By the way, we are seeing cases where BYE being used terminating early
dialog without requiring reliable 1XX handling (ie no 100rel option, no
PRACK) in production environment.
On Wed, Jul 27, 2011 at 1:01 PM, Iñaki Baz Castillo wrote:
> 2011/7/27 Brett Tate :
> > The following are two rfc3261
2011/7/27 Brett Tate :
> The following are two rfc3261 snippets which indicate that the Contact is
> mandatory for dialog creating 18x responses.
>
> Section 12.1: "Dialogs are created through the generation of non-failure
> responses to requests with specific methods. Within this specification,
der field to the response."
From: Iñaki Baz Castillo [i...@aliax.net]
Sent: Wednesday, July 27, 2011 10:27 AM
To: Brett Tate
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] BYE before call answer
2011/7/27 Brett Tate :
> Concerning the lack of Contact within
2011/7/27 Brett Tate :
> Concerning the lack of Contact within a dialog created by an INVITE 18x with
> To tag, it means that the UAS is non compliant to RFC 3261.
I don't agree. RFC 3261 states that Contact MUST be present in
*reliable* responses (not final I mean), and RFC 3261 just defines 2XX
: Tuesday, July 26, 2011 5:50 PM
To: Brett Tate
Cc: Pavesi, Valdemar (NSN - US/Irving); sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] BYE before call answer
2011/7/26 Brett Tate :
> If your are still talking about early dialogs, the early dialog was created
> by receiving
2011/7/27 Leo Leo :
>>>Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow
>>>section 14.2 in RFC 3261 just indicates that 491 is useful when there
>>>is a pending re-INVITE from A to B and B sends a re-INVITE to A. In
>>>that case A should reply 491.
> A re-INVITE must not be fork
Para: Leo Leo
Cc: "sip-implementors@lists.cs.columbia.edu"
Enviadas: Quarta-feira, 27 de Julho de 2011 9:03
Assunto: Re: [Sip-implementors] BYE before call answer
2011/7/27 Leo Leo :
> Anyway, the RFC says that a receiving BYE must to finish all transactions of
> the associated d
2011/7/27 Leo Leo :
> Anyway, the RFC says that a receiving BYE must to finish all transactions of
> the associated dialog.
Interesting, never thought about it. So, if I send a re-INVITE for
which I have no final reply yet and then I send a BYE, should the UAS
reply 200 for the BYE and terminate
hich
requires this behaviour.
Leonardo
De: Iñaki Baz Castillo
Para: Leo Leo
Cc: "sip-implementors@lists.cs.columbia.edu"
Enviadas: Terça-feira, 26 de Julho de 2011 10:03
Assunto: Re: [Sip-implementors] BYE before call answer
2011/7/26 Leo Leo :
2011/7/26 Brett Tate :
> If your are still talking about early dialogs, the early dialog was created
> by receiving a 18x with To tag. The caller can send BYE over an early dialog.
If the 180 has no Contact header (and possibly it does not mirror the
Record-Route headers added by proxies) how wo
bia.edu
Subject: Re: [Sip-implementors] BYE before call answer
"
15.1 Terminating a Session with a BYE Request
15.1.1 UAC Behavior
A BYE request is constructed as would any other request within a
dialog, as described in Section 12 "
If there are no DIALOG how we can build th
From: ext Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Tuesday, July 26, 2011 5:36 AM
To: Pavesi, Valdemar (NSN - US/Irving)
Cc: ext Romel Khan; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] BYE before call answer
2011/7/25 Pavesi, Valdemar (NSN - US/Irving) :
> BYE
2011/7/26 Leo Leo :
> But, as you assure correctly, the BYE may be used in this case, as writen in
> RFC, section 15:
>
> "The BYE request is used to terminate a specific session or attempted
> session. In this case, the specific session is the one with the peer UA on
> the other side of the dia
8:55
Assunto: Re: [Sip-implementors] BYE before call answer
2011/7/26 Leo Leo :
> This makes no sense to me:
>
>
>
> Wrong. BYE can be used to terminate a *specific* dialog (answered or
> not answered yet).
>
> Because...
>
>
> RFC 3261
>
> From section 9
2011/7/26 Leo Leo :
> This makes no sense to me:
>
>
>
> Wrong. BYE can be used to terminate a *specific* dialog (answered or
> not answered yet).
>
> Because...
>
>
> RFC 3261
>
> From section 9.1:
> If the original
> request has generated a final response, the CANCEL SHOULD NOT be
> sent, as it i
response or send an 2XX response followed by an BYE.
Leonardo
De: Iñaki Baz Castillo
Para: "Pavesi, Valdemar (NSN - US/Irving)"
Cc: sip-implementors@lists.cs.columbia.edu
Enviadas: Terça-feira, 26 de Julho de 2011 7:36
Assunto: Re: [Sip-impleme
2011/7/25 Pavesi, Valdemar (NSN - US/Irving) :
> BYE must be used to terminated the calls after answer.
Wrong. BYE can be used to terminate a *specific* dialog (answered or
not answered yet).
--
Iñaki Baz Castillo
___
Sip-implementors mailing lis
is sent.
cheers,
(-:bob
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Romel Khan
Sent: Monday, July 25, 2011 2:01 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] BYE
-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Romel Khan
[romel.k...@idt.net]
Sent: Monday, July 25, 2011 2:01 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] BYE before call answer
RFC3261, sec 15 : "Typically, when the user hangs up, it indicates a desi
, July 25, 2011 1:01 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] BYE before call answer
RFC3261, sec 15 : "Typically, when the user hangs up, it indicates a
desire
to
terminate the attempt to establish a session, and to terminate any
sessions al
RFC3261, sec 15 : "Typically, when the user hangs up, it indicates a desire
to
terminate the attempt to establish a session, and to terminate any
sessions already created. For the caller's UA, this would imply a
CANCEL request if the initial INVITE has not generated a final
37 matches
Mail list logo
