[OpenSIPS-Devel] unsubscribe
Subhashini A
sksubha at TechMahindra.com
Tue Dec 2 06:11:31 CET 2008
help
-----Original Message-----
From: devel-bounces at lists.opensips.org
[mailto:devel-bounces at lists.opensips.org] On Behalf Of
devel-request at lists.opensips.org
Sent: Friday, November 28, 2008 4:30 PM
To: devel at lists.opensips.org
Subject: Devel Digest, Vol 5, Issue 59
Send Devel mailing list submissions to
devel at lists.opensips.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
or, via email, send a message with subject or body 'help' to
devel-request at lists.opensips.org
You can reach the person managing the list at
devel-owner at lists.opensips.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devel digest..."
Today's Topics:
1. Re: [OpenSIPS-Users] About OpenSIP "The New Design" (Dan Pascu)
2. [ opensips-Bugs-2352599 ] 'dialog' 'timeout' is not reset on
a sequential request (SourceForge.net)
3. [ opensips-Bugs-2354984 ] Error in adding contact header of
200ok SUBSCRIBE message (SourceForge.net)
----------------------------------------------------------------------
Message: 1
Date: Thu, 27 Nov 2008 13:03:38 +0200
From: Dan Pascu <dan at ag-projects.com>
Subject: Re: [OpenSIPS-Devel] [OpenSIPS-Users] About OpenSIP "The New
Design"
To: devel at lists.opensips.org
Cc: users at lists.opensips.org
Message-ID: <200811271303.38274.dan at ag-projects.com>
Content-Type: text/plain; charset="utf-8"
On Thursday 27 November 2008, I?aki Baz Castillo wrote:
> El Jueves, 27 de Noviembre de 2008, Dan Pascu escribi?:
> > > Well, while it seems good, I consider it impossible
> > > (unfortunatelly).
> >
> > Fortunately, history shows us that progress was done by people who
> > didn't knew that something was impossible, so they tried anyway :P
>
> Sure something can be improved, but what I meant is that it's not so
> easy to separates layers when dealing with NAT issues.
I'd say let's leave this debate for when we have a design blueprint in
front of us. Otherwise we can speculate endlessly.
> > > How would be the performance if OpenSIPS must run PHP/Python/Ruby
> > > code for each message?
> >
> > I'm sick and tired of people being performance experts without
> > running a single benchmark, just based on assumptions and common
> > myths. Not to mention that in this case it's even more silly as
there
> > was no design presented yet, just some requirements. So you have no
> > idea how things will be, but you can already make absolute claims
> > about the performance of the system... I rest my case.
>
> Dan, if you re-read my phrase you will realize that *it was just a
> question*, I'm not doing assumpions.
I know it was a question, but my frustration related to the performance
obsession on *SER lists has kicked in. Unfortunately performance as a
reason was abused many times on the *SER mailing lists and has even led
to bad design decisions. As I said many times, performance cannot be
discussed without benchmarks and code profiling. And there are other
things to consider as well along performance.
There's a story that reflects what I think about how the performance
argument was used many times in the *SER communities in the past:
An absent-minded professor was getting late for a presentation he had to
make. Realizing how late it was, he jumped into a taxi and yelled to the
driver: "Hurry up! Hurry up! Go as fast as your can!". While the cab was
running like crazy through the city, the professor realized he didn't
mention where he wanted to go. So he asked the driver: "Do you know
where
you're going?". "No sir" said the driver, "but I go as fast as I can!"
> > > Also there are cool functions in OpenSIPS modules, for
> > > example "loose_route()". Would you imagine implementing that
> > > funcion in each "possible" high level language?
> >
> > Where did you read that loose routing will be performed by the
> > application layer?
> > And BTW, loose_route is not a cool function. It's an oxymoron.
> > Something that should be done automatically and you should never
even
> > need to know about.
>
> Imagine you run the "presence" module in the same box as the proxy.
I can imagine many things ;), but as I said let's discuss on the design
proposal when it becomes available.
> Then you do need some logic in your in-dialog section (but not into
> "loose_route" section since in-dialog SUBSCRIBE/PUBLISH will have no
> Route header pointing to our proxy). I think this is a mix between
> application/routing/core layer, is not?
All I can tell you is that the new design we have in mind is so
different
from what you already know, that it's very difficult to make assumptions
about it from what you already know from the old design.
--
Dan
------------------------------
Message: 2
Date: Thu, 27 Nov 2008 11:53:32 +0000
From: "SourceForge.net" <noreply at sourceforge.net>
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2352599 ] 'dialog' 'timeout'
is not reset on a sequential request
To: noreply at sourceforge.net
Message-ID: <E1L5fR6-0006Ea-Ie at 565xhf1.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #2352599, was opened at 2008-11-26 23:57
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&gr
oup_id=232389
Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'dialog' 'timeout' is not reset on a sequential request
Initial Comment:
Theorically 'dialog' module allows dialog timeout being reseting each
time a sequential (except ACKs) request passes.
But it doesn't seem to be true. I set:
modparam("dialog", "dlg_flag", FLAG_DIALOG)
modparam("dialog", "bye_on_timeout_flag", FLAG_DIALOG_BYE_ON_TIMEOUT)
modparam("dialog", "default_timeout", 10)
I do a call and set both flags before t_relay(). During the first 10
seconds I do re-INVITE's all the time, but when call duraton becomes 10
seconds OpenSIPS sends a BYE to both sides.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-27 11:53
Message:
a known bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=2174497&group_i
d=139143&atid=743020
----------------------------------------------------------------------
Comment By: I?aki Baz (ibc_sf)
Date: 2008-11-27 00:06
Message:
It occurs also if I set timeout_avp.
It's not related to the usage of "bye_on_timeout_flag". With it or
without
it, the dialog is removed from memory/DB when the
timeout_avp/default_timeout arrives (even if in-dialog requests have
occurred).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2352599&gr
oup_id=232389
------------------------------
Message: 3
Date: Fri, 28 Nov 2008 07:43:39 +0000
From: "SourceForge.net" <noreply at sourceforge.net>
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2354984 ] Error in adding
contact header of 200ok SUBSCRIBE message
To: noreply at sourceforge.net
Message-ID: <E1L5y0p-0002Fx-Ed at 565xhf1.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #2354984, was opened at 2008-11-28 13:13
Message generated for change (Tracker Item Submitted) made by Item
Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&gr
oup_id=232389
Please note that this message will contain a full copy of the comment
thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in adding contact header of 200ok SUBSCRIBE message
Initial Comment:
Error in adding contact header of 200ok SUBSCRIBE message in
handling_rls_subscribe.
The contact header of 200 ok message should be ip address of opensips.
But it sends whatever received from SUBSCRIBE message.
Without RLS, its working fine.
Subscribe Message
============
SUBSCRIBE sip:s3-1 at 10.6.2.246 SIP/2.0
Via: SIP/2.0/UDP
192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;
X-ST-CID=20003
Via: SIP/2.0/UDP 192.168.126.151:60000;branch=z9hG4bK-s3-12901940060
P-Charging-Vector: icid-value=starent.coms3-1-80
Route: <sip:10.6.2.246:4343;lr>
Expires: 260
Event: presence
Accept: application/rlmi+xml
Accept: multipart/related
Accept: application/pidf+xml
Supported: eventlist
From: sip:s3-1 at 10.6.2.246;tag=59572288
To: sip:s3-1 at 10.6.2.246
P-Asserted-Identity: <sip:s3-1 at 10.6.2.246>
Record-Route: <sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=20003
Record-Route:
<sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=53
6870911
Call-ID: s3-1-80
CSeq: 1 SUBSCRIBE
Contact: <sip:s3-1 at 192.168.126.151:60000>
Content-Length: 0
Max-Forwards: 69
200 ok Message
===========
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.126.1:50602;branch=z9hG4bK+7890d7155f69d4e241e7d752031eccce+s+1;
X-ST-CID=20003
Via: SIP/2.0/UDP 192.168.126.151:60000;branch=z9hG4bK-s3-12901940060
From: sip:s3-1 at 10.6.2.246;tag=59572288
To: sip:s3-1 at 10.6.2.246;tag=f1453b347f31a67638709b559e39d455-6afd
Record-Route: <sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=20003
Record-Route:
<sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=20001;X-ST-DLG-ID=53
6870911
Call-ID: s3-1-80
CSeq: 1 SUBSCRIBE
Expires: 260
Contact: <sip:s3-1 at 192.168.126.151:60000>
Require: eventlist
Server: OpenSIPS (1.5.0dev2-notls (i386/linux))
Content-Length: 0
Regards,
Nathan
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2354984&gr
oup_id=232389
------------------------------
_______________________________________________
Devel mailing list
Devel at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
End of Devel Digest, Vol 5, Issue 59
************************************
============================================================================================================================
Disclaimer:
This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at <a href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> externally and <a href="http://tim.techmahindra.com/Disclaimer.html">http://tim.techmahindra.com/Disclaimer.html</a> internally within Tech Mahindra.
============================================================================================================================
More information about the Devel
mailing list