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,
---------
>
> Message: 1
> Date: Wed, 3 Nov 2010 12:28:04 +0530
> From: Ayyanar P K
> Subject: Re: [Sip-implementors] SDP Offer ANswer
> To: Alok 2 Tiwari , "AGRAWAL, VINEET
>(VINEET)"
> as per 3262 :
>
> If the INVITE contained an offer, the UAS MAY generate an answer in a
>reliable provisional response (assuming these are supported by the
>UAC).
>
>
>> Best Regards,
Vishnu Yadav
___
Sip-implementors mailing list
Sip-implement
I *think* you have gotten a valid response from other respondents, but
I'm not certain about the question. You say the terminating party
supports 100rel, but does the originating party indicate support for
100rel? That is a necessity to use reliable provisionals.
The thing you want to read is d
.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> AGRAWAL, VINEET (VINEET)
> Sent: Wednesday, November 03, 2010 11:45 AM
> To: Tarun2 Gupta
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] SDP Offer ANswer
>
> Ple
Satan [mailto:sip.sa...@gmail.com]
> Sent: Wednesday, November 03, 2010 11:36 AM
> To: Tarun2 Gupta
> Cc: AGRAWAL, VINEET (VINEET); sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] SDP Offer ANswer
>
> Is that a must? 1xx Reliable still can carry NO SDP, and
a.edu
Subject: Re: [Sip-implementors] SDP Offer ANswer
Refer RFC-3261, section-13.2.1:
"If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE."
In your scenario, since Terminating SIP does not
2 Gupta
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP Offer ANswer
Please clarify other doubts.
In SIP terminating scenario, Terminating SIP does not support 100 Rel and
preconditions.
Should it necessary that 200OK must contain SDP, while we have send SDP answ
AL, VINEET (VINEET); sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP Offer ANswer
Is that a must? 1xx Reliable still can carry NO SDP, and answer can
be sent in 2xx subsequantly.
On Wed, Nov 3, 2010 at 11:22 AM, Tarun2 Gupta wrote:
> Hi
>
> The an
Sent: Wednesday, November 03, 2010 11:36 AM
To: Tarun2 Gupta
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP Offer ANswer
Is that a must? 1xx Reliable still can carry NO SDP, and answer can
be sent in 2xx subsequantly.
On Wed, Nov 3, 2010 at 11:22 AM, Tarun2
...@gmail.com]
Sent: Wednesday, November 03, 2010 11:36 AM
To: Tarun2 Gupta
Cc: AGRAWAL, VINEET (VINEET); sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP Offer ANswer
Is that a must? 1xx Reliable still can carry NO SDP, and answer can
be sent in 2xx subsequantly.
On Wed
Tarun Gupta
> ARICENT
>
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of AGRAWAL,
> VINEET (VINEET)
> Sent: Wednesday, November 03, 2010 11:19 AM
> To: sip-implementors@lists.c
: Wednesday, November 03, 2010 11:19 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SDP Offer ANswer
Hi,
Can any one please clarify, if 100 rel support on the terminating SIP party
then the SDP answer of SDP offer received in INVITE must be in 183 Session
progress .
If
Hi,
Can any one please clarify, if 100 rel support on the terminating SIP party
then the SDP answer of SDP offer received in INVITE must be in 183 Session
progress .
If I send SDP answer in 180 Ringing in spite of 183. is it ok according to rfc
3264.
Please clarify the doubts.
Regards,
Vinee
ts.cs.columbia.edu] On Behalf Of Michael
Hirschbichler
Sent: Tuesday, May 04, 2010 8:59 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SDP offer-answer - problem
Hi all,
we are facing the following problem with components of two different
manufactorer and we are now wond
Yes, this is legal.
From 3264:
In the case of RTP, if a particular codec was referenced with a
specific payload type number in the offer, that same payload type
number SHOULD be used for that codec in the answer. Even if the same
payload type number is used, the answer MUST cont
Hi all,
we are facing the following problem with components of two different
manufactorer and we are now wondering about the correct behaviour of the
components:
According to RFC 3725, Flow I, we have the following dialog:
A Controller
|(1) INVITE no SDP |
Đani Vladislavić wrote:
> Hi,
>
>
>
> could you help me ragarding the question marked with asterixes in
> attached file where call flow scenario is described. The questions are
> from MGCF point of view.
So I gather the MGCF is a B2BUA, right?
> 1st (*) Is it allowed to receive any SDP in 18
Hi,
could you help me ragarding the question marked with asterixes in
attached file where call flow scenario is described. The questions are
from MGCF point of view.
1st (*) Is it allowed to receive any SDP in 183 reliable provisional
response as described? shouldn't the call be released immed
PROTECTED] On Behalf Of Alejandro
Orellana
Sent: Friday, November 14, 2008 12:11 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SDP offer/answer question
All,
in the following call flow,
is it valid for endpoint A to send a ACK with SDP?
endpointA
or UPDATE and
not through ACK.
Regards
Anuradha Gupta
ARICENT
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alejandro
Orellana
Sent: Friday, November 14, 2008 12:11 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SDP offer
no, SDP isn't valid in that context
regards
abhishek
2008/11/14 Paul Kyzivat <[EMAIL PROTECTED]>
>
>
> Alejandro Orellana wrote:
> > All,
> > in the following call flow,
> > is it valid for endpoint A to send a ACK with SDP?
> >
> > endpointA
> GW
> > INVITE w/SDP (offer)---
Alejandro Orellana wrote:
> All,
> in the following call flow,
> is it valid for endpoint A to send a ACK with SDP?
>
> endpointAGW
> INVITE w/SDP (offer)-->
> <100 trying-
All,
in the following call flow,
is it valid for endpoint A to send a ACK with SDP?
endpointAGW
INVITE w/SDP (offer)-->
<100 trying---
IMO the appropriate way to treat session timer is that it simply
establishes a deadline for a session refresh and a responsibility for
doing it.
If no reinvite or update has been initiated when the deadline is
reached, then the designated UA is to initiate one. If there is need to
send a reinv
> Of course the refresher should always be prepared
> to receive a new SDP. What I was trying to establish
> is what can the UAC and UAS do to re-use a previous
> SDP (as RFC 4028 suggests) when the roles of the
> offer/answer dialog have been reversed since the
> last exchange.
RFC 4028 doe
Bram Verburg wrote:
> Of course the refresher should always be prepared to receive a new SDP.
> What I was trying to establish is what can the UAC and UAS do to re-use
> a previous SDP (as RFC 4028 suggests) when the roles of the offer/answer
> dialog have been reversed since the last exchange.
>
Of course the refresher should always be prepared to receive a new SDP.
What I was trying to establish is what can the UAC and UAS do to re-use
a previous SDP (as RFC 4028 suggests) when the roles of the offer/answer
dialog have been reversed since the last exchange.
For the refresher UAC to use i
There is nothing you can do when sending an offer that will guarantee
that the answer will be the same as the prior answer. For your offer you
may use the last SDP you sent, with an unchanged o-line, which at least
will mean that an answer the same as the prior will be valid. But it
does not im
If you preserve the previous value of o line of your SDP in the re-INVITE,
this indicates that the offer is not intended to change the session
parameters since the SDP version is same. In this case, the UAS should not
go through the processing of SDP ideally and you are free to put whatever
you lik
Vikram,
Agreed, for the most part. But...
> Once an offer answer completes, you are left with some
> state of session. You can not say that I have answer or
> offer now. There is nothing in the SDP that says that I
> am answer or offer. Therefore in case of session-timers,
> if the most recent an
Please see inline.
On Tue, Sep 9, 2008 at 2:19 PM, Bram Verburg <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>
> RFC 4038 says a session refresh that uses INVITE should include a copy
> of the most recent SDP offer. The UAS can tell from the o-line that
> nothing has changed and respond with a copy of it
Hi,
RFC 4038 says a session refresh that uses INVITE should include a copy
of the most recent SDP offer. The UAS can tell from the o-line that
nothing has changed and respond with a copy of its original answer. This
allows for session refresh without going through the trouble of
re-negotiation
55 matches
Mail list logo
