Thanks Paul for your valuable thoughts.
​Regard
s,
Aman
On Thu, Nov 24, 2016 at 12:37 AM, Paul Kyzivat <pkyzi...@alum.mit.edu>
wrote:
> 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
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
