Subject: RE: [Sipping] BYE generation from the Invited party

From: [email-masked]
Date: Mon, 11 Mar 2002 16:11:07 +0200

If you want to end a call before you have received a final response, you send a CANCEL.

Anyway, to answer your specific question: No, you have to ACK the final response to an INVITE, then send a BYE. Otherwise, the INVITE transaction state machine is hung.

Regards,
Hisham

> -----Original Message-----
> From: ext Arunachalam Venkatraman [mailto:[email-masked]]
> Sent: Monday, March 11, 2002 4:04 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] BYE generation from the Invited party
> 
> 
> Hisham
> The discussion is about BYE from the UAS. So, CANCEL is not 
> relevant here.
> Venkat
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, March 11, 2002 2:02 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] BYE generation from the Invited party
> 
> 
> 
> 
> > -----Original Message-----
> > From: ext Arunachalam Venkatraman [mailto:[email-masked]]
> > Sent: Saturday, March 09, 2002 1:13 AM
> > To: Jonathan Rosenberg; Michael Hammer
> > Cc: [email-masked]
> > Subject: RE: [Sipping] BYE generation from the Invited party
> > 
> > 
> > 
> > The reason the BYE will be rejected by the UAC is that the To 
> > tag of the UAS
> > is established at the UAC only on receipt of the 200.
> > 
> > Question: What happens when a provisional response is sent 
> > reliably? In this
> > case, the To tag is sent in the 1xx and responded to in the 
> > PRACK. In this
> > case, the BYE can be sent as soon as the final response has 
> been sent,
> > right?
> 
> No, in this case, you send a CANCEL.
> 
> Regards,
> Hisham
> 
> 
> > 
> > I am not advocating prescribing one-off exceptions but just curious.
> > 
> > Venkat
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of
> > Jonathan Rosenberg
> > Sent: Friday, March 08, 2002 1:14 PM
> > To: Michael Hammer
> > Cc: [email-masked]
> > Subject: Re: [Sipping] BYE generation from the Invited party
> > 
> > 
> > 
> > 
> > Michael Hammer wrote:
> > >
> > > This question came up at ITU SG11 meeting in February 
> related to the
> > > mapping of ISUP/BICC and SIP messages:
> > >
> > > (extraneous messages removed)
> > >
> > > A and B are interworking gateways
> > >
> > > A sends an INVITE to B
> > > ...
> > > B responds with a 200 OK to the INVITE
> > >
> > > but B then receives a Release from the destination party.
> > >
> > > Can B immediately send a BYE to A or should it wait for the 
> > ACK from A
> > > to
> > > complete the dialog, then send BYE?
> > 
> > It must wait for the ACK. From section 15 of bis:
> > 
> > However, the callee's UA MUST NOT send a BYE on a confirmed 
> > dialog until
> > it has received an ACK for its 2xx response or until the 2367
> > server transaction times out. 2368
> > 
> > 
> > 
> > > Or, does B consider the dialog
> > > completely established upon sending of the 200 OK?
> > >
> > >  From the Inviting-side perspective, assuming the 200 OK to 
> > INVITE got
> > > lost, would receipt of the BYE at A (before the 200 OK or 
> > before sending
> > > of
> > > ACK) cause it any problems?
> > 
> > The BYE would be rejected as not part of any dialog; that 
> its why you
> > wait for ACK.
> > 
> > -Jonathan R.
> > 
> > --
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > [email-masked]                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Mon, 11 Mar 2002 08:45:29 -0600

Hisham
I understand that the BYE should be sent by the UAS after the ACK is
received .
I am clarifying the resoning behind it and pointing out one instance where
it is not really required to wait for the ACK, assuming my reasoning is
correct.
Regards,
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, March 11, 2002 8:11 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] BYE generation from the Invited party

If you want to end a call before you have received a final response, you
send a CANCEL.

Anyway, to answer your specific question: No, you have to ACK the final
response to an INVITE, then send a BYE. Otherwise, the INVITE transaction
state machine is hung.

Regards,
Hisham

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Mar 2002 20:10:54 +0200

Hi,

You should always wait for the ACK. Otherwise, even if there was an
existing early dialog, you would have a race condition. What happens if
the BYE reaches the UAC before the 200 OK for the INVITE? you would have
a 200 OK arriving for an already terminated dialog.

We do not want to define all these strange state machine transitions.
That's why it is forbidden.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]