On Tue, 2009-04-28 at 11:07 +0530, Prince A P wrote:
> Any idea about currently how many live deployments are happening for
> Sigcomp?
>From November 2007, the SIPit survey says 15% of implementations support
sigcomp: http://www.ietf.org/mail-archive/web/sip/current/msg21291.html
> Does the Impo
On Mon, 2009-04-27 at 14:58 +0530, friend friend wrote:
> Dear Folks,
>I have doubt in the following scenario.
>
> Caller's sdp :
>
> v=0
> o=- 1234 1 IN IP4 10.10.20.35
> s=-
> c=IN IP4 10.10.20.35
> t=0 0
> m=audio 12000 RTP/AVP 102 0 8 106
> a=rtpmap:102 iLBC/8000
> a=rtpmap:0 PCMU
On Sun, 2009-04-26 at 12:56 +0200, Iñaki Baz Castillo wrote:
> A SIP phone *cannot* contact a mailto uri, SIP protocol ends when the 302
> Contact is a mailto URI.
And there is a specific error code for reporting this situation: "416
Unsupported URI Scheme".
Dale
That is what session timers are for, theoretically.
--
Sent from mobile device
On Apr 29, 2009, at 10:31 AM, nabam serbang
wrote:
> Thanks everyone for valuable inputs.
>
> It seems that someway or other, billing depends on BYE request at
> the end of call to determine the call duration. Ho
Thanks everyone for valuable inputs.
It seems that someway or other, billing depends on BYE request at the end of
call to determine the call duration. How shall we determine call duration in
following case:
A--INV--->B
<---200k--- -
Also you could find useful info in this new RFC:
http://tools.ietf.org/html/rfc5390
"Requirements for Management of Overload in SIP"
It details the use of 503.
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@lists.cs.col
2009/4/29 Taisto Qvist XX :
> ===
> Question 3.
> ===
> The annoying 503 Response and "Retry-After:"...
> I have read the archive and the fairly new RFC on congestion-handling,
> but neither seems to clarify, or even mention that the text in 3261,
> (that is referred to in rfc5390)
2009/4/29 Paul Kyzivat :
> 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?
1) The gateway could crash (but my pure SIP proxy/B2BUA has
failover
[much better to split up the question]
>>but I receive it on UDP, should I strip it?
I'd leave it, I don't think it matters much, you would
strip the top Route anyway (if the top route is you).
(unless you had different applications running on UDP and TCP,
I don't think it's important)
>>W
[On request, splitting my previous question in separate emails,
and this is the last.]
Greetings fellow SIPers!
I've got a few questions regarding how I should interpret a few things
in rfc3263, and related text in 3261.
===
Question 3.
===
The annoying 503 Response and "Retr
[On request, splitting my previous question in separate emails...]
Greetings fellow SIPers!
I've got a few questions regarding how I should interpret a few
things in rfc3263, and related text in 3261.
===
Question 4.
===
It concerns the text about retrying after fatal transpor
[On request, splitting my previous question in three more emails...]
Greetings fellow SIPers!
I've got a few questions regarding how I should interpret a few things
in
rfc3263, and related text in 3261.
===
Question 2.
===
Route preprocessing says, with regard to stripping the r
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 :
>> What I meant before was th
Hi Taisto, please, send an independent mail for each question, if not
it will be impossible to understand the thread.
I reply here just to question 1:
2009/4/29 Taisto Qvist XX :
> ===
> Question 1.
> ===
>
> 3263 says:
>
> If the URI specifies a transport protocol in the trans
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:
>
2009/4/29 Alex Balashov :
> Makes sense. Thank you for the clarifications.
>
> I suppose a lot of it depends on what the far-end equipment does. In your
> example with the invalid CSeq, do you suppose most softswitches' and/or SBCs
> purge the call anyway if they receive a malformed BYE? I would
Greetings fellow SIPers!
I've got a few questions regarding how I should interpret a few things
in
rfc3263, and related text in 3261.
===
Question 1.
===
3263 says:
If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be u
Makes sense. Thank you for the clarifications.
I suppose a lot of it depends on what the far-end equipment does. In
your example with the invalid CSeq, do you suppose most softswitches'
and/or SBCs purge the call anyway if they receive a malformed BYE? I
would think so. Otherwise there woul
2009/4/29 Alex Balashov :
> That is a very good point.
>
> Do you know how the ACC module in Kamailio determines whether to stamp a CDR
> as finished? Is it vulnerable to this attack?
Kamailio/openSIPS has a "dialog" module, but it remains being a proxy
so, for now, it doesn't check such subjects
That is a very good point.
Do you know how the ACC module in Kamailio determines whether to stamp
a CDR as finished? Is it vulnerable to this attack?
I would have assumed it is tied to the dialog state and that ACC
states are tethered to dialog module callbacks programmatically. But I
am n
2009/4/29 Alex Balashov :
> What I meant before was that I have hacked Kamailio in the past to basically
> do this UA functionality despite it being very much a UA and not proxy thing
> to do. It originated and absorbed special re-INVITEs that were spoofed and
> basically did dlg_bye() if no respo
I can't really argue with that. Having something in the middle to
actually enforce session timers seems like the key to limiting
financial exposure
What I meant before was that I have hacked Kamailio in the past to
basically do this UA functionality despite it being very much a UA and
not
El Miércoles, 29 de Abril de 2009, Alex Balashov escribió:
> I agree; nothing can be forced. And yes, I do think proxy billing has
> vulnerabilities and technological limitations.
>
> But the benefit of simplicity and QOS should also be considered in a
> commercial environment. There is not a con
I agree; nothing can be forced. And yes, I do think proxy billing has
vulnerabilities and technological limitations.
But the benefit of simplicity and QOS should also be considered in a
commercial environment. There is not a convincing reason to be
handling media if you are an ITSP / arbit
El Miércoles, 29 de Abril de 2009, Alex Balashov escribió:
> I suppose B2BUA can work but I was actually using a proxy element--for
> example Kamailio's SST module.
I don't understand: even if a proxy (as Kamailio) wants to "participate" in
SessionTimer, the only it can do is inspecting SS header
I suppose B2BUA can work but I was actually using a proxy element--for
example Kamailio's SST module.
It violates strict proxy behaviour by originating and spoofing a
sequential BYE in the other direction if a 200 OK is not received for
a re-INVITE. Oh well.
--
Sent from mobile device
On A
But Inaki, that requires effort, aforethought, courtesy, and an
ability to see past the narrow aims of instant gratification! :)
--
Sent from mobile device
On Apr 29, 2009, at 2:58 AM, Iñaki Baz Castillo wrote:
> El Miércoles, 29 de Abril de 2009, Manoj Priyankara [TG] escribió:
>> Hi All,
>>
Hi all,
Apologies...
Thanks
BR,
Manoj
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Wednesday, April 29, 2009 12:28 PM
To: sip-implementors@lists.cs.columbia.edu; Manoj Priyankara [TG]
Subject: Re: [Sip-implementors] P-CSCF Security functions
El Miércoles, 2
El Miércoles, 29 de Abril de 2009, Alex Balashov escribió:
> My experience has been that Session Timers (periodic reINVITEs to the
> endpoints mid-call) are a perfectly viable signaling-only solution to
> the problem of billing discrepancies / ad infinitum CDRs due to lack
> of media handling.
I a
29 matches
Mail list logo
