On 2/22/12 5:59 PM, Kevin P. Fleming wrote:
> On 02/22/2012 04:11 PM, Iñaki Baz Castillo wrote:
>> 2012/2/22 Paul Kyzivat:
>>> If I was in the position of needing to construct a temporary offer, with
>>> no ability to handle media myself, and no knowledge of what the caller
>>> might be looking for
On 02/22/2012 04:11 PM, Iñaki Baz Castillo wrote:
> 2012/2/22 Paul Kyzivat:
>> If I was in the position of needing to construct a temporary offer, with
>> no ability to handle media myself, and no knowledge of what the caller
>> might be looking for or what is likely to be offered later, I would be
2012/2/22 Paul Kyzivat :
> If I was in the position of needing to construct a temporary offer, with
> no ability to handle media myself, and no knowledge of what the caller
> might be looking for or what is likely to be offered later, I would be
> inclined to offer audio with G.711 and a black hole
On 2/22/12 4:30 PM, Brett Tate wrote:
>> I do not know the reasoning behind this requirement.
>> Many would find it convenient if it wasn't there. But
>> the gist of the discussion was that relaxing this
>> requirement after its been along is more trouble than
>> its worth. Its really not that hard
> I do not know the reasoning behind this requirement.
> Many would find it convenient if it wasn't there. But
> the gist of the discussion was that relaxing this
> requirement after its been along is more trouble than
> its worth. Its really not that hard to come up with
> some sort of offer.
On 2/22/12 5:54 AM, OKUMURA Shinji wrote:
> Hi Paul,
>
> I think that the following rule should be applied to Session-Expires.
>
> RFC3311/5.1 Sending an UPDATE
> If a UA
> uses an UPDATE request or response to modify the remote target while
> an INVITE transaction is in progress, and i
On 2/22/12 6:51 AM, vivek.ba...@matrixcomsec.com wrote:
> Hi,
>
> I am struggling to find out this from long time, however have seen
> some implementation as follows;
>
> 1. First of all, you can't know whether remote end has a capability to
> detect DTMF in Inband.
> 2. For SIP INFO, your device c
Thanks for all the references Brett!
I don't know how you manage to dredge them all up.
I haven't bothered to read through them all now - sorry.
But the requirement for an offer in the first reliable response was
debated at length a *long* time ago. (I recall a live discussion at some
meeting, w
Issues with RFC 3262 have been raised over the years including the long 2006
SIP Tread "The Problem with PRACK".
http://www.ietf.org/mail-archive/web/sip/current/msg13221.html
Some of them have been addressed by RFC 6337, RFC 6141, and RFC 6228. However
as RFC 6337 indicates, some issues st
2012/2/22 Kevin P. Fleming :
> Well, this scenario is not very realistic anyway, because as others have
> pointed out, "Require: 100rel" in an INVITE is a fairly bad idea to
> begin with.
"Require: 100rel" is a bad idea for anything, right. And also the
whole PRACK specification. A much more easie
On 02/22/2012 02:24 AM, Iñaki Baz Castillo wrote:
> 2012/2/22 Paul Kyzivat:
>> Iñaki,
>>
>> If the invite is offerless, and contains Require:100rel, then the first
>> provisional must be reliable, and the first reliable response must contain
>> an offer.
>
> Hi Paul, I missed the point that the INV
Hi,
I am struggling to find out this from long time, however have seen
some implementation as follows;
1. First of all, you can't know whether remote end has a capability to
detect DTMF in Inband.
2. For SIP INFO, your device can consider that remote end supports SIP
INFO if received in All
Folks,
I wonder how the offerer recognizes whether a particular SIP end point
supports in-band DTMF or SIP INFO by negotiating SDP? SIP INFO is assumed
when RFC2833 negotiation fails but how exactly we know whether the endpoint
supports SIP INFO not In Band?
Cheers!
Manoj
Hi Paul,
I think that the following rule should be applied to Session-Expires.
RFC3311/5.1 Sending an UPDATE
If a UA
uses an UPDATE request or response to modify the remote target while
an INVITE transaction is in progress, and it is a UAS for that INVITE
transaction, it MUST place th
2012/2/22 Paul Kyzivat :
> Iñaki,
>
> If the invite is offerless, and contains Require:100rel, then the first
> provisional must be reliable, and the first reliable response must contain
> an offer.
Hi Paul, I missed the point that the INVITE was offerless, so my apologies.
Anyhow I don't underst
15 matches
Mail list logo
