From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Michael
Hirschbichler
Sent: 17 March 2010 09:20
Cc: SIPImplementors
Subject: Re: [Sip-implementors] Offer-answer question
So, the combination
client A sends:
INVITE
m= G726,
So, the combination
client A sends:
INVITE
m= G726, G729, G723, PCMA, PCMU
client B responses:
200OK
m= G729, PCMA
resulting in
AG729>B
A 2010
2010/3/12 Aneesh Naik :
> Hi Michael,
>
> This will not be allowed. A (UAC) has sent all the codecs it supports,
> and B (UAS) has respoded with the codecs it is willing to talk to A for this
> call. Only one codec will be negotiated for media transfer between A and B.
> In your example below,
lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Offer-answer question
>>
>> Thx,
>>
>> this is also my opinion.
>> To point it down: there is no way to use G726 in *any* direction
>> without
>> Re-INVITEs - is this correct?
>>
>
Michael
>> Hirschbichler
>> Sent: Friday, March 12, 2010 8:52 AM
>> Cc: sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Offer-answer question
>>
>> Thx,
>>
>> this is also my opinion.
>> To point it down: there is no
gt; Subject: Re: [Sip-implementors] Offer-answer question
>
> Thx,
>
> this is also my opinion.
> To point it down: there is no way to use G726 in *any* direction
> without
> Re-INVITEs - is this correct?
>
[Neel]
Since the offer contains G726, the endpoint A should b
Thx,
this is also my opinion.
To point it down: there is no way to use G726 in *any* direction without
Re-INVITEs - is this correct?
BR
Michael
Am 12.03.2010 15:48, schrieb Arunachala:
> Not entirely true. A& B can talk using both G729 and PCMA. Either one
> can switch between these two codecs
Not entirely true. A & B can talk using both G729 and PCMA. Either one
can switch between these two codecs without the use of a reINVITE.
-Arun
On Fri, Mar 12, 2010 at 7:34 PM, Aneesh Naik wrote:
> Hi Michael,
>
> This will not be allowed. A (UAC) has sent all the codecs it supports,
> and
Hi Michael,
This will not be allowed. A (UAC) has sent all the codecs it supports,
and B (UAS) has respoded with the codecs it is willing to talk to A for this
call. Only one codec will be negotiated for media transfer between A and B.
In your example below, the negotiated codec is G.729, so
Hi all,
In my specific test-case, client A sends an INVITE offering some codecs
and client B answers with a 200OK containing a subset of these codecs.
Is it allowed for client B to transmit media using a codec presented in
the offer of client A but not acknowledged in the answer of client B?
e
PROTECTED]>; [EMAIL PROTECTED] <[EMAIL
PROTECTED]>; sip-implementors@lists.cs.columbia.edu
Sent: Mon Apr 14 09:30:57 2008
Subject: Re: [Sip-implementors] Offer/Answer question
Manpreet Singh wrote:
> That's one reason why I have seen most implementations use re-invites ins
[mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Kyzivat
>> Sent: Monday, April 14, 2008 12:34 AM
>> To: Manpreet Singh
>> Cc: Bob Penfield; [EMAIL PROTECTED];
>> sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Offer/Answer question
>&g
TED]>
To: Manpreet Singh
CC: [EMAIL PROTECTED] <[EMAIL PROTECTED]>;
sip-implementors@lists.cs.columbia.edu
Sent: Mon Apr 14 09:04:10 2008
Subject: RE: [Sip-implementors] Offer/Answer question
I agree with Paul; however I'll highlight the rfc3311 section 5.2 text
concerning UPDAT
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Kyzivat
>> Sent: Monday, April 14, 2008 12:34 AM
>> To: Manpreet Singh
>> Cc: Bob Penfield; [EMAIL PROTECTED];
>> sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Offer/Answer ques
; Cc: Bob Penfield; [EMAIL PROTECTED];
> sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Offer/Answer question
>
>
>
> Manpreet Singh wrote:
> > Wasn't denying the use of update on confirmed dialog, just
> saying the
> > recommended
12:34 AM
To: Manpreet Singh
Cc: kaiduan xie; Bob Penfield; [EMAIL PROTECTED];
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Offer/Answer question
Manpreet Singh wrote:
> Wasn't denying the use of update on confirmed dialog, just saying the
> recommended use o
during an early dialog.
Paul
> Thnx
>
> -Original Message-
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 12, 2008 11:49 PM
> To: Manpreet Singh
> Cc: kaiduan xie; Bob Penfield; [EMAIL PROTECTED];
> sip-implementors@lists.cs.columbia.edu
&g
PROTECTED] On Behalf Of
> Manpreet Singh
> Sent: Sunday, April 13, 2008 12:29 AM
> To: Paul Kyzivat
> Cc: Bob Penfield; [EMAIL PROTECTED];
> sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Offer/Answer question
>
> Is this flow legal from offer a
eet Singh
Cc: kaiduan xie; Bob Penfield; [EMAIL PROTECTED];
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Offer/Answer question
It is permitted to use UPDATE after a dialog has been established. AFAIK
the flow shown is legal. In any case from the POV of the UAS, it is no
ECTED] On
> Behalf Of Manpreet Singh
> Sent: Sunday, April 13, 2008 12:29 AM
> To: Paul Kyzivat
> Cc: Bob Penfield; [EMAIL PROTECTED];
> sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Offer/Answer question
>
> Is this flow legal from offer answer perspec
lumbia.edu
Subject: Re: [Sip-implementors] Offer/Answer question
It is permitted to use UPDATE after a dialog has been established. AFAIK
the flow shown is legal. In any case from the POV of the UAS, it is no
different than if the ACK had been sent first and then the UPDATE send,
with the UPDATE arr
t; -Original Message-
> From: kaiduan xie [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 11, 2008 10:32 PM
> To: Bob Penfield; Manpreet Singh; [EMAIL PROTECTED];
> sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Offer/Answer question
>
:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 10:32 PM
To: Bob Penfield; Manpreet Singh; [EMAIL PROTECTED];
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Offer/Answer question
Is the following case legal?
UAC UAS
INVITE/SDP
hanks,
kaiduan
- Original Message
From: Bob Penfield <[EMAIL PROTECTED]>
To: Manpreet Singh <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL
PROTECTED]>; "sip-implementors@lists.cs.columbia.edu"
Sent: Friday, April 11, 2008 5:54:36 PM
Subject: Re: [Sip
: [Sip-implementors] Offer/Answer question
For an INVITE carrying an offer, does the offer/answer has to complete
within the INVITE transaction? Can it complete outside the transaction
but within the same dialog? Call flow is:
-->Invite ( offer )
<180 ( r
gh
Cc: [EMAIL PROTECTED]; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Offer/Answer question
Your flow is not legal. See
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-0
7.txt
Manpreet Singh wrote:
> For an INVITE carrying an offer, does the offer/an
Your flow is not legal. See
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-07.txt
Manpreet Singh wrote:
> For an INVITE carrying an offer, does the offer/answer has to complete
> within the INVITE transaction? Can it complete outside the transaction
> but within the same d
For an INVITE carrying an offer, does the offer/answer has to complete
within the INVITE transaction? Can it complete outside the transaction
but within the same dialog? Call flow is:
-->Invite ( offer )
<180 ( ringing )
<200OK ( empty..no offer )
-
28 matches
Mail list logo
