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

[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 on Offer/Answer Model with SIP

[Amarnath Kanchivanam]

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?

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
> >
> As already noted, the offerless reinvite doesn't indicate a desire to go
> off hold. Nor does it indicate a desire to stay on hold. Rather, it asks
> the other side to indicate its preference at this time.
>
> The subsequent offer of recvonly is however probably at least an unwise
> choice for the left UA. It wasn't the end that initiated the hold, and
> so *presumably* it would prefer to *not* be on hold. Assuming that is
> the case, it should have send an offer with sendrecv. If it had done
> that, then the UA on the right would have been able to choose to answer
> sendrecv if it wanted to be off hold, or sendonly if it wanted to remain
> on hold.
>
> In general, when sending a subsequent *offer* in a session a UA should
> reflect its own needs and refrain from inferring what it thinks the
> other end wants.
>
> > In final Ack there is no SDP attribute (sendrecv or send-only).
>
> This is *wrong*. Since there is no attribute indicating a preference,
> the default is sendrecv. And sendrecv is not permitted as an answer in
> response to recvonly. Rather, it must respond with either sendonly or
> inactive.
>
> > With this
> > call flow UAC failed to Un-Hold and continue to be on hold operation.
>
> This reflects screwups by both ends.
>
> > I would like you to share your comments which would help to understand
> the
> > correct behavior.
>
> I hope this helps.
>
> Thanks,
> Paul
> ___
> 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 on Offer/Answer Model with SIP

[Paul Kyzivat]

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 on Offer/Answer Model with SIP

[Richard Phernambucq]

You can find an example for Call Hold in RFC5359 chapter 2.1.
To take a call off hold the UA has to send a message with attribute 
a=sendrecv. In message F16 this attribute is omitted, so the default 
value of sendrecv is assumed (RFC4566 chapter 6).


If the offer contains a=recvonly, as in your example of the Re-Invite 
without SDP, the answer must contain a=sendonly or a=inactive. This is 
described in RFC3264 chapter 6.1. Sending a=sendrecv in the answer is 
against protocol and will most likely not have the other UA start 
sending a media stream.


Best regards,
Richard

On 19-12-2018 12:25, Amarnath Kanchivanam wrote:

Thanks All for your response.
I did try to send Ack with "sendrecv" attribute, but still it doesn't 
work.

Do we have any RFC describing call flow for various scenarios?

Regards,
Amarnath

On Wed, Dec 19, 2018 at 2:08 PM Olle E. Johansson > wrote:




> On 19 Dec 2018, at 09:28, Richard Phernambucq
mailto:r.phernamb...@cuperus.nl>> wrote:
>
> Hi Amarnath,
>
> A Re-Invite without SDP is called a late offer and isn't the
same as resuming a call that was placed on hold.
>
> If 'UAS' wanted to resume the call it should have sent an SDP
body with sendrecv attribute.
I don’t agree. The UA sending re-invite without SDP is asking the
other side “what is your
opinion on the state right now.”

Hold is a state that can exist separately on both sides, it
doesn’t really apply to the call.

/O
>
> Best regards,
> Richard
>
>
> On 19-12-2018 06:28, 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
>>                               >
>> In final Ack there is no SDP attribute (sendrecv or send-only).
With this
>> call flow UAC failed to Un-Hold and continue to be on hold
operation.
>> I would like you to share your comments which would help to
understand the
>> correct behavior.
>>
>> Regards,
>> Amarnath
>> ___
>> 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

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

[Amarnath Kanchivanam]

Thanks All for your response.
I did try to send Ack with "sendrecv" attribute, but still it doesn't work.
Do we have any RFC describing call flow for various scenarios?

Regards,
Amarnath

On Wed, Dec 19, 2018 at 2:08 PM Olle E. Johansson  wrote:

>
>
> > On 19 Dec 2018, at 09:28, Richard Phernambucq 
> wrote:
> >
> > Hi Amarnath,
> >
> > A Re-Invite without SDP is called a late offer and isn't the same as
> resuming a call that was placed on hold.
> >
> > If 'UAS' wanted to resume the call it should have sent an SDP body with
> sendrecv attribute.
> I don’t agree. The UA sending re-invite without SDP is asking the other
> side “what is your
> opinion on the state right now.”
>
> Hold is a state that can exist separately on both sides, it doesn’t really
> apply to the call.
>
> /O
> >
> > Best regards,
> > Richard
> >
> >
> > On 19-12-2018 06:28, 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
> >>    >>
> >> In final Ack there is no SDP attribute (sendrecv or send-only). With
> this
> >> call flow UAC failed to Un-Hold and continue to be on hold operation.
> >> I would like you to share your comments which would help to understand
> the
> >> correct behavior.
> >>
> >> Regards,
> >> Amarnath
> >> ___
> >> 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

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

[Olle E. Johansson]

> On 19 Dec 2018, at 09:28, Richard Phernambucq  
> wrote:
> 
> Hi Amarnath,
> 
> A Re-Invite without SDP is called a late offer and isn't the same as resuming 
> a call that was placed on hold.
> 
> If 'UAS' wanted to resume the call it should have sent an SDP body with 
> sendrecv attribute.
I don’t agree. The UA sending re-invite without SDP is asking the other side 
“what is your
opinion on the state right now.”

Hold is a state that can exist separately on both sides, it doesn’t really 
apply to the call.

/O
> 
> Best regards,
> Richard
> 
> 
> On 19-12-2018 06:28, 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
>>   > 
>> In final Ack there is no SDP attribute (sendrecv or send-only). With this
>> call flow UAC failed to Un-Hold and continue to be on hold operation.
>> I would like you to share your comments which would help to understand the
>> correct behavior.
>> 
>> Regards,
>> Amarnath
>> ___
>> 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 on Offer/Answer Model with SIP

[Richard Phernambucq]

Hi Amarnath,

A Re-Invite without SDP is called a late offer and isn't the same as 
resuming a call that was placed on hold.


If 'UAS' wanted to resume the call it should have sent an SDP body with 
sendrecv attribute.


Best regards,
Richard


On 19-12-2018 06:28, 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
   

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

[Amarnath Kanchivanam]

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