28 Oct
2005
28 Oct
'05
10:05 a.m.
Hi all!
It depends on what you expect from SIP. If you want to use it as POTS
replacement, or if you want to have full control over every terminal,
than I suggest using proprietary protocols.
If you are dreaming the Internet dream, then the service should be
end-2-end without a service provider inspecting all signaling, payload
and media.
And if there are broken clients, the clients should be fixed. Of course
you can save $$ by giving cheap (broken) phones to your costumers and
fix it by spending $$ for a SBC. Depending on the numbers of clients you
have, it may be cheaper using cheap phones and buy the SBC.
One big problem with SBC are the service contract - you have to buy them
for each year to get updates. If you detect a bug and ask for the
bugfix, they ask you for $$.
Of course if your business depends on selling minutes to the PSTN and
being cheaper than traditionel POTS, you have to be sure that the
billing is accurate.
And do not forget - there is a great B2BUA for free - it's called
"Asterisk". And it will detect dead calls as well.
regards
klaus
Joachim Fabini wrote:
Hi,
I'd also like to add my 2 cents to this topic, which
might be slightly off-topic on this mailing list.
Imho the problem discussed here is a major defficiency
of the SIP protocol, which forces most vendors to
implement proprietary extensions in their equipment.
Call supervision is a feature that might not be
important for best-effort services, but is of utmost
importance when deploying SIP within a commercial
environment.
Have a look at, e.g. H.323. They do have several
redundant mechanisms to detect stale calls (e.g.
at H.225 RAS level (IRQ/IRR/IACK/INAK), and at
call signaling level (Status request/Status)). These
messages offer detailed information on all ongoing
calls within a terminal/gateway - either on sending
an explicit request or by asking the endpoint to
provide this information on a periodical base.
Beside this, RRQ/RCF also provides re-registration
features similar to REGISTER timers in SIP.
Again imho the clean solution for SIP was to have
an equivalent of these features defined in the 3261 core.
It's too late for this now. What still can (and should) be
done is an RFC that defines an extension to SIP which
implements call supervision.
Concluding: It's obvious that _real_ call supervision
that is capable to detect malicious, non-standard
compliant terminals (which, e.g. signal voice but send
video over the voice channel) requires some border
gateways featuring RTP content sniffing. But this is
imho no excuse for SIP not providing standardized
means capable to supervise calls on standard-compliant
SIP devices.
regards
--Joachim
-----Original Message-----
From: users-bounces(a)openser.org
[mailto:users-bounces@openser.org] On Behalf Of Bogdan-Andrei Iancu
Sent: Donnerstag, 27. Oktober 2005 21:02
To: Daryl Sanders
Cc: users(a)openser.org
Subject: Re: [Serusers] Re: [Users] Detecting runaway calls
Daryl,
normally, a PSTN provider who offer quality service must
offer a way to detect hanged calls.
There is also a detection mechanism based on media (on GW) -
at least CISCO GW have.
regards,
bogdan
Daryl Sanders wrote:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
This is exactly what I am trying to overcome. Do
third party PSTN
providers typically employ any other means of monitoring a call? I
would think the would automatically disconnect the call
after a certain
amount of time if there was no media detected.
On 10/27/05, Iqbal <iqbal(a)gigo.co.uk> wrote:
>problem with session timers, is if you have several
different routes
>and you dont control all the end
gateways....then its a pain, so I
>would think you would need a plan B, just in case to ensure
you double
>checked, but agree with bogdan, b2bua i great
but I think
the overhead
>is not needed.
>
>Iqbal
>
>Bogdan-Andrei Iancu wrote:
>
>
>
>
>>Hi Greg,
>>
>>that's the fortunate case of having already a B2BUA on the path :).
>>But only for this particular case, I find the usage of a B2BUA a
>>little bit to "heavy"....
>>
>>Session Timer is actually doing a great job ;)
>>
>>regards,
>>bogdan
>>
>>Greg Fausak wrote:
>>
>>
>>
>>
>>>The re-INVITEs definitely work. I run some setups with Jasomi
>>>inline (a commercial inline b2bua). I configure them to
reINVITE,
>>>works like a charm. If the reINVITE
isn't answered (in either
>>>direction) the Jasomi sends BYEs in both directions. I believe
>>>other commercial gear works that way.
>>>
>>>Also, I believe Session-Timers are supported by Cisco
gateways, but
>>>I don't have experience with
those.
>>>
>>>-g
>>>
>>>
>>>On 10/27/05, Daryl Sanders <daryl.sanders(a)gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Thanks for the info guys! It sounds like I need to do a little
>>>>reading up on cseq to determine if this will even work,
or find a
>>>>PSTN gateway provider that
supports Session-Timers.
>>>>
>>>>- Daryl
>>>>
>>>>On 10/27/05, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>by sending re-INVITEs from the middle of the path you will
>>>>>increase the cseq number differently on each side...so you will
>>>>>need to synchronize the cseq value when some in-the-dialog
>>>>>requests are passing through your proxy....and that's quite
>>>>>complicated....
>>>>>
>>>>>regards,
>>>>>bogdan
>>>>>
>>>>>Daryl Sanders wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Would it be possible to fake a REINVITE then check the
response
>>>>>>to determine if a call is
still in session? Just
brainstorming...
>>>>>>- Daryl
>>>>>>
>>>>>>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users