[asterisk-biz] Experimental/new VoIP rate search engine.

[John Todd]

On Jan 5, 2009, at 9:11 AM, Kristian Kielhofner wrote:
> On 1/5/09, Alex Balashov <abalashov at evaristesys.com> wrote:
>> There's not really much to session timers except periodic re-INVITEs
>> that re-assert an existing SDP offer/answer.  Do they not support  
>> those
>> either?
>
> And SDP is just offer/answer right?  How many pieces of equipment have
> SDP issues?  How many pieces of equipment can't implement the core SIP
> RFCs properly?  Session timers seem simple (and really are) but you
> would be surprised how many implementations are just broken.
>
> With that being said, I don't know of a single Tier 1 that supports
> them.  Interop is tough enough with some of them, I just don't think
> they want to deal with it.  Sure you can do session timers in between
> your endpoints but other than that you're (currently) out of luck.

I would suggest that you just try turning session-timers on YOUR side  
first and see what you get.  In many cases, it "just works" and you  
won't know until you try.  The other side often does not have to  
explicitly support session-timers - it just needs to not crash when  
you sent the re-INVITE with the same media/endpoint criteria.

This will allow your side to figure out when things have gone wrong,  
but it may not help solve the fundamental problem which is the other  
side not having the same knowledge and letting the call go on forever.

Addressing the initial question from long ago in this thread: Perhaps  
a packet logger filter that explicitly tracks "BYE" and "OK" would be  
sufficient for arguments with your carrier, and wouldn't overwhelm you  
from a logging overload perspective.

JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/