I have a large carrier that I am trying to send calls to, and their major brand SIP/ISUP switch (whose name begins with a "S") has a quirk where it emits a 183 Session Progress message with no SDP payload immediately after 100 Trying, and before ACM has actually been received. When ACM is received, it emits either a 180 Ringing with a SDP payload, or a 183 Session Progress with a SDP payload. So
INVITE 100 Trying 183 Session Progress (no SDP payload) 180 Ringing (or 183 Session Progress) (with SDP payload) 200 OK (with SDP payload)
is what you normally get, with the two 18x messages coming one or two seconds apart.
However, if the called number is busy, you get
100 Trying 183 Session Progress (no SDP payload) 486 Busy Here
What the calling party experiences for that is a second or two of ring-back commencing with the 183 Session progress, then a busy signal. That's very non-compliant.
So far, the carrier has been unable to get this switch to stop emitting the first 183 Session Progress message.
What I would like to do is have SER detect the redundant 183 Session Progress message (which I can already detect), and then have SER discard it, eg not send that one message back to whomever the INVITE came from.
So far, I have been unable to get SER to do this. While "drop" is allowed in onreply_route sections, it is silently ignored, and you get a reply anyway. I tried putting a route(666) in the onreply_route section and putting the drop in that route["666"] section, but that had no obvious effect either, although some other functions can now be used in route["666"] that so far aren't solving the problem either.
It occurred to me that I could change the 183 Session Progress of the offending message to something else in the "so-what" department, such as a "181 Your Call Is Being Forwarded", but "replace()" doesn't seem to work on the first line of replies, but can certainly alter other things in the reply message.
There also doesn't seem to be any way (that actually works) to change the numeric SIP Response Code value to something else, even though clearly SER has it in the variable "status".
I even thought of changing the port number or IP address via a rewrite command and send the message off to nowhere, but those don't work on replies or don't appear to.
So, any suggestions on how to simply drop a chosen reply message, or misdirect it or malform it to the point that the call originator doesn't recognize it anymore? Yeah, kludgy but I only need it to work for two months.
Thanks in advance!
Hi!
On Dec 24, 2009, at 12:35 AM, Frank Durda IV wrote:
is what you normally get, with the two 18x messages coming one or two seconds apart.
The reason for this usually is that Softswitches map every ISUP message to a SIP message and even if there isn't any 'new' information they still send something downstream. We see this on another Softswitch as well.
However, if the called number is busy, you get
100 Trying 183 Session Progress (no SDP payload) 486 Busy Here
What the calling party experiences for that is a second or two of ring-back commencing with the 183 Session progress, then a busy signal. That's very non-compliant.
I'd call that expected behaviour ;) Imagine this case: I call you on your cell. You pull your phone out of your bag, see my number and after a few seconds decide to reject my call. In that case a 486 will be send to me a few seconds after the 183. As a matter of fact my phone does play a ringtone for a few seconds as your phone is actually ringing. Whether the tone was locally generated or sent from the network/you is a different story.
I do see the issue with the client first generating the ringtone locally followed/mixed with a network provided one. Note that the early media might include a precall announcement, advise of charge or simply a custom ringtone. I believe it is also common to play announcements as early media to work around some billing things.
I do not have a solution at hand to supress the 183 you experience but wanted to mention a few scenarios in which the 183 does make sense from a user experience point of view.
Just my $.02, Hendrik
-- Hendrik Scholz VoIP System Engineer hendrik.scholz@freenet-ag.de Tel.: +49 (0) 431 9020552 Fax: +49 (0) 431 9020559
freenet Cityline GmbH Ein Unternehmen der freenet Group Am Germaniahafen 1-7 D-24143 Kiel
www.freenet.de
Geschäftsführung: Stephan Esch, Andreas Jürgensen, Bodo Rebetge, Andreas Sand Sitz der Gesellschaft: Kiel HRB 6202 KI, Amtsgericht Kiel
Hendrik Scholz wrote:
I'd call that expected behaviour ;)
For all-SIP environments it may be expected, but for traditional ISUP/TDM networks, it is bad bad unacceptable bad bad bad. Did I mention bad?
It is guaranteed to create trouble tickets. These carriers (including most of the North American cell phone companies) don't care if there is a SIP leg in the call somewhere where such behavior would be considered "okay". As far as traditional phone service is concerned, you are not allowed to give contra-indications to subscribers. It can't be ringing and busy. Choose one.
By the way, on most cell phone networks in North America, if the called party elects to not take the call by hitting the ignore button, the call goes to voicemail, and so the ring-back you got to that point is consistent. If the called party doesn't have voicemail, you go to a recording. Again, the treatment the subscriber hears is consistent and you aren't presented with a busy or fast busy follwing ring-back, except in cases of malfunction. Either of those showing up after ring-back almost always causes a trouble ticket.
What is allowed elsewhere may vary, but they are pretty strict about this sort of thing.
So I still have to come up with a fix or not allow the calls to pass via SIP. It is a pretty clear-cut requirement.
-
Frank Durda IV -
Hendrik Scholz