zivat; sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-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
&
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 f
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) wer
I want to make it inter-operable with Polycom's real presence desktop.
On Thu, Apr 17, 2014 at 6:43 PM, Paul Kyzivat 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 secured media as
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
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).
Thanks.
On Wed, Apr 16, 2014 at 7:54 PM, Paul Kyz
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 of
aurav Kumar; isshed; sip-implementors
Subject: Re: [Sip-implementors] SDP offer answer model
Hi,
If I recall correctly, there are MMUSIC RFCs (such as maybe RFC 6871) which can
potentially be used to clearly communicate to answerer that it prefers only
specific combinations of audio and video
sshed
> Cc: sip-implementors
> 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 a
age-
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
> 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
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
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 wrote:
> Hi All,
>
> I have 1 basic query regarding ofer-answer model
>
>
> Phone1 is sending the offer with 2
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 telephone-event/
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 wrote:
> On 10/23/13 6:23 AM, Brett Tate wrote:
> >> Also I w
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,
> 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 2xx.
Some aspects are likely discussed wi
Also I want to know what should be the answer in this case ?
On Wed, Oct 23, 2013 at 10:21 AM, isshed wrote:
> Thanks Brett!!
>
>
> On Tue, Oct 22, 2013 at 10:47 PM, Brett Tate wrote:
>
>> > Can there be an offer with as follows.
>> >
>> > v=0
>> > o=abc 940493389 1 IN IP4 10.10.10
Thanks Brett!!
On Tue, Oct 22, 2013 at 10:47 PM, Brett Tate 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 ha
I believe this is valid.
If accepted, you will have a signaling session, but no media.
That isn't terribly useful if it stays that way. But it might just be
transitional, with an intent to send an updated offer later.
But the caller is risking that the callee will simply refuse the call.
If ther
On 10/22/13 1:17 PM, Brett Tate 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 have any payload
>> format . Is this a
> 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 . Is this a validoffer?
No. It does not comply with RFC 4566 A
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 . Is this a valid offer?
what is the use case of this offer?
Thanks,
23 matches
Mail list logo
