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] Appropriate back-off response for overly frequent registrations

[Philipp Schöning]

> There are a lot of good reasons of not using STUN but there are no good 
> reasons of not using STUN for UDP keep-alive. STUN keep-alive is extremely 
> easy to implement. It is possible to verify packet validity and it can be 
> used to detect local IP change.

Do you know any implementation (=product) which uses STUN for
keepalive but not for the actual SIP communication?
___
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]

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