I had a very funny and equally annoying experience today. I have a
US-based DID number purchased from voip.ms. This number is forwarded to
an extension of sipXecs system and from there a call forwarding rule via
voip.ms sends the call to my cell phone. I received a call to the DID
this morning and answered it on my cell phone. The caller had the wrong
number so the call was over in a few seconds. After that I started
getting strange calls from the same caller every half an hour. When
answering the call I would hear dead silence on the line. This continued
for hours. Loud noise from banging the phone on the desk and use of
strong language would not stop the guy from calling over and over.

It turns out during call disconnect of the first call sipXbridge messed
up the call termination, probably due to
http://track.sipfoundry.org/browse/XX-6698. It was then left thinking
that it had a call in progress and session timers audit would kick in
every 30 minutes. Unfortunately the ITSP SIP UA (User-Agent:
VoIPMS/SERAST) is not behaving properly and is treating the in-dialog
session timers reINVITE as a new call. The ITSP is actually making a
call to my cell phone each time. It is also OK with reusing the old "to"
and "from" tags and callId for the new call. The other piece of the
puzzle is that every time I would answer the call on my cell phone and
hang up the BYE is generated by the ITSP, but sipXbridge would reject it
with "500 out of order" response, and sipXbridge would keep the call
alive.

Clearly treatment of the reINVITE as a new call is an issue with the
ITSP. But, I may have a hard time getting the ITSP to fix this problem
on their end. 

Is there anything we can do at the sipXbridge end to help minimize the
damage in this scenario? 

I see two opportunities: 
1. During re-INVITE processing ITSP sends provisional 180 ringing
response to sipXbridge. Could this be the hint that the UA is setting up
a new call?
2. When ITSP sends a BYE to sipXbridge could this be a strong enough
indication that this call is better be disconnected, even though
sipXbridge sees that the sequence number is wrong.


Thanks,
Mark.


  
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to