cool goose wrote:
Thanks All for pointing me towards some resources. I have never written any
protocol stacks before except for few small SIP tools. This would be my
first time writing a SIP stack and that's where I felt a need for some
literature or books on designing protocol stacks.
A plausible case is when the call is forked, and there are 180 responses
from multiple forks. The UAC may then be able to determine from the
answer SDP that one of the early dialogs is undesirable - lacks features
it wants. So it sends a BYE to that one while allowing the other to
continue
I agree with Dale. In addition, having the UAC do it this way makes the
downstream behavior the same whether the recursion on the 300 is done by
the UAC or by a proxy on the path.
Thanks,
Paul
Dale Worley wrote:
On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera
bahan...@hotmail.de wrote:
Hi,
I am sorry. Same Email with Subject.
I am newcomer in SIP and Kamailio Wold an have a question.
I have two IP Telefones and would like to realize with Kamailio
What is Kamailio?
an IP Communication. The Problem:
a. The UA 1 calls UA 2
b. UA 2
Dale Worley wrote:
On Tue, 2009-05-12 at 08:47 +0200, Damir Reic wrote:
If UAS receives BYE on early dialog and answers it with 200OK, does it have
to respond to initial invite with 487 (same as CANCEL was received)?
In RFC 3261 section 15.1.2, it says:
The UAS MUST still respond to
A callee capability of isfocus on the contact header field of the far
end tells you that it is a conference focus. E.g.
Contact: sip:al...@atlanta.example.com;isfocus
Paul
wen ren wrote:
hi, all
recently I am implement some complex features about conference. usually
the
Its also possible for the proxy to recurse on some of the alternatives,
and then return a 300 containing some that it chose not to try itself.
But an all-or-nothing approach by the proxy is much more likely.
Thanks,
Paul
Iñaki Baz Castillo wrote:
El Miércoles, 6 de Mayo de
Iñaki Baz Castillo wrote:
2009/5/5 Bob Penfield bpenfi...@acmepacket.com:
If there are no binding remaining, the 200 OK does not need to have a
Contact header. A 200-OK response without any Contacts indicates that there
are no bindings.
Please Bob, read the *oficially* reported bug
Iñaki Baz Castillo wrote:
2009/5/5 Paul Kyzivat pkyzi...@cisco.com:
Iñaki Baz Castillo wrote:
Please Bob, read the *oficially* reported bug about this subject which
had a long discussion some time ago:
http://bugs.sipit.net/show_bug.cgi?id=775
I agree with Bob that there is no bug
Krishna Rao Gurram wrote:
Scenario:-
UAS receives Invite with SDP.
Application above UAS sends 100 Trying
Application now sends 180 without SDP and with 100 rel.
UAS receives PRACK with SDP for 180.
Here what is the behavior of UAS? How to
This isn't really the best place to discuss the logic behind IMS
designs. While I have some knowledge of that, I'm not actively involved,
and I find much of what is there to be strange.
Good Luck
Paul
Dushyant Dhalia wrote:
Paul Kyzivat wrote:
Dushyant Dhalia wrote
In a topology such as shown below, you don't need an extra media relay
to enforce your billing - you have the gateway, which is already
terminating the media. Why aren't you doing the billing there?
Paul
Iñaki Baz Castillo wrote:
2009/4/29 Alex Balashov abalas...@evaristesys.com:
Dushyant Dhalia wrote:
In 3GPP specs, related to IMS procedure, it's written that P-CSCF sends
the SUBSCRIBE request to I-CSCF which in turns finds the address of
S-CSCF through Cx query. My question is why can't P-CSCF send the
SUBSCRIBE directly to S-CSCF using Service-Route it received
I disagree with the notion that you should include C-T:application/sdp
and C-L:0 to indicate no offer. In fact, I think it is probably invalid
to do so.
There are at least a couple of issues with that:
- If you specify a C-T, then the body needs to conform to the
specification for that type.
These are interesting cases. I think they go beyond what is specified,
and hence are subject to creative implementation, which in this case is
probably a bad thing.
I agree with the opinion that this should be treated much like an
INVITE. In particular,
- the request should be routed to a
Castillo i...@aliax.net:
El Martes 14 Abril 2009, Paul Kyzivat escribió:
I think you are missing that there can be multiple publishers of
presence *about* Alice that are themselves *not* Alice. So:
1) they can't assert that the publish is from Alice, because it isn't
2) they can't address Alice's
shamik.s...@wipro.com wrote:
Hi Brett,
In section 4 it is said that
Dialogs come into existence along with their first usage. Dialogs
terminate when their last usage is destroyed. The messages that
create and destroy usages vary per usage. This section provides a
Neel Balasubramanian wrote:
[Neel]
Malformed values typically be treated as 3600 and not as 0.
First, we generally don't specify what is done for invalid cases.
(If we did, in effect we would be extending the spec to that case and so
it would be valid.)
But IMO it makes sense in cases like
I thought the inquiry was wrt the Expires header, not the expires header
parameter. The text in 8.3 seems to be talking about what to do if the
value of the expires parameter is malformed. And that only applies to
use in Contact, and perhaps only for use by redirect servers.
So for instance I
I think you are missing that there can be multiple publishers of
presence *about* Alice that are themselves *not* Alice. So:
1) they can't assert that the publish is from Alice, because it isn't
2) they can't address Alice's presence server because they may not
know it. They just know
[mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: woensdag 8 april 2009 1:06
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] DTMF tones
El Miércoles 08 Abril 2009, Paul Kyzivat escribió:
forget negotiation. Look
Iñaki Baz Castillo wrote:
El Martes 07 Abril 2009, Scott Lawrence escribió:
How is possible a RFC (2976) not being a a standard and a draft being it?
That RFC only defines the INFO method, but not how DTMF or anything else
is transported using that method:
The definition of the
inline
Klaus Darilion wrote:
Hi all!
RFC 3261 explicitly allows the having multiple contacts in a single header.
7.3: ... Specifically, any SIP header whose grammar is of the form
header = header-name HCOLON header-value *(COMMA header-value)
allows for combining header
Iñaki,
I don't think anyone is saying that you must implement your UAC to use
this capability. If your UAC has nothing where this is useful then it
need not bother.
But your UAS and Proxy should support it. And its not like its any huge
burden to do so. Others see value in this, and if they
Iñaki Baz Castillo wrote:
El Lunes 06 Abril 2009, Brett Tate escribió:
The following was one of the threads:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020062
.html
Read sections 12.1 and 12.1.1:
Within this specification, only 2xx and 101-199 responses with a
why do you find that crazy?
Paul
Iñaki Baz Castillo wrote:
El Sábado 04 Abril 2009, Attila Sipos escribió:
For exmaple, set up call with INVITE.
Then the other end can use the same dialog to
subscribe to your DTMF key presses (using kpml).
Subscription for DTMF key presses ???
-conforming. It should have failed the request since
it didn't support the required path option.
Paul
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: 01 April 2009 17:06
To: Attila Sipos
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip
+1
Michael Procter wrote:
Scott Lawrence wrote:
On Thu, 2009-04-02 at 10:03 +0100, Stephen Paterson wrote:
Hi all,
Thanks for your replies. Lots of answers saying I'll only get a single
200. Sorry, bit of a slip on my part there! Ignore the '200/' and you'll
get my meaning.
Anyway, just to
Dale Worley wrote:
On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
I'm currently implementing RFC 3265 as an abstract layer upon which our
customers can build their own event packages and I'm trying to determine
exactly what information their applications will need in order to
#272;ani Vladislavi#263; wrote:
Hi,
could you help me ragarding the question marked with asterixes in
attached file where call flow scenario is described. The questions are
from MGCF point of view.
So I gather the MGCF is a B2BUA, right?
1st (*) Is it allowed to receive any SDP in
Singh, Indresh (NSN - US/Boca Raton) wrote:
IMHO,
I agree with Somesh that 200 OK seems the right response to generate. As
the objective of the UA sending the un-REGISTER request was to remove
the binding on the registrar and since the registar knows about the AoR
but does not have any
Brett Tate wrote:
Question is have Linksys any reason to not send second PRACK
after 401 unauthorized?
No. However RFC 3262 has some wording issues concerning rejecting PRACK.
Some vendors interpreted RFC 3262 as though a PRACK must be accepted and
failure responses like 401 and 488
Hadriel Kaplan wrote:
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Thursday, March 12, 2009 5:59 PM
What to do with the SIP URI host part?
They're gone.
A A ANEES-RJD876 wrote:
All
As part of implementing RFC 3959 (early session) I am trying to
understand what interactions this feature has with preconditions as
described in RFC 3312. RFC just mentions and provides a reference to RFC
3312 but does not provide any details.
I
Andrea Rizzi wrote:
On the other hand, RFC3966, Section 12 says:
When the '+' sign is not present, but a telephone number is
represented by the user portion of the URI, the SIP URI SHOULD
contain the optional ';user=phone' parameter; e.g.,
To: sip:83...@sip.example.net;user=phone
syntax.
Thanks,
Paul
Andrea
-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
Sent: mercoledì 21 gennaio 2009 17.29
To: Andrea Rizzi
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] user=phone usage in SIP trunking gateways
It could have been stated better in 3261 so that it would apply in all
cases, rather than only in the named cases.
The basic rule should be that when there is an ambiguity in the grammar
around the parsing of an addr-spec (as to whether the ',' ';' or '?' is
part of the addr-spec or part of
-boun...@lists.cs.columbia.edu] On Behalf Of
Scott Lawrence
Sent: Wednesday, January 07, 2009 9:47 PM
To: Paul Kyzivat
Cc: Sip-implementors@lists.cs.columbia.edu
mailto:Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] How to determine where to send
erol turac wrote:
how can proxies edit c line in sdp? which rules can be applied to c line by
proxies?
I have a sip client behind nat which insert its own private IP at session
level (c line under m line)
and NAT adds its own public IP into c line at media level before forwarding
200 OK
What Scott says seems reasonable. In his case, if the feature is turned
off it really is a proxy. If the option is turned on, and SDP is
updated, then the best you can say is that it is a proxy with
non-compliant behavior.
Thanks,
Paul
Scott Lawrence wrote:
On Wed, 2009-01-07
Timer values must be the same on both ends of any given transaction. So
choosing different values is only an implementation option if you know
you will be implementing both ends. So it isn't a good answer to the
question Dale is raising.
Thanks,
Paul
Neelakantan
I don't understand why stateless forwarding has been mentioned in the
context of this question. AFAIK it has no relevance.
If we assume that the pcscf in the question is a transaction stateful
proxy (and I'm pretty certain that any IMS implementation would be),
then when the 200 INVITE is
pravin.sw...@wipro.com wrote:
HI.. All,
In the below scenario Is offer /Answer Still required Even if its
completed in INV 180 ??.
Understanding Early Dialog Establishment is it right way to send PRACK
request response without SDP. ??
UAC UAS
The problem here is that you have a device that is trying to charge, but
controls nothing to enforce its charging. If it wants to charge, then it
ought to have something (e.g. the media stream) that it can turn off
when the call terminates. Then there won't be fraud.
If the proxy doesn't
Iñaki Baz Castillo wrote:
2008/12/18 Paul Kyzivat pkyzi...@cisco.com:
The problem here is that you have a device that is trying to charge, but
controls nothing to enforce its charging. If it wants to charge, then it
ought to have something (e.g. the media stream) that it can turn off when
Yes, or course it can be there.
Don't assume that because you sent it once you don't need to send it
again. There is nothing that says any of the Allow-* or Accept-* headers
are scoped to a dialog. How long the commitment is to honor one of these
headers is unspecified. So you had best put
You are tying this to the GW because the GW has a cost to you?
If so, then why isn't it the GW that is generating the accounting?
Or are you saying that you are routing the call to a GW, not controlled
by you, that will bill you? And you want to generate your own accounting
so you can bill back
Iñaki Baz Castillo wrote:
El Jueves, 18 de Diciembre de 2008, Paul Kyzivat escribió:
You are tying this to the GW because the GW has a cost to you?
If so, then why isn't it the GW that is generating the accounting?
Or are you saying that you are routing the call to a GW, not controlled
Iñaki Baz Castillo wrote:
El Viernes, 12 de Diciembre de 2008, Paul Kyzivat escribió:
There are a few uses that I know of:
1) to forcibly *unregister* a device. For instance, you have a device
registered from work, and then you go home without turning it off.
From another suitable
The B2BUA has the burden of making things right here, and as shown it
did not. It should only be adding the Supported:100rel if it has a
workable strategy for generating PRACKs, because it is the element
responsible for doing so.
Its true that the offer in the 18x then requires an answer in
Dale Worley wrote:
On Fri, 2008-12-12 at 11:34 +0530, tamal.bis...@wipro.com wrote:
What is the expected behaviour is a user calls himself ?
Should the called handle the Invite and call should get established
Or cancel should be send or else some error response can be set.
Some UAs will
Dale Worley wrote:
On Wed, 2008-12-10 at 13:32 +0530, Nabam Serbang wrote:
1) If the offer being presented in 2xx (200 OK) for INVITE is not acceptable
by UAC, what would be the valid answer in that ACK? Remember this not
re-INVITE which will have prior SDP.
No doubt you can take the SDP
Maxim Sobolev wrote:
Paul Kyzivat wrote:
Dale Worley wrote:
On Wed, 2008-12-10 at 13:32 +0530, Nabam Serbang wrote:
1) If the offer being presented in 2xx (200 OK) for INVITE is not
acceptable
by UAC, what would be the valid answer in that ACK? Remember this not
re-INVITE which
I agree with all Dale has said on this.
Adding to that - it is also possible that there is *another* device that
is sending register or unregister requests for the *same* contacts as
your UA. Its not a *likely* scenario in most cases, but it is
*possible*. This can lead to all sorts of odd
Yes, it would be possible to do as you suggest. But I think there would
be very little priority to doing so.
In the absence of a suitable specific header, an 400 is what you are
left with. If you combine that with a specific reason-phrase that
identifies the issue, then at least it will be
[EMAIL PROTECTED] wrote:
From: Naarumanchi Kaushik [EMAIL PROTECTED]
According to RFC 3680, when a user subscribes for reg event package, he
would receive notifications for any state change in the registered contacts
under that AOR.
If an AOR is registered with multiple
inline.
kaiduan xie wrote:
Hi, all,
Consider the following case, what are the right values in SDP in INVITE/200?
A B
|INVITE/SDP1|
|--|
|200/SDP2 |
|--|
|ACK |
Iñaki Baz Castillo wrote:
Hi, in case of an INVITE with no SDP, how should the request indicate what it
wants? I think it should include an Accept header:
Accept: Application/sdp
Yes. But I think you can omit it, because any UA that supports INVITE
must support sdp.
But I wonder if
Johansson Olle E wrote:
3 dec 2008 kl. 21.58 skrev Iñaki Baz Castillo:
El Miércoles, 3 de Diciembre de 2008, Paul Kyzivat escribió:
Iñaki Baz Castillo wrote:
Hi, in case of an INVITE with no SDP, how should the request
indicate
what it wants? I think it should include an Accept header
Neelakantan Balasubramanian wrote:
See below.
Thanks,
Neel.
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Iñaki Baz Castillo
[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 9:31 AM
To: sip-implementors@lists.cs.columbia.edu
Subject:
,
Paul
-Thanks
R.Kamath
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
kaiduan xie
Sent: Thursday, December 04, 2008 3:33 AM
To: Paul Kyzivat
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] two-way hold/resume
Yes, I agree with you. This has been discussed before on one of the lists.
You can forget all the B2BUA issues and just view the B2BUA as a UAS
interacting with A, and ask if what it is doing is valid, without regard
to why it is doing it.
In addition to the reasons you have given, if the SDP
, and the governing rule
regarding provisional responses is that they must be forwarded to the
originator.
RFC 3261 says nothing about a special status of a 183.
I think one of the things Paul Kyzivat said is probably the most
reasonable conclusion: If it wants to be less transparent, it
can just
Alex Balashov wrote:
Paul Kyzivat wrote:
Alex,
If I understand you, you are arguing that either:
- proxies shouldn't fork at all, or
- proxies should violate 3261 by not forwarding
some provisional responses when forking.
In the description, the proxy is acting exactly as it should
Hadriel Kaplan wrote:
-Original Message-
From: Alex Balashov [mailto:[EMAIL PROTECTED]
Sent: Friday, November 28, 2008 8:51 PM
I should add here that yes, creating multiple early dialogs works around
that problem, but I would think it is implicit in the general formula of
the results,
but without sucess yet. I don't know what exactly I have to change,
but I'm trying.
Try fixing the o-line.
Paul
On Wed, Nov 26, 2008 at 5:00 PM, Paul Kyzivat [EMAIL PROTECTED] wrote:
Looking at your messages, I see:
- at cseq 2, an initial invite offering a bunch of codecs
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
(with CSeq n+1) arrives
first, then when the first subscribe (with CSeq n) arrives it will be
less than current and hence cause a 500 response.
Paul
Thanks
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat
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
Channa
On Wed, Nov 19, 2008 at 7:46 PM, Paul Kyzivat [EMAIL PROTECTED]
mailto:[EMAIL
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.
The sip controlling protocol rules require that the o/a be completed
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 domain in the
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)---
*
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 send a message such as the above within
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 special
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
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
more special data into the request.
Are there other
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 of any
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 responses
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 be right?
Thanks
Subbu
On Thu, Oct 30, 2008 at 8:30 AM, Paul Kyzivat
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 we need
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 not.
On Fri, Oct 24, 2008 at 8:26 AM, Paul Kyzivat [EMAIL PROTECTED] wrote:
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
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 changed,
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/Misuse)
I agree with Paul
I think the call must not be rejected.
As per 3261 we
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
originator and recipient
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 the
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 TEL URI:
Section 5.
SUBSCRIBE messages also contain logical identifiers
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
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 unique
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,
We have a client that sends multiple registrations.
All of the registrations have the same Call-ID and and incremented CSeq.
So
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 in
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 why all the SIP TCP phones I've tryed
behind NAT
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]
Contact: sip:[EMAIL PROTECTED]
Contact: sip
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:
REGISTER sip:example.com
To: sip:[EMAIL PROTECTED
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 RFC
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
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
Iñaki,
While many pbxs (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]:
Hello,
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
601 - 700 of 926 matches
Mail list logo
