[Sip-implementors] a=sendrecv or a=recvonly in SDP answer

[Elison Niven]

Hi,

If an offer contains an a=sendonly line and the answer does not contain any
a=___ line,
What does that imply? Does that mean the remote UA has not accepted the mode
request and is still using sendrecv mode?

RFC 4566,sec 6:
a=sendrecv

...
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the conference type
"broadcast" or "H332" (see below).

Does that mean the remote UA is still using the sendrecv mode?

Is it alright for a UA to expect the remote UA to send a=recvonly in the
answer to indicate acceptance of the mode when it sends a=sendonly in the
offer?

Look at this example from RFC4317:

3.2. Hold with Two Streams

In this example, two audio streams have been established in the first
offer/answer exchange. In this second offer/answer exchange, one of
the audio streams is placed on hold. Alice offers two media streams,
a bidirectional audio stream and a send-only telephone event stream.
Bob accepts both streams. Bob then puts Alice's audio stream on hold
but not the tone stream. Alice responds with identical SDP to the
initial offer.

[Offer]

v=0
o=alice 2890844526 2890844526 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

[Answer]

v=0
o=bob 2808844564 2808844564 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
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly

[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

[Elison Niven]

Hi,

It seems the answer is in RFC 3264. Sorry to not have referred it.

RFC3264: 6.1:

If a stream is offered as sendonly, the corresponding stream MUST be
marked as recvonly or inactive in the answer. If a media stream is
listed as recvonly in the offer, the answer MUST be marked as
sendonly or inactive in the answer. If an offered media stream is
listed as sendrecv (or if there is no direction attribute at the
media or session level, in which case the stream is sendrecv by
default), the corresponding stream in the answer MAY be marked as
sendonly, recvonly, sendrecv, or inactive. If an offered media
stream is listed as inactive, it MUST be marked as inactive in the
answer.

Regards,
Elison

[Elison Niven]

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

Post by Elison Niven
See that in the second offer, Bob sends an a=sendonly line to put Alice on

hold, but Alice does not send it.

Post by Elison Niven
Shouldn't Alice put an a=recvonly line in the answer to indicate the

acceptance of the mode? Or is she still

Post by Elison Niven
using a=sendrecv?

Regards,
Elison

[Rockson Li (zhengyli)]

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: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of
Elison Niven
Sent: Saturday, July 05, 2008 2:20 PM
To: sip-implementors at lists.cs.columbia.edu
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

Post by Elison Niven
See that in the second offer, Bob sends an a=sendonly line to put Alice on

hold, but Alice does not send it.

Post by Elison Niven
Shouldn't Alice put an a=recvonly line in the answer to indicate the

acceptance of the mode? Or is she still

Post by Elison Niven
using a=sendrecv?

Regards,
Elison

[Paul Kyzivat]

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

Post by Rockson Li (zhengyli)
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: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of
Elison Niven
Sent: Saturday, July 05, 2008 2:20 PM
To: sip-implementors at lists.cs.columbia.edu
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

Post by Elison Niven
See that in the second offer, Bob sends an a=sendonly line to put Alice on

hold, but Alice does not send it.

Post by Elison Niven
Shouldn't Alice put an a=recvonly line in the answer to indicate the

acceptance of the mode? Or is she still

Post by Elison Niven
using a=sendrecv?

Regards,
Elison
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors