On 11/23/16 7:14 AM, Aman wrote:
Hi Experts,
We have a MGCP gateway responding 200 without any media attribute
('sendrecv' is the default) to the offer in the CRCX is sent with 'Mode:
inactive'.
*Call Agent Media Gateway*
CRCX(Mode: inactive) ----------->
<---------------------200(no, a=inactive)
SDP offer answer/answer RFC3264, 5.1 Unicast Streams
If the offerer wishes to only send media on a stream to its peer, it
MUST mark the stream as sendonly with the "a=sendonly" attribute. We
refer to a stream as being marked with a certain direction if a
direction attribute was present as either a media stream attribute or
Rosenberg & Schulzrinne Standards Track [Page 5]
RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
a session attribute. If the offerer wishes to only receive media
from its peer, it MUST mark the stream as recvonly. If the offerer
wishes to communicate, but wishes to neither send nor receive media
at this time, it MUST mark the stream with an "a=inactive" attribute.
The inactive direction attribute is specified in RFC 3108 [3]. Note
that in the case of the Real Time Transport Protocol (RTP) [4], RTCP
is still sent and received for sendonly, recvonly, and inactive
streams. That is, the directionality of the media stream has no
impact on the RTCP usage. If the offerer wishes to both send and
receive media with its peer, it MAY include an "a=sendrecv"
attribute, or it MAY omit it, since sendrecv is the default.
...
A typical usage example for multiple media streams of the same type
is a pre-paid calling card application, where the user can press and
hold the pound ("#") key at any time during a call to hangup and make
a new call on the same card. This requires media from the user to
two destinations - the remote gateway, and the DTMF processing
application which looks for the pound. This could be accomplished
with two media streams, one sendrecv to the gateway, and the other
sendonly (from the perspective of the user) to the DTMF application.
Once the offerer has sent the offer, it MUST be prepared to receive
media for any recvonly streams described by that offer. It MUST be
prepared to send and receive media for any sendrecv streams in the
offer, and send media for any sendonly streams in the offer (of
course, it cannot actually send until the peer provides an answer
with the needed address and port information). In the case of RTP,
even though it may receive media before the answer arrives, it will
not be able to send RTCP receiver reports until the answer arrives.
If my RFC understanding is correct on this, MG should must send the answer
in MGCP 200 with 'a=inactive' and with the above behavior its violating the
SDP offer/ answer RFC.
Yes, if the offer contains a=inactive then the answer MUST also contain
a=inactive (or port=0). Behavior when it does not is undefined. If you
are the one sending the offer, then I suggest you just proceed as if the
answer had a=inactive. (You have nothing to lose by doing so.)
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
