This would certainly be valid as the initial notify after a new
subscription. It would also be perfectly valid if there was a *change*
that led to this state. (The numbers were bigger before, and the
messages were deleted.)
Nor, afaik, is it *wrong* for a notifier to send a redundant
notificat
Iñaki Baz Castillo wrote:
> El Sunday 10 August 2008 16:26:50 George AK escribió:
>> Hi,
>>
>> Why it is decided that CANCEL should be a hop to hop request?
>
> It's faster and there is no need of being ent to end.
>
Perhaps true, but I think the main reason is that CANCEL is usually sent
w
Iñaki Baz Castillo wrote:
>>> IMHO the normal behaviour is that original "P-Asserted-Identity" should
>>> remain rendered but it makes impossible to update the callerid if needed.
>> I think you are rising a good point. IMO, the identity should be
>> updated using the one specified in the UPDATE
IIRC = "If I Recall Correctly".
Sorry - such stuff can't be easy for non-native-English speakers.
Iñaki Baz Castillo wrote:
> El Wednesday 13 August 2008 15:10:09 Paul Kyzivat escribió:
>
>>> So you think that it PAI remains in the UPDATE (with different From) then
I generally agree with what others have said.
Logically there are only a couple of meaningful alternatives:
- the *first* 1xx response with a given to-tag extablishes an
early dialog, and so it MUST contain a Contact
- the first 1xx response with a given to-tag *and* a Contact
establishes
Iñaki,
AFAIK there is little in the way of standards for B2BUAs.
The problem with standardizing B2BUAs is that they can be used for many
different purposes. There is virtually nothing that you can say *in
general* that will apply to all B2BUAs beyond what 3261 says - that they
must satisfy all
I believe Iñaki is only expressing a *desire* that the Contact be
mandatory in these case - not that there is currently such an explicit
requirement.
The tables in 3261 are notorious for not being sufficient to convey
nuances. They are often refined in the text.
There are some cases when a 1xx
This is the reason we do clarifications - different people read the same
normative text and come to different conclusions about what the required
behavior is.
Paul
Valentin Nechayev wrote:
>> I??aki Baz Castillo <[EMAIL PROTECTED]> wrote:
>
>>> I propose another interpretation. As
This is a fair question. The same logic that allows extra codecs in the
answer would suggest it should be ok to include extra media in the answer.
I suppose you could think of it as an oversight.
Paul
George AK wrote:
> Hi,
>
> In 3264, in section 6, it tells
> The answer MUST contai
Jagan Mohan wrote:
> Hi All,
>
>I would like to know whether a B2BUA can insert the SIP Methods it
> support in the Allow header, when a SIP call is made between two UAs through
> the B2BUA.
There are *no* rules for B2BUAs, other than that each *side* must behave
correctly as a UA. There a
Iñaki Baz Castillo wrote:
> El Wednesday 20 August 2008 16:29:22 Jagan Mohan escribió:
>> Hi All,
>>
>>I would like to know whether a B2BUA can insert the SIP Methods it
>> support in the Allow header, when a SIP call is made between two UAs
>> through the B2BUA.
>>
>>If yes, then I have
The point is that 100 is very special. When 1xx is used it means
101-199. 100 is special because it is hop-by-hop, while all the others
are e2e.
Thanks,
Paul
Bogdan-Andrei Iancu wrote:
> Hi Iñaki,
>
> Perfectly right!
> single correction -? 1xx response start from 100 and not f
Well, I can find nothing that formally says 1xx excludes 100, and in
fact do find the contrary. However there are places in 3261 that give
rules for 1xx that in fact don't apply to 100. So be careful when 1xx is
used.
Paul
Attila Sipos wrote:
> AFAIK, 100 is a 1xx response but it diffe
It is widely (universally) used in 3GPP/IMS.
In there architecture, the UA connects to an edge proxy/b2bua (the
P-CSCF), and this eventually sends the request to the originating user's
home proxy/b2bua (S-CSCF). The registration is handled by the S-CSCF,
and the P-CSCF notes this as proof of ide
I have to disagree with the point here.
Some might describe me as a "grammatist", in that I prefer a formal
definition of the grammar to an informal one.
The issue isn't that the syntax is formally specified by a grammar. It
is what syntax was chosen to be formalized. It would be equally
gramma
There is nothing that forbids changing any of the Allow-* / Accept-* /
etc. headers within a dialog. If you examine the definition of a dialog
you will not find any of them listed as part of dialog state.
From a practical perspective they sometimes need to change, because
circumstances change
[EMAIL PROTECTED] wrote:
>From: "V.S.R Kumar Kadimcherla" <[EMAIL PROTECTED]>
>
>When a stateful proxy has received 302 responses from all the down
>stream client transactions and received some contacts in those
>responses then proxy is sending 300 response to the upstream by
>
This is certainly a valid approach, and I agree it is in general the
"best" way to indicate a phone number.
It is better than, e.g. a sip URI, because it is intentionally protocol
independent.
The only problem is getting people to use this approach.
Thanks,
Paul
Iñaki Baz Cast
I can't say why other URI types are permitted in Route - I can't think
how this is likely to be of use. (Perhaps for IM: URIs???)
But other types in Contact do have potential value - not during dialog
establishment, but rather in REGISTER and 3xx. It is explicitly legal to
put other types (e.g.
Iñaki Baz Castillo wrote:
> El Sábado, 23 de Agosto de 2008, Paul Kyzivat escribió:
>> But other types in Contact do have potential value - not during dialog
>> establishment, but rather in REGISTER and 3xx. It is explicitly legal to
>> put other types (e.g. mailto:) in a
I think you had better assume that there could be conflicts.
In some cases there is explicitly noted reuse of non-terminals between
independent RFCs, but otherwise there is generally no effort to ensure
consistency.
Paul
Iñaki Baz Castillo wrote:
> El Domingo, 24 de Agosto de 2008, Iñak
Iñaki Baz Castillo wrote:
> Hi, my parser is getting crazy because, IMHO, RFC3966 BNF has a bug:
>
>global-number-digits = "+" *phonedigit DIGIT *phonedigit
>phonedigit = DIGIT / [ visual-separator ]
>visual-separator = "-" / "." / "(" / ")"
>
> Note that 'phonedigit'
Iñaki Baz Castillo wrote:
> 2008/8/25, Paul Kyzivat <[EMAIL PROTECTED]>:
>>> Hi, my parser is getting crazy because, IMHO, RFC3966 BNF has a bug:
>>>
>>> global-number-digits = "+" *phonedigit DIGIT *phonedigit
>>> phonedigit
Iñaki Baz Castillo wrote:
> 2008/8/25, Paul Kyzivat <[EMAIL PROTECTED]>:
>
>> No. That would only allow *one* digit. I'm pretty sure what I wrote matches
>> the same strings as the original. You are trying to match something like:
>>
>> +1-(978)
Iñaki Baz Castillo wrote:
> Hi, my implementation allows "sip", "sips" and "tel" URI types in
> headers as From, To, PAI, PPI and so (I allow "absoluteURI" just in
> Contact for 3XX replies).
>
> So if I receive a request with a From containing other kind of URI I
> would reject it as invalid.
>
Iñaki Baz Castillo wrote:
> Hi, I assume that using "tel" in a From header the same pain as in SIP
> uri would occur, this is:
>
> a) From: tel:+1234
>
> b) From: tel:+1234;param=qwe <-- This is a header param !!!
>
> c) From:<-- This is a URI param !!!
>
> d) From: ;param=qwe <-- T
I'm not an XML guy, so I don't know the answer to the original question.
But I do know that the rules for case sensitivity in ABNF have no
relevance to the answer. The answer must be determined entirely by the
XML schema.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> 2008/9/3, Klaus
dushyant wrote:
> Hi All,
>
> We are developing IMS core network nodes esp. CSCF. I have a query related
> to implementation of RFC 4028 especially w.r.t. 3GPP TS 24.229 and 3GPP TS
> 32.260 procedures.
Which of the P/I/S-CSCFs are B2BUAs? All of them?
> 1. As per 3GPP TS 24.229
The diversion draft expired long ago.
It is widely implemented, but should be considered proprietary.
It won't ever be standardized by the ietf.
It has been (loosely) replaced by the History-Info header.
Thanks
caio wrote:
> Manoj Priyankara (NOD) escribió:
>> Hi,
>>
>> I also tried to fi
caio wrote:
> I tested a pstn-gw which is confused when INVITE uri is different from
> TO header. And I stuck here, with this misunderstanding..
That is a seriously broken GW. Tell them to fix it.
Paul
___
Sip-implementors mailing list
Sip-im
dushyant wrote:
>> Hi All,
>
>
>> We are developing IMS core network nodes esp. CSCF. I have a query related
>
>> to implementation of RFC 4028 especially w.r.t. 3GPP TS 24.229 and 3GPP TS
>
>> 32.260 procedures.
>
>
>
> Which of the P/I/S-CSCFs are B2BUAs? All of them?
>
>
>
> --->
I agree with what others have said. In addition:
This really isn't about the 200 OK. You are to be ready to receive as
soon as you have sent the answer SDP. This *may* be in the 200, but it
can be sooner, in a 180 or 183.
Thanks,
Paul
Rockson Li (zhengyli) wrote:
> Moveover, ev
caio wrote:
> Paul Kyzivat escribió:
>>
>>
>> caio wrote:
>>> I tested a pstn-gw which is confused when INVITE uri is different
>>> from TO header. And I stuck here, with this misunderstanding..
>>
>> That is a seriously broken GW. Tell them
Robert,
This wasn't my question, but I have wondered the same thing.
Robert Sparks wrote:
> Hrmm - I'm not sure I see the confusion yet, but let me describe one
> concept that drove the text in that section to see if it helps. If,
> after you read this, you think there's still a lack of clarity
Vegas. That had to be before I started following
sip. My knowledge of the history has holes like that.
Thanks,
Paul
Robert Sparks wrote:
>
> On Sep 8, 2008, at 12:01 PM, Paul Kyzivat wrote:
>
>> Robert,
>>
>> This wasn't my question, but I have
about the preservation of orig-RURI for service
> identification.
>
> FYI
>
> Regards,
> -Rockson
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Paul Kyzivat (pkyzivat)
> Sent: Tuesday, September 09, 200
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
The below implies that if the stream is inactive then you don't have to
open the port yet. But that doesn't apply to the RTCP port. It is to be
used even for inactive streams, so should be opened immediately.
Paul
Rohit Aggarwal wrote:
> Hi
>
> Sec 5.1 of RFC 3264 clearly states that:
th. I guess the option is
to send the reinvite with no offer. Note that the same paragraph
explicitly states "A re-INVITE generated to refresh the session is a
normal re-INVITE". So sending something that is invalid as a normal
reinvite would be a bad thing.
Thanks,
Pa
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
Jagan Mohan wrote:
> Hi,
>
>If the codec change requested in a Re-INVITE needs to be rejected by UAS,
> is it mandatory to send a 488 response to the Re-INVITE and continue
> operating with the codec negotiated in the INVITE?
Would be helpful if you showed the specifics of the SDP in the in
Harsha. R wrote:
> Paul,
>
> >- answer successfully, but reject the media line, by setting the port
> > to zero
>
> If the port is set to zero, will it not cause media flow to cease?
Certainly.
I was just enumerating all the possible responses.
This isn't likely to be the most desirable ap
Jagan Mohan wrote:
> Yes, it would cause media flow to cease for that particular stream.
>
> AFAIK, setting port to zero is normally used only when there are
> multiple 'm' lines in the offer and you want to reject certain 'm' lines
> in the answer. If all 'm' lines need to be rejected, then
First, look at
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-08.txt
More comments inline.
Thanks,
Paul
krishna kalluri wrote:
> Hi,
>
> The following para in "13.3.1.4 The INVITE is Accepted" in RFC 3261 is
> confusing with the description in 13.2.1 (A
Iñaki Baz Castillo wrote:
> Hi, imagine A calls B via proxy P:
>
> - A sends the INVITE to P.
> - P forwards to B.
> - B replies a 200 OK that arrives to P (this would cause proxy core to
> terminate the client transaction).
> - Before A receives the 200 OK it sends a CANCEL to P.
>
> What sho
At end...
Iñaki Baz Castillo wrote:
> El Martes, 16 de Septiembre de 2008, Paul Kyzivat escribió:
>> Iñaki Baz Castillo wrote:
>>> Hi, imagine A calls B via proxy P:
>>>
>>> - A sends the INVITE to P.
>>> - P forwards to B.
>>> - B replies a
I'm not buying the "this poor dumb UA can't handle it" argument.
A UA capable of handling IMS signaling is not dumb. So I agree that the
"right" way to do this is to forward the INVITE for the new call to A,
alongside the existing call. The UA then is responsible for alerting the
user. Because t
Rockson Li (zhengyli) wrote:
> Yes, Notify alone is enough to establish dialog in UAC.
While the NOTIFY is enough to establish the dialog, it doesn't obviate
the need for the 200 to complete the SUBSCRIBE transaction. If the 200
doesn't arrive, the SUBSCRIBE will be retransmitted.
Having the
Rockson Li (zhengyli) wrote:
> Comments inline.
>
> Thanks
> -Rockson
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
> Castillo
> Sent: Wednesday, September 17, 2008 4:51 PM
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re:
See RFC 5057. The error only means that this one transaction has failed.
The dialog remains.
Paul
Pascal Maugeri wrote:
> Hi
>
> I have the following scenario where a UAC subscribe to a UAS a SIP
> SUBSCRIBE request, receive SIP NOTIFY messages (RFC3265) and then the UAC
> receives fro
Hi Dale,
Looks pretty reasonable, though I think people will continue to use a
multiplicity of methods depending on their goals, constraints, and whims.
One thing I was thinking about here is what happens if common codecs
don't exist at all parties. I think your proposal can still work in that
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
[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
Iñaki,
What you suggest is a valid way to manage presence.
This all comes down to how presence data from different sources is
aggregated. This was discussed quite a bit once, and then we concluded
that it isn't something that we knew how to standardize. So presence
aggregation is an area for pr
Reject the reinvite with a 488. That will cause the call to revert to
the single media stream in effect prior to the reinvite.
Paul
Neranza Bundova wrote:
> But if the UA reject the media by setting it the port to 0, there will
> be no media streams in the call. Because according to rfc
Iñaki Baz Castillo wrote:
> 2008/9/18, Paul Kyzivat <[EMAIL PROTECTED]>:
>> Iñaki,
>>
>> What you suggest is a valid way to manage presence.
>> This all comes down to how presence data from different sources is
>> aggregated. This was discussed quite
t a formal problem.
In fact, as far as I can tell, it isn't a real problem any time the
address/port changes as well as the payload numbers. That's why I think
the real answer is the relax the restriction.
Thanks,
Paul
[EMAIL PROTECTED] wrote:
>From: Paul Ky
Iñaki,
While many "pbx"s (including those from my employer) are implemented as
B2BUAs, it is possible to implement pbx functionality without a B2BUA.
(Dale and Scott can explain to you how they do it.)
Paul
Iñaki Baz Castillo wrote:
> 2008/9/23, karthik karthik <[EMAIL PROTECTED]>:
>>
karthik,
B2BUA is a very general mechanism that may be used for a multitude of
purposes, some good, some evil.
Some things that are B2BUAs that you might not think of as such:
- a conference focus
- a presence server
The kind of B2BUA you seem to be talking about is probably an SBC, or
maybe a
t;
> -Bhanu
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Paul Kyzivat (pkyzivat)
> Sent: Tuesday, September 23, 2008 10:11 PM
> To: karthik karthik
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [
I'm not familiar with either of these "features", but I do agree that
you can invent features that would require a B2BUA.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> El Martes, 23 de Septiembre de 2008, Paul Kyzivat escribió:
>> Iñaki,
>>
>> Whi
Bartosz,
You seem to be ignoring the distinction between 'dialog' and 'dialog
usage' which is clarified in 5057. Most of the things you mention below
terminate the dialog usage. Especially for *early* dialogs its
*generally* the case that the dialog will go away at the same time.
There are pot
Each sends using the value specified by the other end, and expects to
receive the value it specified.
Paul
Rockson Li (zhengyli) wrote:
> Yes it represents the UA's intended RTP payload type for SENDING or
> RECEIVING RTP.
> And you are correct you don't have to make use of the same valu
Harsha. R wrote:
> ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend
> tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx
> responses. If 3262 clearly stated that reliable provisional responses
> MUST have Contact - we would not have this issue
>
> Its not
I'm not going to tell you how to do that because it isn't a legal sip usage.
It is true that some things have been known to use unsolicited NOTIFY.
I'm not certain I have heard of it for DTMF, but I have heard of it for
MWI. But its still not a standard usage.
The only plausible reason I can th
Kamalakanta Palei (kpalei) wrote:
>
>> What is the behavior of the receiver if it receives offer with
>> different
> "session id" in
>> re-INVITE or UPDATE?
>
> Take down the call as REINVITE o-line with a new session id identifies a
> session that does not exist at UA.
>
> [Kamal]
> Taking
IMO you can do as you wish. But to maximize interop you probably don't
want to reject the call.
The assumption was that the UAC supported but didn't require session
timer. So just accepting the call and *not* acting as refresher will
suit its needs. But if there is a proxy in the middle that is
Anuradha Gupta wrote:
> How to maintain multiple dialogs should be implementation specific.
> RFC 3261 explains about forking at multiple places.
> As the forked reponses differ on "To Tag" therefore multiple dialogs need to
> be maintained on the basis of To Tags till the time forked provisiona
Iñaki Baz Castillo wrote:
> Hi,
>
> It's very common that when a UA1 sends a REGISTER via TCP from a random port
> 1, if the connection remains open (for example using ping-pong method),
> the proxy can send request to UA1 using that TCP connection.
> Is really this behaviour defined in RF
Iñaki Baz Castillo wrote:
> 2008/10/13 Paul Kyzivat <[EMAIL PROTECTED]>:
>
>> You say you don't consider the connection reuse draft. But you should,
>> because its intent is to clarify behavior that is unclear in 3261.
>
> Well, what I want to know is wh
Iñaki Baz Castillo wrote:
> El Martes, 14 de Octubre de 2008, Paul Kyzivat escribió:
>> I was thinking of something more extreme:
>>
>> REGISTER sip:example.com
>> To: sip:[EMAIL PROTECTED]
>> From: sip:[EMAIL PROTECTED]
>>
Iñaki Baz Castillo wrote:
> El Miércoles, 15 de Octubre de 2008, Paul Kyzivat escribió:
>> Iñaki Baz Castillo wrote:
>>> El Martes, 14 de Octubre de 2008, Paul Kyzivat escribió:
>>>> I was thinking of something more extreme:
>>>>
>>>>
Rohit Aggarwal wrote:
> Hi
>
> I have a query regarding the media format list for rejected stream in answer
> SDP.
>
> An offered media stream can be rejected by setting media port to 0 in the
> m-line corresponding to the rejected stream. In this m-line, is it necessary
> that the media for
Funny. This exact point came up in a private conversation I was having
just a day ago.
Alok 2 Tiwari wrote:
> Hi,
> As per RFC-3261, the retry after timer is started by UAC itself after
> deciding the retry after duration based on call id ownership. So there is no
> need of retry after header i
Vadim Berezniker wrote:
> Hi,
>
> We have a client that sends multiple registrations.
> All of the registrations have the same Call-ID and and incremented CSeq.
> So far, I believe the behavior is correct. (Although in practice, every
> other device I've seen uses a unique Call-ID for each uniqu
id all that, a lot of registrars will probably work ok
with what you are currently doing.
Thanks,
Paul
> On Mon, Oct 20, 2008 at 9:29 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>>
>> Vadim Berezniker wrote:
>>
>>> Hi,
>>>
>
's acceptable, it must wait until a final response for a
> registration before sending the next one. Am I interpreting it correctly?
>
>
> On Mon, Oct 20, 2008 at 10:13 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>>
>> Vadim Berezniker wrote:
>>
&
Iñaki Baz Castillo wrote:
> 2008/10/22 Iñaki Baz Castillo <[EMAIL PROTECTED]>:
>> Hi, SIP Presence Event Package RFC( 3856 ) says that From and To of a
>> SUBSCRIBE cannot be a TEL URI:
>>
>> Section 5.
>>
>> SUBSCRIBE messages also contain logical identifiers that define the
>> originat
You are asking two different questions. More inline.
Subbu Rajendran wrote:
> Hi,
> SIP RFC 2543 uses c=0.0.0.0 method to put a call on hold. RFC 3264 has
> introduced a=sendonly/recvonly/inactive/sendrecv attributes that can be used
> put media to one way, hold and 2-way. However what should be t
Paul
Klaus Darilion wrote:
>
> Paul Kyzivat schrieb:
>> Iñaki Baz Castillo wrote:
>>> 2008/10/22 Iñaki Baz Castillo <[EMAIL PROTECTED]>:
>>>> Hi, SIP Presence Event Package RFC( 3856 ) says that From and To of a
>>>> SUBSCRIBE cannot be a TE
Iñaki Baz Castillo wrote:
> El Viernes, 24 de Octubre de 2008, Vikram Chhibber escribió:
>> I think we are digressing from the original query. The question is not
>> about routing of tel url. The query is why the public identities in
>> From and To header can not be tel for SUBSCRIBE. A better ex
Arunachalam Venkatraman (arunvenk) wrote:
> The sequence of processing a received message at a SIP UA ia to identify
> the call, then the dialog within the call and then the transaction
> within the dialog.
> If the call is found, then an existing dialog must be found. If the
> from-tag is change
inal Message-
> From: Kanumuri, Sreeram [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2008 1:20 PM
> To: Paul Kyzivat (pkyzivat); Arunachalam Venkatraman (arunvenk)
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: RE: [Sip-implementors] Call-id Use ( Re-use/Misu
So, my question is can we
> generalize that if c=0.0.0.0 is present then
> a=sendonly/recvonly/sendrecv/inactive can be ignored and be processed as
> call being put on hold?
>
> Thanks,
> Subbu
>
> On Fri, Oct 24, 2008 at 8:26 AM, Paul Kyzivat <[EMAIL PROTECTED]> wr
karthik karthik wrote:
> Hello All,
>
> Please let me know the behavior for the below cases.
> I believe 'm=' line is not mandatory according to rfc 4566
> Still It was decided to release the session in our application.
>
> case1:
> Invite is received with SDP, and has no 'm=' line.
> In case w
Andrea Rizzi wrote:
> Brett,
>
> Could you please clarify why an unreliable provisional response doesn't
> complete an offer/answer? IMO, when a UAC send an offer on the Invite, the
> SDP included in the first provisional response closes the offer/answer
> exchange, regardless it is reliable or
ually making the answer
> contain c=0.0.0.0 <http://0.0.0.0> and a=inactive which is nothing but
> the answer, from a GW that supports both RFC 2543 and RFC 3264, for an
> offer to put the call on hold.
>
> So I'm trying to find out if my first statement is proved to
Romel Khan wrote:
>
> If an INVITE contains an initial offer, per RFC3261 "the answer MUST be
> in a reliable non-failure message from UAS back to UAC The UAC MUST
> treat the first session description it receives as the answer, and MUST
> ignore any session descriptions in subsequent respo
Iñaki Baz Castillo wrote:
> 2008/11/10 Paul Kyzivat <[EMAIL PROTECTED]>:
>>
>> Iñaki Baz Castillo wrote:
>>> Hi, draft-anil-sipping-bla requires a 3rd Party Registration. This
>>> REGISTER is a normal REGISTER but From and To are different, there is no
&
Iñaki Baz Castillo wrote:
> Hi, draft-anil-sipping-bla requires a 3rd Party Registration. This REGISTER
> is
> a normal REGISTER but From and To are different, there is no more "special"
> data into the request.
>
> Are there other cases in which 3rd Party Registration is used?
I don't know
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-
Iñaki Baz Castillo wrote:
> Hi, during a chat between two users (alice and bob) using XMPP, alice closes
> the chat window and bob receives a notification:
> "alice has ended this chat"
>
> I wonder if such of features are possible in SIP. I hope this would be done
> via a MESSAGE with a spe
Iñaki Baz Castillo wrote:
> El Domingo, 16 de Noviembre de 2008, Paul Kyzivat escribió:
>> Lets assume you mean an MSRP session established using SIP.
>> In that case, there are many possibilities:
>> - when alice tells her client to end the session,
>>it could
jorma h wrote:
> Hi,
>
> I'd like to ask a couple of follow-on questions to this.
>
> When a proxy receives a message (e.g. INVITE) with a SIP URI containing an
> embedded tel URI, and that embedded tel URI has parameters, how is this
> handled when:
>
>
> 1. The proxy DOES NOT serve the doma
No this isn't valid. The offer must be answered.
This is the Session Initiation Protocol. Without an answer you have not
initiated a session.
Paul
NC Reddy wrote:
> Hi,
> I have the following context question:
>
> UAC <->AS(B2BUA)
> | --F1 (INVITE)--->
> *
their network) to require the media to be symmetric,
using the address in the answer as a gate for what will be accepted.
So why would you not want to send the answer? It costs almost nothing
extra in signaling.
Thanks,
Paul
> Thanks in advance.
>
> Regards
> Ch
NC Reddy wrote:
> On Thu, Nov 20, 2008 at 9:49 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>>
>> NC Reddy wrote:
>>
>>> I agreed it breaks the SDP offer/answer protocol, but i think it won't
>>> break SIP controlling protocol rules.
>>
Volkan Hatem wrote:
> How are you planning to handle race conditions where "Subscribe expires:0"
> is delivered before the original subscribe?
In that case, you get the one notify, and the earlier subscribe fails
with a 500 due to out of order CSeq number. But you get the result you
wanted.
>
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Paul Kyzivat (pkyzivat)
> Sent: Tuesday, November 25, 2008 1:11 AM
> To: Volkan Hatem
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Multiple Subscriptions in a dialog.
>
>
>
> Volkan Hatem wr
Looking at your messages, I see:
- at cseq 2, an initial invite offering a bunch of codecs
- the 200 to that accepts two codecs plus telephone-events
- at cseq 3, pbx reinvites, apparently to reduce to once
codec plus telephone-events.
- that gets the 415.
It seems that at least the 415 is bei
301 - 400 of 1159 matches
Mail list logo
