Yes Dale, I am referring to RFC 4916. I meant that what is the behavior of
the UA if the SIP dialog that got established supported "from-change"? Does
holding party informs the held party that he is not connected to different
identity?
On Fri, Sep 26, 2008 at 9:21 PM, <[EMAIL PROTECTED]> wrote:
>
From: "Vikram Chhibber" <[EMAIL PROTECTED]>
Do you think it is worth mentioning about the RFC 4917 on SIP Connected
Identity as the media-session is re-negotiated in mid-dialog?
(I assume you mean RFC 4916.)
I expect that anyone who works with SDP knows this fundamental
property of the
Thanks Dale, this explains a lot.
Do you think it is worth mentioning about the RFC 4917 on SIP Connected
Identity as the media-session is re-negotiated in mid-dialog?
On Wed, Sep 24, 2008 at 1:07 AM, <[EMAIL PROTECTED]> wrote:
> From: "Vikram Chhibber" <[EMAIL PROTECTED]>
>
>I think I have
From: "Vikram Chhibber" <[EMAIL PROTECTED]>
I think I have missed something here. Why do we need to maintain codec
numbers relationship with the previous offer/answer (Between Alice and Bob)?
My understanding is that offer/answer model does not have any state
dependency with previou
I think I have missed something here. Why do we need to maintain codec
numbers relationship with the previous offer/answer (Between Alice and Bob)?
My understanding is that offer/answer model does not have any state
dependency with previous one except for "o" line and maintaining media
description
From: "Vikram Chhibber" <[EMAIL PROTECTED]>
In the call flow that the draft describes, isn't it better to send re-INVITE
without SDP towards the music-store? The reason is that "Alice" UA may send
back codecs previously negotiated with "Bob" whose intersection with
media-source may
From: "Rastogi, Vipul (Vipul)" <[EMAIL PROTECTED]>
What basic issue you wanna remove from this new RFC in MOH scenario ? I
can think of MOH directly be initiated by UAC/UAS rather than any middle
man. Is it correct assumption?
Yes, that is the idea.
Dale
_
[EMAIL PROTECTED]
Sent: Thursday, September 18, 2008 2:32 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Music-on-hold proposal
I've got an Internet-Draft that describes the best way that we (the sipX
PBX project) have found to implement music-on-hold. I'd like fee
In the call flow that the draft describes, isn't it better to send re-INVITE
without SDP towards the music-store? The reason is that "Alice" UA may send
back codecs previously negotiated with "Bob" whose intersection with
media-source may be 0.
Even though
http://www.ietf.org/internet-drafts/dra
[EMAIL PROTECTED] wrote:
>From: Paul Kyzivat <[EMAIL PROTECTED]>
>
>It is technically a "callee-capability". IMO using it for rendering is a
>bit of an abuse, since it is trying to describe what it is doing rather
>than what it is capable of doing. Even so, it doesn't mean "hol
From: Paul Kyzivat <[EMAIL PROTECTED]>
It is technically a "callee-capability". IMO using it for rendering is a
bit of an abuse, since it is trying to describe what it is doing rather
than what it is capable of doing. Even so, it doesn't mean "hold". I'm
not certain that it reall
: [Sip-implementors] Music-on-hold proposal
Iñaki Baz Castillo wrote:
> El Miércoles, 17 de Septiembre de 2008, [EMAIL PROTECTED] escribió:
>> I've got an Internet-Draft that describes the best way that we (the
>> sipX PBX project) have found to implement music-on-hold. I
El Jueves, 18 de Septiembre de 2008, Paul Kyzivat escribió:
> > Why so strange parameter name in Contact?:
> > +sip.rendering="no"
> > Is it usual a parameter name begining with "+" and containing a dot "."
> > in other parameters?
>
> You obviously haven't yet found callerprefs. Check out RFCs
Iñaki Baz Castillo wrote:
> El Miércoles, 17 de Septiembre de 2008, [EMAIL PROTECTED] escribió:
>> I've got an Internet-Draft that describes the best way that we (the
>> sipX PBX project) have found to implement music-on-hold. I'd like
>> feedback from the implementor community.
>
> Hi, it seem
El Miércoles, 17 de Septiembre de 2008, [EMAIL PROTECTED] escribió:
> I've got an Internet-Draft that describes the best way that we (the
> sipX PBX project) have found to implement music-on-hold. I'd like
> feedback from the implementor community.
Hi, it seems really interesting. Just a question
I've got an Internet-Draft that describes the best way that we (the
sipX PBX project) have found to implement music-on-hold. I'd like
feedback from the implementor community.
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Ses
16 matches
Mail list logo
