I don't have 2543 committed to memory and am not motivated to go read it
right now. But as Brett says, I think you can get a 180 w/o to-tag from
a 2543 compatible UAS. If you subsequently get a 1xx with a to-tag then
I guess you have two early dialogs. (But I'm not certain 2543 had the
notion
Sameer Sawhney wrote:
Hi Paul,
The draft document talks about procedures to check operational status of SIP
elements which support OPTIONS.
In network, there might be some SIP elements which do not support OPTIONS
and they will respond appropriately with 405 (Method Not Allowed) to
Brett,
Yes, 3261 has all those MUSTs in it. But it was there for 2543
compatibility. AFAIK there is nothing that calls for checking that the
URIs remain unchanged as a requirement for recognizing that the request
is an in-dialog request.
So I think it might be within the letter of the law to
Sagar,
Think of it like declarations in nested scopes in a programming language.
The outer (session level) scope applies except where overridden by a
redeclaration in an inner (media level) scope.
This applies to a lot, but not all, attributes. (The ones that may be
used at both session and
like that, I think you must let the
originating phone live or die by the quality of its REFER implementation.
Thanks,
Paul
M. Ranganathan wrote:
On Tue, Aug 17, 2010 at 4:10 PM, Paul Kyzivat pkyzi...@cisco.com wrote:
M. Ranganathan wrote:
On Tue, Aug 17, 2010 at 9:50 AM, Paul
M. Ranganathan wrote:
On Tue, Aug 17, 2010 at 9:50 AM, Paul Kyzivat pkyzi...@cisco.com wrote:
M. Ranganathan wrote:
Hello,
I am implementing a B2BUA ITSP bridge that bridges a PBX with an ITSP.
In one of the call flows, I get a REFER from the PBX which I have to
convert to an INVITE
$...@r\/|r!`/@ wrote:
Hi All,
Can you please refer me a write up which explains how a proxy handles
transport switching scenarios if required which frwding request.
Can you be more specific about your question?
Each hop is a separate sip transaction. Each must make a decision about
the
Iñaki Baz Castillo wrote:
2010/7/6 Jean-Hugues Royer jhro...@joher.com:
If a subscription and invite usage are sharing a dialog, sending a
refresh SUBSCRIBE with a different contact will cause reINVITEs from the
peer to go to that different contact.
What does it mean a subscription and
Iñaki Baz Castillo wrote:
2010/7/6 Paul Kyzivat pkyzi...@cisco.com:
What does it mean a subscription and invite usage are sharing a
dialog? does it mean two dialog, an INVITE dialog and a SUBSCRIBE
dialog, sharing the same From/to-tags and Call-ID? how could it be
useful such experiment
Adding to what Dale said:
Even in 3gpp, a registration failure should not cause a deregistration.
Rather, state should be the same as if you hadn't done it at all.
So as long as you eventually get it right before the registration
succeeds you should not have a problem.
Of course, if you waited
As has been noted, it can be used in this form to revise the Contact
address, and it may be used to refresh a session-timer. INFO is no good
for either of those things.
It has advantages, over reINVITE, for both of those things in that you
can be certain that there will be no new offer/answer
Arunachala wrote:
Doesn't RFC3960 talk about this very thing?
Yes. I knew that was out there, but didn't remember the number.
Thanks,
Paul
-Arun
On Wed, May 12, 2010 at 1:14 PM, Paul Kyzivat pkyzi...@cisco.com wrote:
Technically, SDP in any 18x only serves to indicate
Technically, SDP in any 18x only serves to indicate where media should
be *sent*, and has nothing to do with whether you should receive media,
play received media, etc.
Nor does receiving a 180 mean you should play local ringback. It merely
says the other end is being alerted. Nor does
, schrieb Paul Kyzivat:
Michael Hirschbichler wrote:
Hi all,
we are currently discussing if it is possible (and - esp. - allowed)
to set both, a Require:- and a Supported:-Header with the
100rel-option in the same INVITE-Request. In my opinion, if 100rel
is set in the Require:-header
Dushyant Godse wrote:
Now UA2 receives re-invite w/ SDP on call leg #1 from UA1. UA1 extracts
SDP from call leg #1 and sends a Re-INVITE to UA2 on call leg#2. At the
same time UA1 sends a re-invite on call leg#2 to UA2. These are part of
session refresh being triggered using re-invites.
https://datatracker.ietf.org/doc/draft-ietf-sipping-sip-offeranswer
neil corcoran wrote:
Hi,
In an established session we receive a re-INVITE with an SDP offer
we respond with a 200 with an SDP answer
and the far end sends an ACK with a copy of the original SDP offer
which is out of the
Brett Tate wrote:
I have some odd test scenario where initial call establishment
happens with
recv only / sendony. After the establishment of the call caller
reinvites
with 0.0.0.0 and direction attribute recvonly. I understand that
this is a
invalid case, but would like to get
Iñaki,
Iñaki Baz Castillo wrote:
2010/4/20 Brett Tate br...@broadsoft.com:
section 5.1.1.1:
If all the Contact header fields in a REGISTER request are SIPS, the
UAC MUST use SIPS AORs in the From and To header fields in the
REGISTER request. If at least one of the Contact header
Avasarala Ranjit-A20990 wrote:
It could be that they did not anticipate the buddy list to very large
one.
Or it could be that they expected that the implementors would support
TCP, as 3261 requires them to do.
Thanks,
Paul
Regards
Ranjit
-Original Message-
Ayesha Shahab wrote:
Hi,
For a non-established dialogs how do we have a 400 Bad Request response ?
The scenario is as follows
1. A sends an INVITE to B
2. A gets 100 trying response
3. A sends lot many OPTIONS towards B
4. B does not respond to the OPTIONS
5. B responds with 400 Bad
Here is the long explanation:
There are two sources of temp gruu information to the UA:
- that which is returned in the response to REGISTER requests
- that which is returned in notifications by the reg event package
Seemingly you wouldn't need the reg event package for this - you can
simply
Iñaki Baz Castillo wrote:
But if the algorithm for constructing temp gruus would be known then
it would become a vulnerability :(
Security by obscurity is never a great choice.
Crypto techniques can largely avoid the vulnerability.
I thought this was discussed in the RFC. (But I'm too lazy
Iñaki,
This is probably far from obvious.
The reason for creating new ones was because for anonymization purposes
you probably don't want to keep using the same one. It would have been
better to have an explicit mechanism to request when you want a new one,
but that didn't fit into the model
Iñaki Baz Castillo wrote:
2010/3/20 Pranab Bohra pranab.bo...@gmail.com:
As per section 2.1 of rfc 3666, the softphone should open the rtp port
to receive early media when the gateway responds with 183 + SDP.
The problem is that some servers/gateways send first a 183 with SDP.
The UAC
Olle E. Johansson wrote:
20 mar 2010 kl. 15.50 skrev Iñaki Baz Castillo:
2010/3/20 Pranab Bohra pranab.bo...@gmail.com:
As per section 2.1 of rfc 3666, the softphone should open the rtp port
to receive early media when the gateway responds with 183 + SDP.
The problem is that some
Iñaki Baz Castillo wrote:
2010/3/20 Schwarz Albrecht albrecht.schw...@alcatel-lucent.com:
It's amazing that such a fundamental session configuration topic is not
really well specified (explicitly, detailed, unambiguous) in RFCs 3261
3264. Just wondering ...
I agree. When such kind of
I agree that it is better to return a 180 if you know that alerting is
happening. Unfortunately, the UAS doesn't always know that. Gateways in
particular may not know.
So the UAC has to be prepared to cope if the 180 doesn't arrive.
Thanks,
Paul
Olle E. Johansson wrote:
20
Iñaki,
Note that specifying a=recvonly gives a receive the video without
sending any. But in that case you are still expected to send rtcp.
If you want to avoid that too, then you should specify c=0.0.0.0.
Thanks,
Paul
Iñaki Baz Castillo wrote:
2010/3/19
KUMARAVEL ANAND-MWCH34 wrote:
Hanifa,
As per RFC 5627,section 3.2, all of the temporary GRUUs learned
from REGISTER responses of a contact remain valid as long a contact with
that instance ID remains registered and the UA doesn't change the
Call-ID in its REGISTER request compared
Actually, Brett gave the best answer.
The lack of response to OPTIONS should not have caused a presumption
that the dialog, or the invite dialog usage, has failed. Lacking some
other failure, the RTP should have continued to flow and the call should
have stayed up.
Once the RTP stopped
E
Paul Kyzivat wrote:
The form of the user part is really the responsibility of the owner of
the domain. user=phone is really only meaningful if the domain owner
allows/supports that. In absence of user=phone, the domain may *choose*
to treat the user part according to tel uri syntax
Premalatha Kuppan wrote:
Hi,
I have some basic question on GRUU (sip extension - GRUU RFC 5627 )
I think that most of your questions are not specifically related to gruu.
1. Can i have multiple devices like mobile phone, laptop etc with sip client
on it and use both the device during the
Holmberg, Gonzalo Camarillo)
Thanks,
Paul
Nancy
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: March-15-10 10:42 AM
To: Nancy Greene
Cc: SIP-implementors mailing list
Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI
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
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
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
The form of the user part is really the responsibility of the owner of
the domain. user=phone is really only meaningful if the domain owner
allows/supports that. In absence of user=phone, the domain may *choose*
to treat the user part according to tel uri syntax, or not.
*if* user=phone is
Attila Sipos wrote:
So this leads me to another question:
What is the practical difference between:
sip:+12345...@domain.org;user=phone
and
sip:+12345...@anotherdomain.org;user=phone
and
tel:+12345678
?
Is it that in the first case, the request gets sent to
If you aren't interested in the NOTIFY, you can use the norefersub
option to bypass the subscription altogether.
Alternatively you could use the information about a failure to alert the
transfering user in some way - display a message, blink, etc. From a
practical perspective, I think a user
(maushah)
*Sent:* Tuesday, February 23, 2010 9:28 AM
*To:* Vinay Pande (vipande); artg-sip-bliss(mailer list); Toleti Danayya
Naidu (naidud); Paul Kyzivat (pkyzivat)
*Subject:* RE: RFC 2833 / RFC 4733 - question on duration 0
Hi Vinay
I think the 3^rd party vendor is going to claim RFC4733
, Paul Kyzivat wrote:
At end...
Aaron Clauson wrote:
-Original Message-
From: Dale Worley [mailto:dwor...@avaya.com]
Sent: Monday, 22 February 2010 4:42 PM
On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
You should be able to do this in a standard way.
First, let us assume
At end...
Aaron Clauson wrote:
-Original Message-
From: Dale Worley [mailto:dwor...@avaya.com]
Sent: Monday, 22 February 2010 4:42 PM
On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
You should be able to do this in a standard way.
First, let us assume that an address of
Roman Shpount wrote:
From/To header should be preserved completely with all of its parameters
to be compatible with RFC 2543. RFC 3261 Section 11.2 Callee Issues
Response says that The response MUST copy the To, From, Call-ID, CSeq
and Via fields from the request. This implies that
Iñaki Baz Castillo wrote:
El Miércoles, 17 de Febrero de 2010, Paul Kyzivat escribió:
AFAIK the contents of that To header are to be generated from dialog
state information. The URI and the tag are part of that state, but other
header parameters from the original INVITE are not, and hence
Brett Tate wrote:
Question is: Should the To in that (re)INVITE
contain ';foo=bar' ???
AFAIK the contents of that To header are to be generated
from dialog state information. The URI and the tag are
part of that state, but other header parameters from the
original INVITE are not, and
I got queried about this when an interop problem popped up.
I know what I think the right answer is, but want to check what others
think.
Here is the case:
Alice calls Bob:
INVITE ...
From: sip:al...@atlanta.com;tag=;foo=bar
this succeeds and a dialog is established.
Then, within
Once the first INVITE has failed, and early dialog it might have had is
gone. The retried INVITE is working toward establishing a new dialog. So
the CSeq values are for that dialog. I think that means the CSeq
numbering should be permitted to restart.
OTOH, if there are any messages still in
To be anonymous with a tel URI, just lie and use somebody else's number.
Or, you could do something like:
tel:0;phone-context=anonymous.invalid
But AFAIK there is no *standard* way of doing it.
Thanks,
Paul
Iñaki Baz Castillo wrote:
El Miércoles, 13 de Enero de 2010, Paul
Iñaki Baz Castillo wrote:
El Miércoles, 13 de Enero de 2010, ROHIT CHAUDHARY escribió:
Hi experts,
A sip-uri with user part as anonymous is allowed. But if the user
parameter is phone, ie, the user part is to be treated as
telephone-subscriber of tel-url (RFC 3966), then should it be
I'm going to get a bit nit-picky here. The text from 3261 says:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to
distinguish telephone numbers from user names that happen to
look like
Rajanikanth wrote:
But in RFC5627(GRUU) it's mentioned that Call-ID can change in register
refresh requests,if UA wants to invalidate temp-gruu.
Can we change call-ID in the register refresh requests?
Sure you can change the callid from one REGISTER request to another. In
that case it is,
Pandurangan R S wrote:
In such a case UAC and NOTIFIER would destroy then SUBSCRIBE
dialog quietly.
NOTIFIER will destroy the dialog as per RFC3265.
But how/why did the UAC destroy subscribe dialog? I think it has to
wait for the NOTIFY.
Now my questions are -
1. Does the proxy server
If your proxy refrains from adding itself to the Record-Route header, it
will not remain in the chain. (You must take overt action to stay in.)
But note this is for *proxies*, not B2BUAs.
Paul
Mihaly Zachar wrote:
Hi Gents,
How is it possible to drop off a SIP chain after the
IMO it would be inappropriate to send a 491 in this case, because it is
not glare, and it is perfectly ok to terminate the dialog. Given that it
has sent the BYE, I *think* it would be ok for S to send a 481 to the
reinvite. (But I haven't scrutinized the state machines regarding this.)
If not
To be charitable, we should assume that the UAC is trying to do the
right thing. So presumably it *sent* the PRACK (which was then lost or
delayed), and then sent the UPDATE without awaiting the reply to the prack.
The UAS can infer from the UPDATE with offer that the 183 was received,
and
sunil.bha...@wipro.com wrote:
Hi,
Say, UAS doesn't have any endpoint configured and will not be able to handle
calls. In this case, should the UAS send a 4xx response, say 408 timeout,
when it receives OPTIONS request, or is it better to ignore the incoming
OPTIONS request and not send
Iñaki Baz Castillo wrote:
Hi, if there any *real* case in any SIP core (i.e: IMS) in which a user could
have a URI with parameters?
Usually it doesn't occur as any network/provider users have an identifier
like:
- sip:al...@domain.org
- tel:+12345678
However I wonder if there is
Iñaki Baz Castillo wrote:
El Martes, 1 de Diciembre de 2009, Paul Kyzivat escribió:
So, is there any SIP core in which such URI's exist for its users?
Of course they COULD exist, however I want to know if they *really*
exist :)
I'm curious why you ask.
Are you considering
Mayank Gupta wrote:
Hi Ritul
Is there any significance of this additional message for INVITE?
ACK for initial INVITE request makes sense as it may be useful for
offer-answer when initial INVITE is without SDP and offer is received from
called party in 200 OK. In that case ACK will send
Brez Borland wrote:
Hi all,
Below I assume using tcp transport for registrations.
As I understand, while using a reliable transport for dialogs the
connection between UAC and the next hop is active until the dialog is
terminated by one party sending BYE and another party responding
Victor Pascual Avila wrote:
On Tue, Oct 13, 2009 at 11:12 AM, Jin-Soo Eo jinsoo...@samsung.com wrote:
Hello,
I would like to know how to reuse Server Connection other than
mentioned in draft-ietf-sip-connect-reuse-03.
I think most SIP entities do not support draft-ietf-sip-connect-reuse-03
David Benoit wrote:
On Fri, Oct 02, 2009 at 04:22:55PM -0400, Dale Worley wrote:
On Thu, 2009-10-01 at 10:37 +0200, DE CLERCQ Johan wrote:
As we all know, in ISDN you can detect when you go to a voicemailbox of
a cellular line by looking for the PROGRES message as defined in Q.931.
There is
To elaborate:
There is no standard for DTMF over INFO.
The usages that exist in the wild are *proprietary* though you may find
some commonality. If you need to use this to interoperate with
something, do whatever your peer expects.
Thanks,
Paul
Avasarala Ranjit-A20990 wrote:
Alex Balashov wrote:
I cannot easily tell from 3261 whether references to URIs other than the
Request URI must be encased in and or not, probably because I do
not know how to read BNF.
If you are involved in SIP, or almost any IETF protocol, then I strongly
suggest that you *learn* to
Yong Xin wrote:
Hi,
The RFC3261 is clear that UA can not send a re-INVITE when another
INVITE is pending. However, for non-INVITE request (e.g.: INFO), I was
not able to find any restriction like this. So I assume this is allowed.
However, sending another INFO before the previous one
a=.) change?
As the recipient, you *don't* distinguish a HOLD request from a non HOLD
one. You simply take things at face value without attempting to ascribe
a reason for *why* they have happened.
Thanks,
Paul
Regards
Ranjit
-Original Message-
From: Paul Kyzivat
Avasarala Ranjit-A20990 wrote:
no it should not. For a Hold request, you do not send any media
capabilities. U only change the existing media description lines to
indicate HOLD.
I beg to differ.
Technically there is no HOLD request.
All there is is an offer that offers to change a media
.
I think this is a problem for RFC3264.
What do you think about this reINVITE ?
I'm not seeing what the problem is.
Thanks,
Paul
Regards,
Shinji
Paul Kyzivat pkyzi...@cisco.com
Rockson Li (zhengyli) wrote:
Paul,
If I catch you clearly, do you mean this is a real bug
soma bhargava wrote:
Hi All,
As per RFC 3261
sec 8.2.2.3 Require:
An ACK request for a 2xx response MUST contain only those Require
and Proxy-Require values that were present in the initial request.
I think that is less than ideal wording.
It would have been better worded as:
An ACK
Bhaskar Dutta wrote:
I had a doubt on History-info header present in Sip 18x Responses.
Are the History-info headers UAC received in 18x response useful to an
application or user ?
If yes can you please quote an example where its useful to an
application/user .
This is entirely
Dale Worley wrote:
On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
Additional round trips should be made optional (only for implementations
having concurrent codecs limitation).
Additionally, why can't the spec be modified (or place in a BCP):
1. to allow only a sub-set
comment at end.
Dale Worley wrote:
On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote:
I think answerer can add additional codec G729 here per sec 6.1 of
rfc3264
snip
The stream MAY indicate additional media formats, not listed in the
corresponding stream in the offer,
vijay wrote:
Hi,
a snippet from 3311:
If a UA receives a non-2xx final response to a UPDATE, he session
parameters MUST remain unchanged, as if no UPDATE had been issued.
Note that,
as stated in Section 12.2.1 of RFC 3261 [1], if the non-2xx final
response is a
481 (Call/Transaction
ALG's use this method to see the availability of the UAS.
Its reasonable for checking general availability of the UA, assuming of
course that you know the URI of the UA, rather than just of the AOR.
Thanks,
Paul
BR,
Manoj
-Original Message-
From: Paul Kyzivat
Manoj Priyankara [TG] wrote:
Dear All,
According to the RFC 3261, SIP OPRIONS message should be used to query
the statue of other UAC or the UAS. Is it OK to use the OPTIONS as a
keep alive message to know whether the UAS is alive?
Is it necessary to send the OPTIONS message from a
I just saw this thread. Thanks Mikael for your response. Its the best
one available for this case, assuming (as the original poster has
confirmed) that this is all one dialog.
If there is early media flowing, you probably don't want to preempt it
with a generated ringback. But if there is no
Olle E. Johansson wrote:
6 aug 2009 kl. 12.49 skrev Vivek Batra:
Greetings,
I am wondering if the below scenario is valid or not.
-- 183 (with SDP) then,
-- 180 (without SDP)
Yes it's.
However it depends in UAC behaviour on how to render it to the human
(it could choose to render the
Rajani wrote:
In SDP body for each media line we have its media attribute values set below
the media line. Each of them have default values if its not mentioned
explicitly in the body..
If an offered media stream is
listed as sendrecv (or if there is no direction attribute at the
Brett Tate wrote:
Race conditions exists (although not likely to occur) where the remote
party's Contact may be updated between sending requests again with update
auth headers. Depending upon loose routing usage, this can impact Route
header or request-uri (see rfc3261 section
I can understand how you might dislike the unusual way that forking of
subscribes is handled. It is a special case. It was done that way
because there was a desire to support forking of subscribe, and also a
desire not to institute a transaction state machine for subscribe (akin
to the one for
friend friend wrote:
Dear somesh,
In hold condition, i set the media ip address as 0 and i set the
attribute as send only.
is this enough? am not setting the port as 0.
and could you please tell me, when shall i use Inactive and send only
please advice me.
please read
Manoj,
Virtually none of the terms you use below have well defined meanings in
sip standards. Many people use such terms, but AFAIK there are not well
understood and consistent implementations for them. So it is not
possible to answer your question as posed.
Tell us whether your SS and IP-PBX
Sreenath,
I'm puzzled by how you are asking this question.
In general the form of the user part of a sip URI should only be of
concern to the owner of the domain of that URI.
So in sip:VoiceMail;userparam=12...@wcom.com,
it is up to the owner of wcom.com to decide which user parts it is
Linking of registration to authorization of sessions is an IMS concept.
You will need to ask this question in some IMS forum.
As far as IETF is concerned, the presence, coming, or going of
registrations has *no* bearing on extablished sessions, or on the
ability to establish new sessions.
There is nothing wrong with that as long as wcom.com is happy with it.
Regards,
Paul
Sudhir Kumar Reddy wrote:
Hi All,
Can I consider following request-uri?
INVITE sip:VoiceMail;userparam=12...@wcom.com SIP/2.0
any response is highly appericated
Thanks in advance
Iñaki Baz Castillo wrote:
Thanks for so great explanation.
However, I wonder why so many new features are needed when most of the
devices
don't implement XCAP yet. The fact I don't consider useful all the new
features described above. Is it really implemented somewhere?
I suspect the
Certainly things of this sort could be useful.
At least for now such things are in the realm of products rather than
standards-based stuff.
Blocking of call delivery based on presence status does require a
significant degree of trust in the accuracy of the presence status. When
in doubt I
Victor Pascual Ávila wrote:
Hi Paul,
thanks for your comments. See responses inline.
2009/6/11 Paul Kyzivat pkyzi...@cisco.com:
There is really no particular value in using session timers in this case.
Session timer is for the benefit of record-routed proxies.
Since session timer works
This special treatment for call waiting has always baffled me.
It seems to be rooted in the telco partitioning of services rather than
on any fundamental difference.
Specifically, from a caller perspective, how is a call handled via call
waiting at the callee any different from the call ringing
Agree with Attila. So in the given circumstance the UAS could have
responded to the invite with a 488 to indicate that it didn't support
the offered media.
Another possibility is for the UAS to return an answer where the port in
the m-line is zero, thus rejecting the media stream since it
Iñaki Baz Castillo wrote:
El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió:
Specifically, from a caller perspective, how is a call handled via call
waiting at the callee any different from the call ringing on a phone
with two lines where the other line is in use? Why should the caller
Iñaki Baz Castillo wrote:
El Jueves, 11 de Junio de 2009, Paul Kyzivat escribió:
In one case I have a single phone with one phone number. Typically if a
2nd call comes in while phone is in use it is signaled to the callee in
the media stream rather than through ring. To switch between calls
Iñaki Baz Castillo wrote:
El Miércoles, 10 de Junio de 2009, Dale Worley escribió:
And a UAC might want to display the reason phrase, so you could use
Do you mean that the UAC could display the reason phrase in *English*? IMHO a
standarized code or string should be needed for this instead
Iñaki Baz Castillo wrote:
El Miércoles, 10 de Junio de 2009, Paul Kyzivat escribió:
Actually, *in theory*, you can put Accept-Language:es into your INVITE,
and then the text messages in the response ought to be written in Spanish.
(And of course everybody's SIP implementation does
,
Paul
Thanks and regards,
Shamik Saha
Project Engineer
Voice Protocols
Cell : +91-9886704155
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: Thursday, June 04, 2009 9:05 PM
To: Attila Sipos
Cc: Shamik Saha (WT01 - Telecom Equipment);
sip
This discussion has all assumed MESSAGE.
If you want to send big messages, use MSRP.
Then they can be as big as you like. Multi-GB messages were considered
when designing it.
Paul
Victor Pascual Ávila wrote:
Iñaki,
On Fri, Jun 5, 2009 at 11:56 AM, Iñaki Baz Castilloi...@aliax.net
A significant limitation in what you propose is that it requires Bob to
have a public key that Alice knows. In general we don't find that to be
the case in most telephony applications.
Thanks,
Paul
Vadim Lebedev wrote:
I see,
Well this particular attack could be prevented by
Good answers.
Also look at
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-10.txt
Paul
Attila Sipos wrote:
yes, the call flow is fine.
But I can understand why you are confused.
The important part is this:
For this specification, that is
It wasn't stated who is doing the reinvite, and that can make a difference.
Also, there is nothing special about a reinvite used for session timer
refresh vs any other reinvite. Only the sender of the reinvite knows why
it was sent, and reinvites that are primarily for some other purpose
also
I would just put a different spin on this without changing the facts:
If you *don't* terminate the subscription with your NOTIFY, then by
definition it is not the last NOTIFY, because the subscription still has
to be terminated sometime, and that will entail a NOTIFY.
So, if you sent a NOTIFY
501 - 600 of 926 matches
Mail list logo
