On Tue, 2009-10-20 at 09:33 +0200, Victor Pascual Avila wrote:
> Well, while here the usage of the From and To HF is basically done for
> backwards compatibility with RFC2543, (in the absence of other
> mechanisms) they are normally presented as "Caller ID" by a
> human-readable user interface; th
On Mon, 2009-10-19 at 23:52 +0200, Iñaki Baz Castillo wrote:
>
> Ways to solve this vulnerability:
>
> a) The proxy requires From username to match credentials username.
It turns out that enforcing that too strictly breaks a lot of call
forwarding and third party call control flows.
> b) The pr
On Mon, 2009-09-28 at 16:05 +0530, Thomas george wrote:
> Hi,
>
> In case the Authentication takes more time for a SUBSCRIBE request,
> Can I first send 202 response to the SUBSCRIBE request and later send 401?
No - proxies will not forward the second response because the
transaction is complete.
On Mon, 2009-08-31 at 12:31 -0400, Scott Lawrence wrote:
> On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli Srikanth-A19563 wrote:
> > True, UDP flow may not be required if TCP flow has been setup to route
> > incoming traffic towards UA. But Won't it be an additional bonus if
On Mon, 2009-08-31 at 22:33 +0800, Vavilapalli Srikanth-A19563 wrote:
> True, UDP flow may not be required if TCP flow has been setup to route
> incoming traffic towards UA. But Won't it be an additional bonus if UA
> creates a UDP FLOW in addition to TCP FLOW, so that network can still
> reach the
On Mon, 2009-08-31 at 15:54 +0530, shyam wrote:
> Hi All,
>
>
>
>Can I simulate the below call flow using SipProxy Server (Partysip or
> siproxd).
>
>
>
> CSCF PROXY AS
>
>
> <--INV---
>
On Fri, 2009-08-21 at 09:52 -0400, Alex Balashov wrote:
> Greetings,
>
> I occasionally get questions about a use of REFER that I can't answer.
>
> They revolve around handing a call leg "back" to the proximate UA whence
> it came after some portion of the call completes. For example, imagine
On Wed, 2009-07-29 at 17:33 +0200, Iñaki Baz Castillo wrote:
> 2009/7/29 Scott Lawrence :
> >> Does it mean that you system doesn't allow nonce reuse?
> >
> > No... but only reuse within a single dialog.
>
> In a proxy (not dialog aware) it would be impossib
On Wed, 2009-07-29 at 16:52 +0200, Iñaki Baz Castillo wrote:
> 2009/7/29 Scott Lawrence :
>
> > Not with our system (sipXecs).
> >
> > In order to make replay attacks more difficult, the nonce that sipXecs
> > returns is cryptographically bound to the call-id and t
On Wed, 2009-07-29 at 16:13 +0200, Iñaki Baz Castillo wrote:
> Wow! what could I reply now...?
(I keep that reply around in canned form - it comes up now and then)
> Ok, if it would be a "MUST" you'd convince me XD (joking)
>
> However, it'd also work even if the client uses a different
>
On Wed, 2009-07-29 at 15:48 +0200, Iñaki Baz Castillo wrote:
> 2009/7/29 Scott Lawrence :
> > A 4xx response does not create a dialog, so the retry of the INVITE with
> > credentials is a new request.
> >
> > It should however, use the same call-id and from tag that the
On Wed, 2009-07-29 at 15:39 +0530, Krishna Rao Gurram wrote:
> Hi,
> Our call scenario involves the following exchange:
> INV->
> <- 401
> ACK ->
> INV With Credentials in Authorization header ->
>
> Please let us know if in this scenario,
> Is it correct to use the same Request URI from the initi
On Mon, 2009-07-20 at 16:37 +0200, Iñaki Baz Castillo wrote:
> 2009/7/20 Michael Procter :
> >> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
> >> OK to the initial SUBSCRIBE, that's all.
> >> Of course, the Contact in the NOTIFY from the server are equal.
> >
> > Not exact
On Mon, 2009-07-20 at 10:20 -0400, M. Ranganathan wrote:
> Hello
>
> I have a question about how to re-originate a request for an in-dialog
> challenge. For example, if a re-INVITE gets challenged, when sending
> the new request with credentials, would it be correct to just clone
> the old route (
On Wed, 2009-07-15 at 09:18 +0300, Valentin Nechayev wrote:
> Hi,
> RFC2617 defines the following rule to extract header values for
> calculating response:
>
> ===
> The notation unq(X) means the value of the quoted-string X without the
> surrounding quotes.
> ===
>
> and later e.g.:
>
> ===
>
chandan kumar :
> > Could any clarify what does HOP do in SIP?
> >
> > whether HOP is related to a register request or Call request?
> >
> > Issue faced : Phone comes up & tries to regsiter to the server.Lets say the
> > server is not available.So registration fails .Now I will try to make an IP
On Tue, 2009-06-16 at 10:34 +0200, Pascal Maugeri wrote:
> Hi
>
> I'm investigating the possibility for the kamailio proxy we're using to send
> periodic NOTIFY requests to clients for NAT traversal.
>
> Reading the RFC3261, it is not clear what a SIP UAS must/should do when a
> such NOTIFY is re
On Thu, 2009-06-11 at 14:41 -0500, Brad Johnson wrote:
> The scenario I am talking about is when multiple phones behind our proxy
> are registered to an external registrar. Our proxy rewrites the
> registration Contacts from the phone's private address:port to a public
> address:port on our prox
On Thu, 2009-06-11 at 14:19 -0500, Brad Johnson wrote:
> So if proxies do not register multiple bindings using unique public
> ports in the Contact, how do they distinguish to which phone an inbound
> Invite should go?
All of them, as a rule.
The registration binds some AOR (sip:xmlsc...@exampl
On Thu, 2009-06-11 at 10:49 -0500, Brad Johnson wrote:
> I am trying to figure out the proper behavior when multiple SIP phones
> are registered with the same URI account.
> With our own SIP Proxy implementation, we map registrations from the
> phones private contact address and port to our own p
On Wed, 2009-06-03 at 10:11 +0530, chandan kumar wrote:
> Hi All,
>
> Iam very much confused about sip expire time (during registration).
>
> Say UserAgent registered to the Proxy . I want to know how long the UA
> will be in the Proxy,When the UA agent again will send the Register
> request.
>
On Thu, 2009-05-14 at 10:50 -0700, cool goose wrote:
> Hi All,
>
> I have no idea how the SIP headers I pasted in my email got corrupted.
> Actual messages never had those nested Request URI, From and To header
> fields. I am attaching a small wireshark trace with the messages
(no attachment)
__
On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote:
> A question about the CALL-ID.
>
> 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc.
> 2. Redirect server sends response "300 Multiples Choices".
> 3. UAC makes a pararell search sending three IN
On Mon, 2009-04-27 at 02:22 +0800, Avasarala Ranjit-A20990 wrote:
> Hi
>
> I do not think a SIP entity can return a 302 response with contact
> containing "mailto:"; because SIP is not a email protocol like SMTP. So I
> feel its an error to receive "mailto: in Contact as the behaviour of
> entity
On Tue, 2009-04-07 at 22:02 +0200, Iñaki Baz Castillo wrote:
> El Martes 07 Abril 2009, Paul Kyzivat escribió:
> > The info method is unofficial and non-standard.
> > One of its limitations is that it *isn't* negotiated.
> >
> > The "official" ways are:
> > - kpml event package
> >(draft-ietf-s
On Wed, 2009-04-08 at 01:23 +0530, Nagendra Swamy Honnalagere Shivanna
wrote:
> Hi all,
>
> Is there a standard mechanism defined to generate 'nonce' value used
> in Digest authentication for SIP?
The server is free to use any method it wants to. That method should
ensure that it is hard to gues
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 finish off, I'll be adding a flag so that the
On Mon, 2009-03-30 at 12:35 +0100, Stephen Paterson wrote:
> Hi all,
>
> 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
> support
On Wed, 2009-03-11 at 16:13 +0100, Iñaki Baz Castillo wrote:
> 2009/3/11 Iñaki Baz Castillo :
> > 2009/3/11 Brett Tate :
> >> The generic answer is that the re-resolution per rfc3263 should occur for
> >> every request (except for CANCEL and ACK-non-2xx). However rfc3261 and
> >> rfc3263 provide
On Wed, 2009-03-11 at 14:46 +0100, Iñaki Baz Castillo wrote:
> Hi, imagine a domain "myomain.org" with a SRV _sip._udp register
> pointing to two hosts:
>
> sip1.mydomain.org (priority 1)
> sip2.mydomain.org (priority 2)
>
> Clients MUST contact sip1.mydomain.org since this entry has high
On Mon, 2009-03-09 at 23:08 -0700, cool goose wrote:
> Hi All,
>
> In RFC 2617 in Section 1.2 Access Authentication Framework states the below
> mentioned:
>
>
>
> "
>
> A user agent that wishes to authenticate itself with an origin
>server--usually, but not necessarily, after receiving a
On Mon, 2009-03-09 at 17:53 -0700, cool goose wrote:
> Hi All,
>
> If UAC sends a REGISTER request with "Authorization" header with digest
> response, should the registrar acknowledge it with 200 OK or 401
> Unauthorized? Also, Consider the below scenario:
>
> UAC sends REGISTER-1 to UA
On Tue, 2009-02-24 at 10:08 -0800, cool goose wrote:
> If a registrar receives REGISTER request with Max-Forwards value zero,
> should he respond with 200 OK or 483 Too Many hops?
RTFM:
If the request contains a Max-Forwards header field with a field
value of zero (0), the element MUS
On Tue, 2009-02-24 at 08:37 -0800, cool goose wrote:
> What about the request validation rules specified in Sec 16.3?
What about them - they say:
3. Max-Forwards check
The Max-Forwards header field (Section 20.22) is used to limit the
number of elements a SIP request can traverse.
On Tue, 2009-02-24 at 12:23 +0530, Somesh S. Shanbhag wrote:
> Max-Forwards is mandatory in REGISTER request. (Table 2 of RFC 3261)
> You can reject with 400 Bad Request if Max-Forwards is missing.
You _can_, but there is little reason to do so.
Be sensible - validate only what you _need_ to vali
On Sun, 2009-02-08 at 20:10 +, Andrew Wood wrote:
> How would it distinguish between the forked replies then just by the
> Contact or by putting different branch id in the Via?
that's what the branch id is for
___
Sip-implementors mailing list
Si
On Sun, 2009-02-08 at 15:33 +, Andrew Wood wrote:
> Does a proxy change the From tag when forking a request or leave it
> the same.
A true proxy does not ever change either the To or From header values.
Which is not to say that there are not real-world implementations that
don't...
Specifi
On Thu, 2009-01-29 at 16:58 +0100, Klaus Darilion wrote:
>
> Scott Lawrence schrieb:
> > On Thu, 2009-01-29 at 15:36 +0100, Johansson Olle E wrote:
> >>> Don't use registration.
> >>>
> >>> Provision the DIDs, then all normal targeting mechan
On Thu, 2009-01-29 at 15:36 +0100, Johansson Olle E wrote:
> > Don't use registration.
> >
> > Provision the DIDs, then all normal targeting mechanisms work just
> > fine.
> >
> > Someone will say "but what about dynamic addresses" - don't use a
> > dynamic address for your phone system.
> >
> T
On Thu, 2009-01-29 at 09:53 +0100, Klaus Darilion wrote:
> Hi all!
>
> We recently discussed the following problem on the asterisk-dev list and
> are hoping for inputs how to solve it in a standard conform way.
>
> Scenario: There is an enterprise using an IP PBX connected via a SIP
> trunk to
On Mon, 2009-01-26 at 12:31 +0530, Hasini Gunasinghe wrote:
> Hi All,
>
> In my sip soft phone application, I send DTMF using RFC 2976 (through sip
> info message). That works fine and it is related to the SIP stack of our
> application.
> My questions are:
> 1). In implementing the DTMF sending
On Sun, 2009-01-25 at 01:23 -0800, cool goose wrote:
> Hi All,
>
> I have the following question in the Registration with Authentication
> scenario.
>
> Consider the below scenario:
>
> UAC sends Register to UAS
>
> UAS challenge with 401 Unauthorized
>
> UAC sends Register with response for
On Fri, 2009-01-23 at 18:14 +0800, Rockson Li (zhengyli) wrote:
> There're bugs in loop detection of rfc3261,
>
> Check draft-ietf-sip-fork-loop-fix-08, which will fix it eventually.
That is now RFC 5393
___
Sip-implementors mailing list
Sip-impleme
On Mon, 2009-01-12 at 06:12 -0500, Alex Balashov wrote:
> What, do you suppose, is the motive? This is coming from a Squire
> signaling agent.
There's no reasonable motive - it's probably just a bug.
___
Sip-implementors mailing list
Sip-implemento
On Wed, 2009-01-07 at 11:02 -0500, Paul Kyzivat wrote:
> 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.
... and
On Wed, 2009-01-07 at 16:17 +0100, Victor Pascual Ávila wrote:
> > If it breaks these rules, it is no longer acting as a proxy.
>
> When a caller is behind a NAT, rewriting SDP in INVITE to include an
> RTP relay's address in it is a pretty common practice.
> Leaving RFC3261 fundamentalism aside
On Wed, 2008-12-17 at 12:01 +0530, Tapan Kumar Biswal wrote:
> Dear friends
>
> Could please any body let me know the "Loop detection" in VoIP
> is a client feature or server feature ?
Properly, both.
___
Sip-implementors mailing list
Sip
On Wed, 2008-12-03 at 12:05 +0530, Pandurangan R S wrote:
> Hi,
>
> Registrar and proxy (say responsible for domain XYZ) are co-located
> (say node A). Since node A acts the registrar, it also terminates
> SUBSCRIBEs for event "reg" for the requests containing request uri as
> sip:[EMAIL PROTECTE
On Wed, 2008-10-29 at 08:07 -0700, KASTURI Narayanan (kasnaray) wrote:
> Hi ,
>
> I have a question on a specific behavior seen with a Proxy, the behavior
> is as follows.
>
> UACProxy
> |---Invite(req-URI:A, callid:1, Ftag=1)->|
> |
On Mon, 2008-10-20 at 10:20 +0200, Klaus Darilion wrote:
>
> [EMAIL PROTECTED] schrieb:
> > You should first consider if you want to give an error, rather than
> > simply forwarding the request to the proxy for the domain in the
> > request-URI. In many cases, a proxy will receive requests from
On Sun, 2008-09-28 at 23:22 +0200, Iñaki Baz Castillo wrote:
>
> Thanks a lot. IMHO is good to make SIP more simple (for example by replying
> always to incoming IP:port in UDP) even if it breaks annoying backaward
> compatibility with old and extrange implementations. Let's move on! ;)
Ok...
On Tue, 2008-09-23 at 16:21 +0200, Iñaki Baz Castillo wrote:
> 2008/9/23, Klaus Darilion <[EMAIL PROTECTED]>:
>
> > > it would also be helpful to include the request as a message/sipfrag
> > > body in the response, since this gives the sender some hope of
> > > understanding how the request re
On Mon, 2008-09-22 at 16:53 +0200, Klaus Darilion wrote:
> Hi!
>
> What is the response code for a SIP request which was routed to the
> wrong proxy, e.g. "INVITE sip:[EMAIL PROTECTED]" was wrongly routed to
> example.com SIP proxy. How should example.com reject the request?
> 404 or is there a b
On Tue, 2008-09-16 at 13:06 +0100, Stephen Paterson wrote:
> Hi all,
>
> Quick question.
> Are there any recommended/suggested ways of generating a cnonce for use
> with a RFC 2617 compliant UAC or is it just an arbitrary quoted string?
> I've found plenty of info on nonce but not so much on cnon
> > 2008/9/3, Klaus Darilion <[EMAIL PROTECTED]>:
> >> RFC 4235 says: '...The "state" element indicates the state of the
> >> dialog. Its value is an enumerated type describing one of the states in
> >> the FSM above...' The state machine uses "Early" whereas all the
> >> examples in RFC 4235
about things that cannot be changed.
By all means - next time you are defining an entirely new protocol for
the Internet that has no backward compatibility issues, be sure you
remember these lessons.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project c
ials in your domain
with which to authenticate. SIP digest authentication is always
end-to-end (one of the very few differences introduced when SIP adopted
the HTTP Digest mechanism).
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfou
DP protocol connection information
> contains the customer signaling IP when the switch is not routing media.
>
> This may be a futile effort.. i just thought id throw the idea out on
> this list since if any one would know, it would be here ;)
Why not just challenge the request for
same address. The whole point of the reinvite may have been to
accomplish the change.
One example of this usage is so-called "music on hold": see
http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-service-example-01.html
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:
level of backward
compatibility was considered far more important than getting a
distinction correct in the label choice.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
_
On Sat, 2008-07-19 at 23:33 +0200, Iñaki Baz Castillo wrote:
> El Sábado, 19 de Julio de 2008, Scott Lawrence escribió:
>
> > A 'request replay' is an attempt by an attacker to use the
> > authentication from one (legitimate) authenticated request to
> > authen
d not by the core. Maybe this
> field makes sense just in HTTP where AFAIK there is not "retransmission"
> concept?
>
> If not, what is a "request replay" in SIP?
A 'request replay' is an attempt by an attacker to use the
authentication from one (legitim
uest Header
>...
>The values of the opaque and algorithm fields must be those supplied
>in the WWW-Authenticate response header for the entity being
>requested.
>
> What about if the 401 doesn't include "algorithm" field (so "MD5" is
> su
ct
> situation. The new call should have the References set to call-id of the
> session returning 3xx, could help with billing...
The new fork created by a 3xx response doesn't need a new Call-Id - it's
the same call (it must get a new branch id).
--
Scott Lawrence tel:+1.78
On Wed, 2008-07-02 at 09:33 +0100, Stephen Paterson wrote:
> Hi all,
>
> I need to test handling of forked responses. Does anyone know of a
> proxy/test tool that I could test against?
http://interop.pingtel.com/
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMA
don't rely on the IP address to be
the identifier.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/
t at all
clear on why implementors find it necessary to parse anything but the
topmost Via). We've seen this on a couple of other implementations as
well, and have changed that to a '$', which is legal in a token.
> If the proxy had spiralled it out, there would be other
On Fri, 2008-06-13 at 16:38 +0530, padmaja venkata wrote:
> Hi,
>
> Thanks for the reply. I, however, use only one proxy and that single proxy
> has inserted 3 via headers of its own. Please see the Invite from the UA and
> the corresponding Invite forwarded by the proxy below. My question again
y to match
> From/To URI's, but just From/To tags, is it?
You can assume anything you like... in practice, that's not true.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voi
the messages in
> out-of-order)
>
> Also REFER creates a implicit subscription within which a NOTIFY can be sent.
>
> Barring the above two conditions, is NOTIFY by itself a dialog creating
> request?
No.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMA
speeding implementation by allowing
> the reuse of existing parser code. There were other points made at the
> time of a similar nature.
There were also some at the time who had hopes that it could be made to
work transparently through HTTP proxies. That didn't last long, though.
-
> FieldMin number Max number Notes
> > to 0 1
> >
> >
> > So how is it possible? how can "To" header appear at minimun 0 times while
> > it's mandatory???
>
> Sorry, the second RFC wasn't
is that it is
obvious to everyone what the right thing to do is, but not all the
obvious solutions are the same.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice
On Thu, 2008-02-21 at 16:33 -0800, Dushyant Godse wrote:
> Hello
> I was referencing the RFC 3515 regarding messaging for transfers based
> on SIP REFER.
> Is the UA processing the REFER required to send NOTIFY subscription
> event messages to the sender agent notifying the progress of the
> trans
On Thu, 2008-02-21 at 16:25 +0200, Anca Vamanu wrote:
> Hi,
>
> RFC3261 specifies in section 12.2 that a request inside a dialog may
> contain a Contact header that could update the remote target uri. In
> presence RFC3856 there is no specification if this should be possible in
> a presence d
On Thu, 2008-02-14 at 18:46 +0530, Prakash Mariasusai, TLS-Chennai
wrote:
> Hi,
>
> We would like to know the behavior of s SIP Client in the below error
> scenario:
>
> An UAS, on receiving an INVITE, sends a TCP packet containing two SIP
> responses in ONE Packet. Here the first SIP Response h
ak
security feature, and nothing in the standards requires or even
encourages it (better security would be to just challenge the INVITE
directly).
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.or
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
you could not have, which would work if the proxy let the REFER
through unauthenticated), but that failure is less interesting and less
common than the problem we're trying to solve.
> This of course depends on that proxy having record-routed.
Yes, but our proxy always does.
On Mon, 2008-01-28 at 13:04 +, SCG2 wrote:
> Is there any circumstance at all where it makes sense to challenge an INVITE
> which is putting a call on hold?
A UAS or a Proxy is allowed to challenge any request (except an ACK,
since it isn't supposed to get any response) for any reason at any
On Thu, 2008-01-24 at 15:49 +0530, Ayyanar pk wrote:
> Can anybody help me with the following:
>
> Am a programmer, going to work on SIP for the first time, Imagine me as a
> novice in SIP
>
> 1) Can someone help with briefing the SIP stack and its features and
> functionality.
> 2) How the ap
t obeying your
convention? It doesn't prevent the abuse you're worried about.
Just requiring that the REGISTER be authenticated such that the
authentication identity is valid for the To address (the AOR) seems good
enough to me.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or si
yntactically valid, I cannot
imagine any reason to reject a call based on the presence or absence of
any url parameter it might have. Other than the tag, the From header
has no real semantics in SIP - it's essentially decoration.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[E
On Wed, 2008-01-16 at 09:45 +0100, Iñaki Baz Castillo wrote:
> On Tuesday 15 January 2008 19:11:21 Scott Lawrence wrote:
> > Why both instead of just using one or the other?
> >
> > While it's possible that this is technically legal, it certainly is not
> > the way
red a call in SIP. It's not too hard to get the Contact
address, but that's not always easily mappable (certainly for a UA) to
an AOR, much less a human identity.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http:
they have
different to-tag values). I've had cases where the phone alternated
making a locally-generated ring and an early-media busy tone - confusing
but legal.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www
mend
> a SIP-based Open Source implementation suitable to the task? The service
> must run on Linux; language preference is C/C++ , though Java would also OK.
The sipXecs project has much of what you're looking for, and we'd
certainly welcome contributions of additional SIPMLE support.
ns when someone sends an FQDN
> in the Contact URI in a 200 OK and then ACK goes to wherever the DNS
> tells you to send it to (assume non-record-routing proxies in the
> middle)?
I would ask this as a different question:
Does it make sense to use REGISTER to control routing of en
ceive a 401 Unauthorized response for an INVITE
> first and then receive a 407 Proxy Authentication Required
This could happen if the retried request for some reason followed a
different path (was routed differently by some proxy on the path), or
the proxy changed it's rules about authenticating
lear. If you're going to use an out-of-band
mechanism to change what the REGISTER message means anyway, why not just
use the out of band mechanism to modify the mapping of the set of AORs?
Why go to the trouble to use REGISTER in a non-standard way?
--
Scott Lawrence tel:+1.781.229.0533;e
ule that requires that all AOR->contact mappings be
established using REGISTER. A redirect server is free to do that
mapping using any mechanism at all.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://ww
> > On Sat, 2007-12-22 at 19:22 +0530, sourav dharchaudhuri wrote:
> >> Now if a request came with underlying value in Request Disposition header
> >>
> >> Request-Disposition: proxy, nofork, parallel
> >>
> >> What the proxy will do?
> S
ential"
> queue-directive= "queue" / "no-queue"
>
> Now if a request came with underlying value in Request Disposition header
>
> Request-Disposition: proxy, nofork, parallel
>
> What the proxy will do?
I'd say return a &
nerates phone configurations needs to keep it, but no
other component does.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesoc
2616bis/issues/
that purl.org url is the same as the skrb.org page you quoted.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.
On Thu, 2007-11-29 at 22:43 -0800, Sudhir Sharma wrote:
> Hi,
>
> I have a question regarding header "Max-Forwards"
>
> RFC 3261 in section '8.1.1.6' states that
> "If the Max-Forwards value reaches 0 before the request reaches its
> destination, it will be rejected with a 483(Too Many Hops)
the SUBSCRIBE with 489 - Bad Event OR
> b) Forward the SUBSCRIBE to the registered contact address.
Forward it.
That's the real power of using a proxy - it rarely needs to understand
what endpoints can and cannot do - it just allows them to find each
other and work out their own interoperab
by playing a ring.
This does lead to odd progress tones sometimes - I've had scenarios
where I get alternating busy tones (from a gateway that used 183 to play
the PSTN audio rather than interpreting it and returning a 486) and a
ring (from a 180 on another fork).
--
Scott Lawrence tel:+1.781.22
st served.
In the sipXecs proxy, there is configuration that allows separation of
services based on the event package. The default in when not specified
by that configuration is to route according to the request URI as with
any normal request.
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or s
ate,
>
> Proxy Authorization, WWW-Authenticate.
>
> Also please tell me what is the use of nc, response, opaque parameters
> in the Authorization
>
> Header field.
See RFC 2617
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED]
sipXecs project
1 - 100 of 121 matches
Mail list logo
