date:20181221

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Paul Kyzivat


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  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 

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 
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 

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

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Moy Amiga

Noted with thanks.




--
*Moisés Amiga*

*Voice Operations*

*Mex T.* + 52 (55) 5147 8040  ext 1367
*Cel.* +521 55 2575 6848
 Llámame 

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) 13:35, Roman Shpount (ro...@telurix.com)
escribió:

> 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.
>
> Regards,
> _
> Roman Shpount
>
>
> On Fri, Dec 21, 2018 at 2:23 PM Moy Amiga  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 
>>
>> 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 >> >
>>> 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 
>>> > wrote:
>>> > >
>>> > > > Hi.
>>> > > >
>>> > > > I Have a question.
>>> > > > When I have a already established call, and we send a Re-Invite, if
>>> > this
>>> > > > Re-Invite was

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Roman Shpount

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.

Regards,
_
Roman Shpount


On Fri, Dec 21, 2018 at 2:23 PM Moy Amiga  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 
>
> 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 
>> 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 
>> > 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
>> > > >
>> > >

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Moy Amiga

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 

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 
> 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 
> > 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

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Roman Shpount

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

:)
_
Roman Shpount


On Fri, Dec 21, 2018 at 1:31 PM Alex Balashov 
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 
> 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

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Alex Balashov

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  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

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Roman Shpount

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  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

[Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

2018-12-21 Thread Moy Amiga

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

Re: [Sip-implementors] Question on Offer/Answer Model with SIP

2018-12-21 Thread Paul Kyzivat

On 12/21/18 12:27 AM, Amarnath Kanchivanam wrote:

Thanks Paul, yes it helps.
I have one more question - What should be the SDP answer for empty 
Re-Invite (without SDP) in hold and non hold scenario?

The SDP in the response to a INVITE/reINVITE is an *offer*, not an *answer*.

As I noted before, it doesn't really matter whether it is a hold or 
non-hold case. The one sending the offer should offer what *it* wants at 
that time, without regard to what it might guess that the other end 
might want. The other end can deal with its desires in the answer.

To cover some common cases,

1) assume that Alice and Bob are in a call and Alice put the call on hold:

1a) if Bob receives an offerless reinvite, he most likely should put 
sendrecv in the offer he sends back. Note that it is valid but odd for 
Alice to send this, but it makes more sense if it was sent by a 
middlebox. (I presume Bob doesn't *want* hold, or he would already have 
sent another invite to indicate that.)

1b) if Alice receives an oferless reinvite, she will most likely want to 
put sendonly in the offer she sends back. (If she had changed her mind 
about wanting to be on hold she would have then sent a reinvite with an 
offer with sendrecv.

1c) Suppose Bob now also wants to put the call on hold. (Doesn't want to 
receive media from Alice.) He will send a reinvite with an offer to 
accomplish this. He may put either sendonly or inactive in that offer. 
Either way, assuming Alice still wants the call on hold she must put 
inactive in her answer.

1d) suppose in the initial invite of the call Alice had offered both 
audio and video, and Bob had accepted the audio and rejected the video. 
When Alice sends subsequent offers within the call she may well want to 
continue to offer video, just in case Bob has a change of heart and 
might accept it, though this might seem to be unlikely. This becomes 
more interesting when there is a middlebox in the call, such as a device 
managing 3pcc (third party call control). It is common for such a device 
to send an offerless invite to Alice when it wants to transfer the call 
from Bob to Charlie. In that case it may be that Charlie would accept 
the video.

But this needs to be tempered by the UI between Alice and her phone. It 
may be that she is no longer prepared for video in the call. Perhaps the 
video resource is being used for something else. So in the end this is 
an implementation choice.

There are similar issues regarding alternative codecs for the media. 
Ideally the offerer will include all supported codecs in every offer. 
But optimization of the implementation may result it in wanting to limit 
what it puts in subsequent offers, based on what is being used. Doing so 
can cause trouble in the 3pcc case.

Note that while I say that offers should reflect what the offerer wants 
without regard to what it thinks the answerer will want, there are some 
constraints on this documented in 3261 and 3265. For instance, if a 
payload type has been used earlier in the call for an rtp session then 
it can't be used for a *different* codec or codec configuration later in 
the session.

Thanks,
Paul

Regards,
Amarnath

On Wed, Dec 19, 2018 at 10:19 PM Paul Kyzivat > wrote:

Amarnath,

Take a look at RFC6337 for an in-depth treatment of offer/answer issues
and best practices. More below, consistent with what is in that rfc.

On 12/19/18 12:28 AM, Amarnath Kanchivanam wrote:
 > Hi,
 >
 > I have below call flow and would like to know the correct behavior.
 >
 > UAC                                          UAS
 > INVITE     ->
 >                              <---200 OK
 > Ack      -->
 >
 > Now UAS puts call on Hold
 >
 >                               <---Re-Invite with
send-only
 > attribute
 > 200 OK --> recv-only
 >                                 <--Ack
 >
 > Now UAS does Un-Hold
 >                                   <-Re-Invite*
without SDP*
 > 200 OK --> recv-only
 >

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

[Sip-implementors] Question if we reject a re-Invite with 404, we need to send a BYE message to end a call?

Re: [Sip-implementors] Question on Offer/Answer Model with SIP

9 matches

Site Navigation

Mail list logo

Footer information