http://www.ietf.org/rfc/rfc3264.txt
7 Offerer Processing of the Answer When the offerer receives the answer, it MAY
send media on the accepted stream(s) (assuming it is listed as sendrecv or
recvonly in the answer). It MUST send using a media format listed in the
answer, and it SHOULD use the
-implementors] SDP offer answer model
http://www.ietf.org/rfc/rfc3264.txt
7 Offerer Processing of the Answer When the offerer receives the
answer, it MAY send media on the accepted stream(s) (assuming it is
listed as sendrecv or recvonly in the answer). It MUST send using a
media format listed
On 4/17/14 12:45 AM, isshed wrote:
Thanks Paul and everyone ...
I am designing Phone1 to use only one audio and one video. Phone1
supports secured media as well. so it is offering both secure/non
secure to phone2 and expects phone2 to select among the given m-lines
(RTP and SRTP).
And what is
I want to make it inter-operable with Polycom's real presence desktop.
On Thu, Apr 17, 2014 at 6:43 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote:
On 4/17/14 12:45 AM, isshed wrote:
Thanks Paul and everyone ...
I am designing Phone1 to use only one audio and one video. Phone1
supports
On 4/17/14 1:02 PM, isshed wrote:
I want to make it inter-operable with Polycom's real presence desktop.
Then, an unsatisfying as it is, it may be best to first find out what
Polycom supports in this regard.
From a standards perspective, SDP capability negotiation (RFC 5939 and
friends)
Hi All,
I have 1 basic query regarding ofer-answer model
Phone1 is sending the offer with 2 audio mlines and 2 video mline like
as follows.
m=audio 3342 RTP/SAVP 0 8 127
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:22
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:127
I think the first audio line and the first video line in the answer should
be taken as the negotiated codecs.
Thanks,
Mayank.
Mayank Kamthan
On Wed, Apr 16, 2014 at 12:21 PM, isshed isshed@gmail.com wrote:
Hi All,
I have 1 basic query regarding ofer-answer model
Phone1 is sending
I think this happens with codecs. The first one from each list would be the
selected and would be initially used unless re-offer or switch on the fly tales
place.
However in the case of m-lines (ie. multiple negotiated streams) I'm under the
impression that unless port is 0 in any of them then
Which m line should phone1 select to send and
receive audio and video.
From an offer/answer perspective, all of the m lines.
--
This email is intended solely for the person or entity to which it is
addressed and may contain confidential and/or privileged information. If
you are not the
-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Brett Tate
Sent: Wednesday, April 16, 2014 1:49 PM
To: isshed; sip-implementors
Subject: Re: [Sip-implementors] SDP offer answer model
Which m line should phone1 select
Subject: Re: [Sip-implementors] SDP offer answer model
Hi,
This Offer-Answer is use-case of supporting multiple m-line for SRTP.
The answerer does support SAVP (for media encryption).
Ideally, Answerer should keep the port zero for audio and video m-lines
with RTP/AVP and non-zero port
I read a number of the replies to this, but couldn't find an obvious
place to jump in, so I'm just replying here.
An offer multiple audio and/or video m-lines does not mean that they are
*alternatives*. Absent some explicit indication, there is no way to know
what the offerer's intent is in
Thanks Paul and Brett.
I have treated as a valid offer because the port is zero. Also, if all of
the m lines presents do not have PT list. then I rejected with 488.
Thanking you again!!
On Wed, Oct 23, 2013 at 8:03 PM, Paul Kyzivat pkyzi...@alum.mit.edu wrote:
On 10/23/13 6:23 AM, Brett Tate
Also I want to know what should be the answer in this case ?
On Wed, Oct 23, 2013 at 10:21 AM, isshed isshed@gmail.com wrote:
Thanks Brett!!
On Tue, Oct 22, 2013 at 10:47 PM, Brett Tate br...@broadsoft.com wrote:
Can there be an offer with as follows.
v=0
o=abc
On 10/23/13 6:23 AM, Brett Tate wrote:
Also I want to know what should be the answer in this case ?
Because the offer SDP is malformed, the device can basically act how it
wants. Similarly, I assume that the behavior might vary based upon if
received within INVITE, UPDATE, PRACK, 18x, or
Hi all,
Can there be an offer with as follows.
v=0
o=abc 940493389 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 0 RTP/AVP
Here m line does not have any payload format fmt. Is this a valid offer?
what is the use case of this offer?
Thanks,
Can there be an offer with as follows.
v=0
o=abc 940493389 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 0 RTP/AVP
Here m line does not have any payload
format fmt. Is this a validoffer?
No. It does not comply with RFC 4566 ABNF.
Thanks Brett!!
On Tue, Oct 22, 2013 at 10:47 PM, Brett Tate br...@broadsoft.com wrote:
Can there be an offer with as follows.
v=0
o=abc 940493389 1 IN IP4 10.10.10.10
s=-
c=IN IP4 10.10.10.10
t=0 0
m=audio 0 RTP/AVP
Here m line does not
18 matches
Mail list logo
