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
