181 should follow the rules for any other provisional response. So you
could include SDP in the same cases where you might if it were a 183.
You are governed by the general offer/answer rules.
Paul
Sumin Seo wrote:
Hi All,
Let's say I want to play announcement to let user know that
Girish,
There are no rules here. IETF only standardizes the protocol, not the
construction of stacts that support it. You are free to construct the
stack any way you, and the users of your stack, desire.
Paul
Girish Moodalbail wrote:
Thanks Robert for the response.
From your
oh, duh. The Linksys device is the victim here, not the culprit.
Paul
Paul Kyzivat wrote:
Stephan Steiner wrote:
Actually this proxy/registrar (the Linksys SPA9000), does things in a rather
interesting way:
Well... you will note that my email address is @cisco.com, and Linksys
Stephan Steiner wrote:
Could you tell me where exactly? I must have looked in the wrong
sections as I've been unable to find it.
Well, its not quite as explicit as I was thinking. :-(
That's what I feared. To make sure I get this, what do you think should
happen in this scenario:
by different manufacturers).
Regards
Stephan
- Original Message - From: Paul Kyzivat [EMAIL PROTECTED]
To: Paul Kyzivat [EMAIL PROTECTED]
Cc: Stephan Steiner [EMAIL PROTECTED];
sip-implementors@lists.cs.columbia.edu
Sent: Saturday, July 21, 2007 3:54 AM
Subject: Re: [Sip
Its clear from 3264 that just as an offer can change the session, the
answer may change as well. Think of the sip session as having one
currently active session description on each end. Via subsequent
offer/answer either one of the session descriptions may be changed by
providing a suitable
Dale has covered this. For the original poster, Stefan: there is a lot
of written information on this subject that you don't seem to be
familiar with. The most obvious are RFCs 3261 and 3264. For a more
complete treatment, see
Vikram Chhibber wrote:
As per RFC 3264, a missing direction attribute in offer SDP default is
sendrecv. What is the default considered in case of Answer SDP?
I assume that it should be again sendrecv and the default does not
change whether it is offer or answer.
There are some issues
there is no serious harm in incrementing it in
this case too if you haven't kept track of whether it has changed.)
Paul
Stefan Sayer wrote:
Paul Kyzivat wrote:
Dale has covered this. For the original poster, Stefan: there is a lot
of written information on this subject that you don't
From what I can see of the example below there is only one problem -
the version number in the 2nd answer should have been incremented.
As written, the offerer could proceed on the assumption that the answer
has not changed. In this case that would do no harm. In some other cases
it might.
Valentin Nechayev wrote:
Stefan Sayer [EMAIL PROTECTED] wrote:
complete treatment, see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt
where you write in 4.2.5. Subsequent Offers and Answers:
o In the o-line, only the version number may change, and if
I believe the question is really not whether the terminal is
available, but rather whether it would accept your call if you made a
call.
Its quite possible that even though it is engaged in a call it would
still accept a call from you, or that even though it is not engaged in a
call it might
What do you want to know? You are correct that this is a third party
registration. Its legal if the registrar authorizes it. (Many won't.)
Paul
friend friend wrote:
Folks,
The below message is a Third Party Registration message
From:sip:[EMAIL PROTECTED]
To: sip:[EMAIL
nabeel mohamed wrote:
Hi all,
Can anyone of you clarify me the below ?
RFC 3261 says,
If the remote sequence number in a dialog is not empty, and a request is
received with a sequence number lower than the remote sequence
number, then the request should be rejected with response 500.
[EMAIL PROTECTED] wrote:
Telefónica Móviles España, S.A.
Hi
According to RFC3841 it
, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat
Sent
responses
from different UASs due to forking.
If these had different R-R, then that would constitute changing the
route for a dialog, which isn't allowed.
Paul
Thanks,
Praveen
*/Paul Kyzivat [EMAIL PROTECTED]/* wrote:
I agree with Kasturi regarding the meaning of that text
I'd be very interested to hear of *anybody* that has implemented this.
I have the impression there are none.
Paul
Brett Tate wrote:
Look closer at the examples within section 7.
The caller offered port 2 in INVITE. The caller answered the early
offer with port 20002. Thus the
Devaki D wrote:
Hi All,
I have some doubts regarding the implementation of tel URI as per RFC
3966.Any inputs will be highly appreciated.
1)Is it possible to have tel: URI as request URI in methods other than INVITE
and REGISTER i.e in OPTION,PRACK,ACK,CANCEL,BYE, Notify,Subscribe
[EMAIL PROTECTED] wrote:
Hi Vinay,
REFRESH SUBSCROBE
|---|---|
Will create the subscription again on UAS because for UAS it is a
totally new SUBSCRIBE, previous subscription has been deleted.
Since the subscriber thinks this is a refresh, the request will have a
to-tag. But
Since the SDPs are the same, I assume that the responses are from the
same UAS, and carry the same to-tag. You didn't say if the responses
were reliable provisionals, so I will assume they were not. (The answer
is different if they are.)
In that case the answer is that this is entirely legal.
Pandurangan R S wrote:
Thanks for the reply.
In case the proxy receives a SUBSCRIBE (with the request uri
[EMAIL PROTECTED] the proxy is responsible for this domain)
for an Event that it does *not* understand, should it
a) Reject the SUBSCRIBE with 489 - Bad Event OR
b) Forward the
Vikram Chhibber wrote:
Hi,
I want to perform page-mode instant messaging (using SIP MESSAGE) on a
dialog created by INVITE. This INVITE I want for establishing a dialog
on which I can send SIP MESSAGE only and there will be no media. I do
not want msrp either.
The first question is *why*
Attila Sipos wrote:
I seem to remember some discussion about the # and # character a
long time ago.
You could respond with 400 Bad Request but I think it would be best
if you just treated it as if the # had been escaped. I know it's not strictly
compliant but:
1. I don't think it
: Paul Kyzivat [EMAIL PROTECTED]
The UA receiving this must (by definition) be the UAS. It *ought* to be
the intended recipient of the request (leaving aside some B2BUAs which
have different issues). As the intended recipient, the URI ought to be
one it knows about. Since this one
at all means that the UA will retransmit until
timeout and as you already have said that is not a good solution.
Hope that you can help me out on this :)
// Andreas
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat
Sent: den 15
라스토기 wrote:
Request-Disposition of RFC 3841 prevents or guides forking. Hope it helps
I've never heard of anyone implementing that. Has anybody?
Thanks,
Paul
Vipul Rastogi
Engineer, Business Management Team
Telecommunication Network Business
Samsung Electronics CO,
Vikram,
I don't think you should do this at all. But if you are going to do it,
why don't you follow some precedent such as what MS does. I don't have
the details, but I expect it wouldn't be hard to come up with them.
Paul
Vikram Chhibber wrote:
Dale, the problem here is that the
라스토기 wrote:
'sendonly' is part of SDP, UA (we) know/s that call via this SDP is put on
hold.
If you put 'sendonly' in SDP you ought to know why, whether it is for
hold, or because you are just a music player, or whatever. Nobody has to
tell you why.
If you *receive* SDP with 'sendonly'
What is impractical about it.
UPDATE may be used for a mid session o/a. This is perfectly fine as long
as UPDATE is supported.
Paul
라스토기 wrote:
It is valid but not practical but looks very interesting as one can avoid
3-way handshaking of RE-INVITE by using UPDATE.
Vipul Rastogi
Raghu Thakur wrote:
The SDP offer for the FAX stream by UAC can be sent in case UAC
already has a voice call established ( media over voice is already
present) with UAS. Offer can be seen as an attempt by the UAC to
change its existing audio stream to T.38 FAX.
The SDP negotiation
narendra singh wrote:
Hi Attlia,
Thanks for the reply.
What corrective actions has to be taken at user A, if the mentioned answer
is received.
That's difficult. Since the violation came in a response you can't
respond to it with an error.
You could simply send a BYE, or you can
Murali Radhakrishnan wrote:
Hi,
I have an Application Runing on a Weblogic Sip Server (BEA). In Case 1
- Non Reliable scenario, when i send a UPDATE request, it reaches the
destination (Request-URI) is set to the target.
Case 1 :- Non- Reliable
A (UAC)
Vikram Chhibber wrote:
Andrea, I was in the impression that sending BYE terminates the
session which includes all the dialogs. Can anyone confirm this?
I can refute it. Look at RFC 5057.
Paul
~Vikram
http://www.veraznetworks.com/
On Nov 28, 2007 1:56 PM, Andrea Rizzi [EMAIL
shweta kavishwar wrote:
Hi,
Please verify if this understanding is correct.
Consider the following scenario:
UAC supports session-timer extension UAS dosent.
UAC sends an INVITE request with Session-Expires header Supported:timer.
UAS behavior:
- It either blindly copies the
Huh???
I don't understand what you have in mind.
Paul
Arjun Roychowdhury wrote:
Hi,
I am working on a scenario where Alert-info would be included in an INVITE
request. However, in the same request, I want to bind the 'download'
mechanism of the file pointed to in Alert-Info with the
/MSRP *
.
.
.
a=path:msrp://myurltoringtone:/342sf;tcp
On Dec 1, 2007 2:18 PM, Paul Kyzivat [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I don't see any way to do that. I think you would need either:
- a special URL type, that implies accessing file with MSRP
I agree. In general the To-URI isn't useful for *anything*.
Paul
Sanjay Sinha (sanjsinh) wrote:
Request-uri number
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of SungWoo Lee
Sent: Tuesday, December 04, 2007 12:04 AM
To: Sanjay Sinha
vinodh kumar wrote:
Hi,
User A and User B is in call. User A puts the call on hold now the music is
played to User B(Music on hold).
Invite sent from A to B has media marked as sendonly. Is it mandatory to
have connection IP and port info in SDP sent by A. As the media is sendonly
is
Oh, duh. The * is there among the token chars. I agree with Brett.
Paul
Brett Tate wrote:
I want to know whether the INVITE request having
Require/Supported header with value as * is similar to that
of INVITE request having Require/Supported header with all
the valid option
Vikram Chhibber wrote:
On Dec 11, 2007 12:42 PM, Brett Tate [EMAIL PROTECTED] wrote:
Please confirm my understanding of subscribe for MWI. NOTIFY
should not be sent to a UA unless a SUBSCRIBE has been sent to it.
RFC3265 allows for non-SUBSCRIBE mechanisms to create subscriptions.
Some
It seems I have to say this every few weeks...
*WHY* is the UAC requesting a session timer???
The real purpose of session timer is so that a record-routed proxy can
cause one of the UAs to send periodic messages - confirming for the
proxy that the session is still active. (A proxy isn't
I agree with Nataraju. In general a UA should not be including anything
it doesn't understand it its requests or responses. If a request
contains unknown headers they shouldn't be included in the corresponding
responses.
This is in contrast to the behavior of a proxy, which should be passing
On Dec 12, 2007 6:15 PM, Paul Kyzivat [EMAIL PROTECTED] wrote:
It seems I have to say this every few weeks...
*WHY* is the UAC requesting a session timer???
The real purpose of session timer is so that a record-routed proxy can
cause one of the UAs to send periodic messages - confirming
-E to the response as well.
By your logic, the UAS would have to copy *every* header it doesn't
understand from the request to the response. That would be a very bad thing.
Paul
Vivek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul
[EMAIL PROTECTED] wrote:
Searching for methods in RFC 3840 turns up an oddity: Section 5
says:
When using the sip.methods feature tag, a UA MUST NOT include
values that correspond to methods not standardized in IETF standards
track RFCs.
but two paragraphs later it says:
This is all discretionary, so you can use your best judgment.
My interpretation of the particular case is that the request should be
proxied in parallel to the single best candidate. Of course the with
only one candidate the parallel is moot, but so be it.
Paul
Scott Lawrence wrote:
Why does it matter? AFAIK the phone number in SDP is simply for
documentation, not for automated usage. This is especially the case if
the SDP is being used with SIP.
Paul
shweta kavishwar wrote:
Hi,
Section 5.6 of RFC 4566 says:
Phone numbers SHOULD be given in the form of an
Reading between the lines, this sounds like the goal is for a pbx to
register with a proxy, and then for the proxy to route calls for a block
of numbers to that pbx.
The sip forum addressed this to some extent in a spec known as
SIPConnect. (But IMO they botched it a bit.)
If I have the
, 2008 9:31 AM, Paul Kyzivat [EMAIL PROTECTED] wrote:
If its fully distributed with no central point of control, then
presumably the individual line cards (UAs) become available/unavailable
independently. That seems inconsistent with the desire to have a single
registration enable routing
Santosh
On 1/9/08, *Paul Kyzivat* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
To answer your last question - it can certainly make sense in some
cases. An example is a fault tolerant UA with multiple instances.
In any case it is not the business of the registrar
It is illegal in its naked form. It may be included by escaping it.
Paul
Iñaki Baz Castillo wrote:
Hi, RFC 3261 says:
25.1 Basic Rules
...
Several rules are incorporated from RFC 2396 [5] but are updated to
make them compliant with RFC 2234
...
And RFC 2396
Iñaki Baz Castillo wrote:
Hi, I've configured a UAS to reply with 180 Ringing for 2 seconds and then
with 183 Session Progress containing early-media RPT.
If I call that UAS from some phones (Thomson S203 or Linksys SPA942) I hear
the ring but not the early-media after 2 seconds. In
Theo,
You are right that there are things that *could* be done.
But AFAIK there have been no efforts to standardize this within ietf. (I
believe there has been some work within some other quasi-standards
organizations for SPs.)
I am inclined to agree with Scott that this could be a sort of
Your scenarios below are confusing and incomplete. Its hard to
understand the point you are trying to make. More inline...
Srinivas wrote:
Hi all,
Consider the following scenarios.
1.
C-S: INVITE (for speechrecog)
S-C: 200 OK
C-S: ACK
Now
Harsha. R wrote:
Hi,
Consider the following scenario with regard to session-refresh
INVITE[Min SE:900, (SE:900,refresher=uas),k:timer]
UAC-UAS
183 SP,PRACK(183),200OK PRACK,180 Ringing,
Scott said what I was going to say, but apparently you didn't fully get
his point.
Anybody that you permit to register with your scheme can still put any
ip it wants into the the contact addresses it registers. So you haven't
solved the problem you set out to solve. Having something special in
I think there can be various answers about what should happen in this
case. They would probably be described as different features from A's
perspective.
I know of implementations that hairpin transfers all the time because
that is what the customers want. (E.g. it provides the expected billing
The target-set is derived by a proxy when getting ready to forward a
request. In simple cases there is only one entry in the target-set, the
R-URI of the request or the URI in the top Route header. But if the
proxy translates the R-URI, the result of the translation may be a
target-set with
no matter which way you go.
This is an area that seems deserving of a new draft.
Paul
Thanks,
Praveen Dandin
*/Paul Kyzivat [EMAIL PROTECTED]/* wrote:
This isn't compatible with the current approach because in the
current
approach
has expired at the authenticating server/proxy and so it generates
another nonce and issues a challenge to the sender of that request?
Sanjay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Paul Kyzivat (pkyzivat)
Sent: Monday, January 28
requests.
Thanks for all your help.
-Original Message-
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: 28 January 2008 14:11
To: Steve Langstaff
Cc: SCG2; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Challenging a sendonly INVITE
The question
The question is a little too narrow. The same issues apply to any
in-dialog request.
Steve makes a good point. But practically speaking authentication is
rarely done on in-dialog requests. Bypassing it assumes that the dialog
id is only known to the parties on the signaling path, even though
Scott Lawrence wrote:
On Mon, 2008-01-28 at 15:41 -0500, Paul Kyzivat wrote:
Scott Lawrence wrote:
It helps to understand the problem we were trying to solve. The proxy
may restrict some users to a subset of possible calls - for example, I
might be allowed to make local PSTN calls
[EMAIL PROTECTED] wrote:
It seems wise to send reply MESSAGE containing a user-readable
message. Fortunately, it is almost certain that the UAC processes
MESSAGE requests, and the original MESSAGE has established a route set
for sending the response MESSAGE. In this case, you would want
You are almost correct...
santoshkumar pati wrote:
*Hi All,*
* Can U corect me, If i am wrong*
**
*Assume the UAC receives the SDP (answer_1) in a reliable
18x. After that, is sends eg an UPDATE with a new offer, and receives a new
(answer_2) in the
UPDATE response. Then, INVITE 200
There really aren't any rules for B2BUAs (other than the basic rule that
it must behave as a UA), and its hard to make any because there are so
many different purposes (good and bad) for them. What rules might be
appropriate depend on what the B2BUA is trying to do. In some cases a
B2BUA is
I think the part that is not clearly specified is when the referee may
terminate the subscription. It must send at least one NOTIFY, but I
think it principle it could set the subscription state to terminated in
the very first NOTIFY if it wanted, even though the referred request is
still
Anders Kristensen wrote:
Paul Kyzivat wrote:
I think the part that is not clearly specified is when the referee may
terminate the subscription. It must send at least one NOTIFY, but I
think it principle it could set the subscription state to terminated
in the very first NOTIFY
There was once a draft that discussed this. (I think maybe Rohan Mahy
was the author.) But it was a long time ago and it no doubt expired.
There seem to be many schools of thought about how to handle early
media, so there have been no agreements on how it should work. Among the
issues are:
-
christina,
I'm sorry, but I can't figure out what you are asking below.
If you haven't already, see if
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-06.txt
answers your question.
Paul
christina yuen wrote:
My understanding is
1 if an SDP offer
.
Paul
Alex Zhang
ESN: 6-554-8782
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat
Sent: Monday, March 03, 2008 9:24 PM
To: christina yuen
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] what about
The choice of which response to generate to reject a call is a conscious
decision on the part of the implementer depending on how he wants the
rejection to be perceived by the caller.
A 486 is used when the *goal* is for the caller to be informed that the
callee is busy.
A 480 can be used so
of specs like 3398 is to specify how the sip codes
should be mapped to/from the pstn by gateways, not to specify how other
sip devices should behave.
Paul
Iñaki Baz Castillo wrote:
El Tuesday 04 March 2008 17:02:25 Paul Kyzivat escribió:
If you mean the callee isn't registered in the sip
://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-06.txt
Paul
Alex Zhang
ESN: 6-554-8782
-Original Message-
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2008 11:48 PM
To: Alex Zhang (GDNTRND)
Cc: [EMAIL PROTECTED]; sip-implementors
Dale,
at end...
[EMAIL PROTECTED] wrote:
From: Attila Sipos [EMAIL PROTECTED]
What if you are using something like DNS SRV to route to a
group of gateways? How can one ensure all new requests go the
same gateway?
Why would you want to?
Maybe I wasn't
I agree with you that the definitions of the codes are not entirely
clear. IMO 404 is not an appropriate response for a known and supported
AOR for which no device is currently registered.
Paul
Iñaki Baz Castillo wrote:
El Tuesday 04 March 2008 19:07:14 Paul Kyzivat escribió:
A UAS
[EMAIL PROTECTED] wrote:
Thanks,
So, the UAS can not take for granted that the previous SDP is to be used
for both ways if it just ignores codec3 without terminating the session.
Right?
Once you get outside the valid behavior specified by the standards you
can take nothing for granted.
IMO the default value is always TRUE. If that is inappropriate for a
particular feature then you should provide a value.
Paul
Pavan Kumar Avala wrote:
hi,
I have small doubt regarding RFC 3840.
BNF mentioned in section 9 says that feature-param will have optional
value part.
What do you want to know about them? How they work, or how they are
implemented? Or what?
And for which Cisco products?
Thanks,
Paul
Janu Mukherjee wrote:
Hi All,
I have with me the cisco feature list. In it there are two features like
Calling and Connected Line ID .
other SIP implementor handle such a
case. :)
Thanks a lot.
Alex Zhang
ESN: 6-554-8782
-Original Message-
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 12:00 PM
To: Alex Zhang (GDNTRND)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED
Its not clear what your goals are. Are you making a stack just for an
intermediary?
The key is that if a header is unknown then you can't do any meaningful
processing on it. So if you are proxying you can copy it along and that
is about all. If you are a UAS and you don't know it then all you
You could make the same argument about C or Java. They would (arguably)
be easier to compile if you only allowed whitespace in a much more
restricted set of places.
I think this is more a matter of how the syntax is described, rather
than what it allows. Most parsers that I know of distinguish
Attila,
AFAIK there are no standard rules for how to resolve a tel uri with
phone-context. (You are on your own.)
The context simply defines an abstract namespace within which the local
number is to be interpreted. There are explicit statements that
something of the form
Note that Supported talks about what the *sender* of the message
containing it supports. Require talks about what the *recipient* of the
message containing it (must) support.
For some options its possible that only one side need support the
option. For others that makes no sense. (One where it
Jagan Mohan wrote:
Yes, I agree with what you have said.
But how should be behavior, if the device receiving the refresh request is a
B2BUA?
You can do whatever you want, as long as each side of the B2BUA acts
correctly as a UA. Having session timer running on one side does not
obligate
Any header which uses the repeated field separated by comma format can
be repeated either via the comma for by multiple instances of the
header. It spells this out somewhere in 3261.
In theory I think some form of header that doesn't meet that requirement
might also be allowed to be repeated,
. And they may be escaped in funny ways.
The syntax is the syntax. You can try to fool mother nature, but she
will get you in the end.
Paul
These are exactly the kind of comments I was hoping for!
Thanks,
FM
-Original Message-
From: Paul Kyzivat [mailto:[EMAIL
Frank W. Miller wrote:
You can't really just check for quotes out of context. In some contexts
they might not always come in pairs.
FM: Where does the syntax allow for unpaired quotes? I did a quick search
on 3261 for DQUOT and didn't see any place where they are allowed to be
Frank W. Miller wrote:
-Original Message-
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 3:35 PM
To: Frank W. Miller
Cc: 'Iñaki Baz Castillo'; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Why SIP abnf is so permissive
Yes, of course it can be sent in the PRACK. Its one of the primary
purposes of PRACK.
Paul
[EMAIL PROTECTED] wrote:
Can the SDP answer be actually sent through PRACK? Shouldn't it be sent
in ACK for 200 Ok?
Sanjay Sinha (sanjsinh) wrote:
200 OK to the Prack and then terminate
Joegen
Paul Kyzivat wrote:
Yes, of course it can be sent in the PRACK. Its one of the primary
purposes of PRACK.
Paul
[EMAIL PROTECTED] wrote:
Can the SDP answer be actually sent through PRACK? Shouldn't it be
sent in ACK for 200 Ok?
Sanjay Sinha (sanjsinh) wrote:
200 OK
I agree with Robert.
The following is a more direct answer to your specific question.
Brett Tate wrote:
Greetings,
Concerning rfc3261 and rfc4485 usage of gen-value and quoted-string, are
the quotes considered part of the value during use?
Since I didn't notice a good example within
some text about it, reason=foo ought to be
different than reason=Foo. So are reason=Foo and reason=Foo the
same? Reason=foo and reason=Foo?
Paul
Regards
Ranjit
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat
Sent: Thursday
Brett,
Consider the following:
From: PaulKyzivat sip:[EMAIL PROTECTED]
From: PaulKyzivat sip:[EMAIL PROTECTED]
I can certainly imagine that a stack might receive either of these, and
convert into some internal form that is identical for both. Then when
generating a new request it might
In a word - NO.
This is a policy thing, so you can't assume anything. (The impression
the callee wants to give to the caller is governed by sociology, not
standards.)
Do Not Disturb is a feature, or perhaps a number of different features.
The user of the feature may have his own idea of the
IMO the behavior of OPTIONS - where it is expected to return the same
result as an INVITE would - was short sighted. It is biased toward
INVITE, in that it can't say what a SUBSCRIBE or PUBLISH or MESSAGE
would respond. As you say, probably many UAs don't support this.
Presence is a better way
It is certainly legal to continue retransmitting the CANCEL even though
it will have no effect. A more interesting question is whether it is
legal to suppress retransmissions in this case. From a practical
perspective I see no problem with doing that if you wish.
Paul
[EMAIL
Yes.
Jyoti Parija wrote:
Can we send 180 Ringing after sending 183 session progress?
Thanks,
Jyoti
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
an extended time for
approval before being answered. If that isn't to be the case then there
isn't any issue with using UPDATE.
Note that the issue with immediate response also applies to an UPDATE
used during an early dialog.
Paul
Thnx
-Original Message-
From: Paul Kyzivat
1 - 100 of 926 matches
Mail list logo
