Thanks!!

On Wed, Jun 3, 2015 at 5:39 PM, Brett Tate <br...@broadsoft.com> wrote:
> Hi,
>
> Based upon the shown message flow, the behavior appears to be incorrect.
> More specifically, it looks like UAC1 desired sendrecv within step 1.  If
> UAC1 still prefers sendrecv, it should have offered sendrecv within step
> 5.
>
> The following are a few RFC snippets.
>
> RFC 3261 section 14.2:
>
> "A UAS providing an offer in a 2xx (because the INVITE did not contain an
> offer) SHOULD construct the offer as if the UAS were making a brand new
> call, subject to the constraints of sending an offer that updates an
> existing session, as described in [13] in the case of SDP."
>
> RFC 6337 section 5.1:
>
> "A UA should send an offer that indicates what it, and its user, are
> interested in using/doing at that time, without regard for what the other
> party in the call may have indicated previously.  This is the case even
> when the offer is sent in response to an INVITE or re- INVITE that
> contains no offer.  (However, in the case of re-INVITE, the constraints of
> [RFC3261] and [RFC3264] must be observed.)"
>
> RFC 6337 section 5.3:
>
> "If a UA has occasion to send another offer in the session, without any
> desire to change the hold status (e.g., in response to a re- INVITE
> without an offer, or when sending a re-INVITE to refresh the session
> timer), it should follow the "General Principle for Constructing Offers
> and Answers" (Section 5.1).  If it previously initiated a "hold" by
> sending "a=sendonly" attribute or "a=inactive" attribute, then it should
> offer that again.  If it had not previously initiated "hold", then it
> should offer "a=sendrecv" attribute, even if it had previously been forced
> to answer something else.  Without this behavior it is possible to get
> "stuck on hold" in some cases, especially when a 3pcc is involved."
>
>
>> -----Original Message-----
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of isshed
>> Sent: Wednesday, June 03, 2015 3:14 AM
>> To: sip-implementors
>> Subject: [Sip-implementors] SDP attribute for hold and rersume
>>
>> Hi All,
>>
>> Below is the scenario..
>>
>>
> UAC1--------------------------------------------------------------------UA
> C2
>>
>> 1)---------------------INVITE (a=sendrecv)------------------------->
>> 2)<---------------------200-OK(a=recvpnly)-------------------------
>>
> 3)-------------------------------ACK--------------------------------------
>>
>>
>> 4)<---------------------INVITE (withoutsdp)-------------------------
>> 5)---------------------200-OK(a=sendonly)------------------------->
>> 6)<---------------------------ACK (a=inactive)-----------------------
>>
>> in step 4 UAC2 send INVITE without SDP and in 200-OK UAC1 is responding
> with
>> a=sendonly attribute. Question is if UAC1 is behavior is correct is not?
>>
>> if not, please suggest correct bahaviour.
>>
>> Thanks
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to