On 11/3/11 1:10 PM, Brett Tate wrote:
> Howdy,
>
> RFC 6337 and 3GPP TS 24.610
> (http://www.3gpp.org/ftp/Specs/html-info/24610.htm) appear to be in conflict
> concerning resuming from hold. However, it may just be a poor interpretation
> of 3GPP TS 24.610 when a sendonly offer (from X) is answered with inactive
> (by Y).
>
> 3GPP TS 24.610 section 4.5.2.1 appears to indicate that X should offer
> recvonly instead of sendrecv when resuming. RFC 6337 section 5.3 explicitly
> indicates that X would offer sendrecv.
>
> Anyone know if discrepancy is intentional?
I don't know why 24.610 was written that way.
It will probably not cause problems most of the time - e.g. if its
interoperating with another UA following the same rules.
But there are other reasons for ending up at inactive, and this might
not work with those.
Fundamentally its silly to offer recvonly if you really want to send.
Thanks,
Paul
> Thanks,
> Brett
>
> -----
>
> RFC 6337:
>
> "Once in this state, to resume a two-way exchange of media, each side
> must reset its local hold status. If UA1 is first to go off hold, it
> will then send an offer with "a=sendrecv" attribute. The UA2 will
> respond with its desired state of "a=sendonly" attribute because that
> is a permitted response. When UA2 desires to also resume, it will
> send an offer with "a=sendrecv" attribute. In this case, because UA1
> has the same desire it will respond with "a=sendrecv" attribute. In
> the same case, when UA2 receives the offer with "a=sendrecv"
> attribute, if it has decided it wants to reset its local hold but has
> not yet signaled the intent, it may send "a=sendrecv" attribute in
> the answer."
>
> ------
>
> 3GPP TS 24.610:
>
> "If all the media streams that shall be resumed, the invoking UE shall
> generate a session level direction attribute, or separate media level
> direction attributes, in the SDP that is set to:
>
> - "recvonly" if the streams were previously inactive media streams; or
>
> - "sendrecv" if the streams were previously sendonly media streams, or the
> attribute may be omitted, since sendrecv is the default."
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
