Looking back at RFC4317 I will agree that example 3.2 seems to be in
error. Certainly it is mistaken for alice to respond to the second offer
without recvonly or inactive for the first stream.
I would also say that it was at least unwise for bob to offer recvonly
rather than sendrecv for the second stream. There are insufficient
details to say this for certain, because we don't know of bob's device
is *capable* of sending telephone events. But absent his own reason to
require readonly, it would make more sense for him to offer sendrecv for
the second stream and let alice reduce it to sendonly if that is what
she needs.
However this is all a bit tangential to the current discussion.
Thanks,
Paul
Rockson Li (zhengyli) wrote:
> I am a little bit confused here,
>
> Two guys raised the same question before, unfortunately no any replies.
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg03148.html
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg03416.html
>
> FYI
>
> Regards,
> -Rockson
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Elison Niven
> Sent: Saturday, July 05, 2008 2:20 PM
> To: [email protected]
> Subject: Re: [Sip-implementors] a=sendrecv or a=recvonly in SDP answer
>
> Hi,
>
> Regarding my previous post then, isn't this example from RFC4317 section
> 3.2 clearly violating RFC3264 section 6.1?
>
> [Second-Offer]
>
> v=0
> o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
> s=
> c=IN IP4 host.biloxi.example.com
> t=0 0
> m=audio 49172 RTP/AVP 97
> a=rtpmap:97 iLBC/8000
> a=sendonly
> m=audio 49174 RTP/AVP 98
> a=rtpmap:98 telephone-event/8000
> a=recvonly
>
> [Second-Answer]
>
> v=0
> o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
> s=
> c=IN IP4 host.atlanta.example.com
> t=0 0
> m=audio 49170 RTP/AVP 0 97
> a=rtpmap:0 PCMU/8000
> a=rtpmap:97 iLBC/8000
> m=audio 49172 RTP/AVP 98
> a=rtpmap:98 telephone-event/8000
> a=sendonly
>
>
>> See that in the second offer, Bob sends an a=sendonly line to put
>> Alice on
> hold, but Alice does not send it.
>> Shouldn't Alice put an a=recvonly line in the answer to indicate the
> acceptance of the mode? Or is she still
>> using a=sendrecv?
>
> Regards,
> Elison
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
