tag:blogger.com,1999:blog-3993498847203183398.post636400393481295305..comments2024-03-28T09:19:27.451+00:00Comments on RevK<sup>®</sup>'s ramblings: Another SIP challengeRevKhttp://www.blogger.com/profile/12369263214193333422noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-3993498847203183398.post-42113032982399577292013-05-28T01:23:50.164+01:002013-05-28T01:23:50.164+01:00Would you like a Cisco 7960 to add to your collect...Would you like a Cisco 7960 to add to your collection?leighporterhttps://www.blogger.com/profile/05302818815635825482noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-82248172382994662742013-05-23T14:23:34.863+01:002013-05-23T14:23:34.863+01:00Yes, and indeed, the linux based system does that,...Yes, and indeed, the linux based system does that, but it is nothing like as "clean" in the way or working and has all sorts of problems of its own. This is the lowest common format but the result is "just works", and is good call quality too.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-79343487155502947082013-05-23T13:43:56.130+01:002013-05-23T13:43:56.130+01:00Can you not renegotiate the codec once the call ha...Can you not renegotiate the codec once the call has started? (I would've expected that to be do-able with a reinvite?)Steve Hillhttps://www.blogger.com/profile/09798286430189689578noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-47191263718188431392013-05-23T09:10:14.211+01:002013-05-23T09:10:14.211+01:00Indeed. What the FireBrick does is spots the media...Indeed. What the FireBrick does is spots the media stop, as it is always in the path, and then does "poll" the endpoint with a re-invite so as to check. It is valid for media to stop when on hold, for example, so this approach allows that as long as the end point still answers the re-invites. Also, we only negotiate a-law audio so we can always join the calls up - it is a deliberate restriction which means it works the same as the PSTN but again makes for reliability.RevKhttps://www.blogger.com/profile/12369263214193333422noreply@blogger.comtag:blogger.com,1999:blog-3993498847203183398.post-79153983474598349872013-05-23T09:06:57.199+01:002013-05-23T09:06:57.199+01:00I have always been curious how SIP is *supposed* t...I have always been curious how SIP is *supposed* to work WRT endpoints vanishing in the middle of a call (and therefore not sending a BYE). Under Asterisk I've certainly noticed the occasional call that claims to still be ongoing even though both endpoints went away hours before. My understanding is that the SIP proxy doesn't poll the client to ask if the call is still in progress, so its relying entirely on the endpoints not vanishing mid-call. I've also had occasional issues with my POTS<->SIP gateway not hanging up the call in the event the handset crashes, which is a problem when calling a POTS line since POTS doesn't allow the callee to hangup the line!<br /><br />Also I note that under Asterisk, some of my handsets very occasionally fail to ring, which I presume is down to a loss of the SIP packet (although this should be resent?!).<br /><br />One problem I've noticed with Asterisk being an endpoint rather than a proxy, is that media isn't renegotiated - for example, Asterisk will negotiate a video stream with the caller before connecting to the callee, and that video stream will remain in place even when its discovered that the callee doesn't support video (asterisk just bitbuckets the video stream, which means lots of wasted bandwidth that could be avoided). I presume though that this is just an artifact of Asterisk's implementation rather than an inherent problem of being an endpoint rather than a proxy?Steve Hillhttps://www.blogger.com/profile/09798286430189689578noreply@blogger.com