Hi Neel,
RFC3264
7 Offerer Processing of the Answer
The offerer MAY immediately cease listening for media formats that
were listed in the initial offer, but not present in the answer.
Therefore, UA A may not be able to receive G726.
If UAs use G726, reINVITE will be needed.
Shini
>See bel
Hello,
Can anyone please help me out on the below issue.
Thanks,
Nitin Kapoor
On 12 March 2010 09:06, Nitin Kapoor wrote:
> Hello Friends,
>
> I am facing the problem with one of my client. I can see we are getting the
> 2 codecs in SDP(G.711 & G.729) with payload "0, 101, 19".
>
> Now here is
2010/3/12 Paul Kyzivat :
> This is addressed by RFC 5057.
> The transaction times out and fails, but neither the dialog nor the invite
> dialog usage are affected.
Thanks!
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@lists
This is addressed by RFC 5057.
The transaction times out and fails, but neither the dialog nor the
invite dialog usage are affected.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> Hi, an easy scenario:
>
> - A calls C through a B2BUA and the call is established with direct
> audio bet
Specifically regarding session timer:
every UPDATE or reINVITE renegotiates the use/non-use of the timer and
the timer value. So you may start with it off, and later turn it on, or
start with it on and later turn it off. If you're not careful, you may
start with it on and inadvertently turn it
the way 3264 is worded, any of the codecs in the offer may be used to
send toward the offerer, and any of the codecs in the answer may be used
to send toward the answerer.
However in practice I think you will find that many implementations only
support sending and receiving using codecs in the
2010/3/12 Saúl Ibarra :
> Hi Iñaki,
>
> On Fri, Mar 12, 2010 at 5:39 PM, Iñaki Baz Castillo wrote:
>> Well A could generate a BYE with a very high CSeq (at least greater
>> than the failed OPTIONS) and send it to B2BUA but it's, for sure, not
>> required at all.
>>
>> My question is: could somebod
Iñaki Baz Castillo wrote:
> Any reference in RFC 3261 please? Thanks a lot.
This could help:
12.2.1.2 Processing the Responses
... A UAC SHOULD also terminate a dialog if no response at all is
received for the request (the client transaction would inform the TU
about the timeout.)
For INVITE in
Hi Iñaki,
On Fri, Mar 12, 2010 at 5:39 PM, Iñaki Baz Castillo wrote:
> Hi, an easy scenario:
>
> - A calls C through a B2BUA and the call is established with direct
> audio between A and C.
>
> - A sends an in-dialog OPTIONS but B2BUA replies nothing (ignores the
> request) due to a bad implement
Hi, an easy scenario:
- A calls C through a B2BUA and the call is established with direct
audio between A and C.
- A sends an in-dialog OPTIONS but B2BUA replies nothing (ignores the
request) due to a bad implementation or SIP stack.
- After ~32 seconds A decides that the dialog is dead and term
See below.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Michael
> Hirschbichler
> Sent: Friday, March 12, 2010 8:52 AM
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-imp
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Balu
> Meenakshi-a24053
> Sent: Friday, March 12, 2010 12:22 AM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] Mi
Saúl Ibarra wrote:
> I'm not an expert myself, but hope this gives you a little hint :) The
> fact that a user is behind symmetric NAT doesn't mean that it will
> need assistance 100% of the times (only 99,999% xD). If user A is
> behind a symmetric NAT and user B is on open internet without NAT an
Hi,
On Fri, Mar 12, 2010 at 4:32 PM, Thomas Gelf wrote:
> All,
>
> wondering myself where I can find an RFC section stating how an UAC
> shall behave, if it discovers itself being behing a symmetric NAT (as of
> RFC3489). Shall it fill Via, Contact and SDP with it's internal IP:Port,
> or shall i
All,
wondering myself where I can find an RFC section stating how an UAC
shall behave, if it discovers itself being behing a symmetric NAT (as of
RFC3489). Shall it fill Via, Contact and SDP with it's internal IP:Port,
or shall it use it's reflective ip:port pair, even if knowing that it
will not
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
Hello Friends,
I am facing the problem with one of my client. I can see we are getting the
2 codecs in SDP(G.711 & G.729) with payload "0, 101, 19".
Now here is my doubt is that whenver my client is sending the SDP in initial
OFFER with G.729 its offering "Media format = 0".But when i checked the
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
20 matches
Mail list logo
