[asterisk-users] Send SIP 100 Trying instead of 183 Session Progress

[Remi Quezada]

Hi,

I have a Asterisk that connects to the PSTN via a PRI. After Asterisk
sends the setup message it immediately sends a 183 Session Progress. Is
there a way I can change it so that it sends a 100 Trying instead?
Because I am having some issues with a equipment where it does not play
a busy tone as a result of sending a 183 Session Progress then the 486 Busy.

Thanks

Remi

[Richard Revels]

You are probably running into the problem described below. Below that
is a link to the original document with the code patch. I put it on a
PRI box we use inhouse and it took care of the 183 before a busy for
me. However, this is a box we use inhouse. I've never put it on
anything in production. Your mileage may vary
gday guys (n'gals).

I have a third party SIP platform which generates outbound calls via
asterisk to ISDN (Australia - so thats ETSI ISDN). This platform
doesn't
really like inband signalling on outbound calls (ie getting 183's with
SDP
-- its fine with 180 Ringing etc...)

Having had a bit of a silly time with the sip.conf variable
progressinband=never,no,yes (arg!) I dug a little deeper into the
chan_sip
code.

It appears on a SIP->Zap call the ISDN channel is opened, and before
you can
say 'boo' sip_write() in chan_sip is called.... this appears to occurs
prior
to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)

sip_write doesn't seem to care at all what progressinband is set to,
and if
it gets a frame when the SIP channel is not in AST_STATE_UP it
generates a
183 with SDP (then sets SIP_PROGRESS_SENT)

Does this behaviour seem strange? I'm not really sure if this is a
bug, a
'its just like that' thing, or something strange with our ISDN that is
unusual?

In an ideal world (for me anyway... *grin*) I would think that
progressinband=never (or even progressinband=no) would mean that 180
Ringing, 486 Busy etc would be used and 183 Session Progress with SDP
would
not...

I have done some basic testing and if I patch as follows...

[Richard Revels]

And in case that link doesn't work so well in text email clients here
is the real address.

lists.digium.com/pipermail/asterisk-dev/2006-May.txt.gz

Richard

Post by Richard Revels
You are probably running into the problem described below. Below
that is a link to the original document with the code patch. I put
it on a PRI box we use inhouse and it took care of the 183 before a
busy for me. However, this is a box we use inhouse. I've never put
it on anything in production. Your mileage may vary
gday guys (n'gals).
I have a third party SIP platform which generates outbound calls via
asterisk to ISDN (Australia - so thats ETSI ISDN). This platform
doesn't
really like inband signalling on outbound calls (ie getting 183's
with SDP
-- its fine with 180 Ringing etc...)
Having had a bit of a silly time with the sip.conf variable
progressinband=never,no,yes (arg!) I dug a little deeper into the
chan_sip
code.
It appears on a SIP->Zap call the ISDN channel is opened, and before
you can
say 'boo' sip_write() in chan_sip is called.... this appears to
occurs prior
to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)
sip_write doesn't seem to care at all what progressinband is set to,
and if
it gets a frame when the SIP channel is not in AST_STATE_UP it
generates a
183 with SDP (then sets SIP_PROGRESS_SENT)
Does this behaviour seem strange? I'm not really sure if this is a
bug, a
'its just like that' thing, or something strange with our ISDN that is
unusual?
In an ideal world (for me anyway... *grin*) I would think that
progressinband=never (or even progressinband=no) would mean that 180
Ringing, 486 Busy etc would be used and 183 Session Progress with
SDP would
not...
I have done some basic testing and if I patch as follows...

[Johansson Olle E]

Post by Richard Revels
You are probably running into the problem described below. Below
that is a link to the original document with the code patch. I put
it on a PRI box we use inhouse and it took care of the 183 before a
busy for me. However, this is a box we use inhouse. I've never put
it on anything in production. Your mileage may vary
gday guys (n'gals).
I have a third party SIP platform which generates outbound calls via
asterisk to ISDN (Australia - so thats ETSI ISDN). This platform
doesn't
really like inband signalling on outbound calls (ie getting 183's
with SDP
-- its fine with 180 Ringing etc...)
Having had a bit of a silly time with the sip.conf variable
progressinband=never,no,yes (arg!) I dug a little deeper into the
chan_sip
code.
It appears on a SIP->Zap call the ISDN channel is opened, and before
you can
say 'boo' sip_write() in chan_sip is called.... this appears to
occurs prior
to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)
sip_write doesn't seem to care at all what progressinband is set to,
and if
it gets a frame when the SIP channel is not in AST_STATE_UP it
generates a
183 with SDP (then sets SIP_PROGRESS_SENT)
Does this behaviour seem strange? I'm not really sure if this is a
bug, a
'its just like that' thing, or something strange with our ISDN that is
unusual?
In an ideal world (for me anyway... *grin*) I would think that
progressinband=never (or even progressinband=no) would mean that 180
Ringing, 486 Busy etc would be used and 183 Session Progress with
SDP would
not...

I don't think progressinband controls early media (audio to caller
before call setup)
but how indications should be sent (in audio=inband). If we get early
media from
the callee leg of the call, we have to relay it always.

If you get early media signalling in SIP and don't have early media on
the outbound
call leg, then there's a bug and you should open a bug in the bug
tracker so we
can resolve it. For license reasons, we can't handle patches on the
mailing list,
we have to get them through the bug tracker.

I really appreciate your help in resolving this issue, as you clearly
have a lot of
insight in the situation. Please open a bug on the bug tracker and
we'll meet
you there!

Thanks,
/Olle

---
* Olle E. Johansson - ***@edvina.net
* Asterisk Training http://edvina.net/training/
* The Asterisk SIP Masterclass - Stockholm, Sweden, January 2008
* Register today!

[Richard Revels]

You're right of course. I should have dug into this a little deeper
and checked to see if it is corrected in the current release. As is
so often the case, I was working on a real specific problem and once
the system started doing what I wanted it to I pretty much forgot
about it.

I won't drag this out but I do want to clarify one point. This
scenario occurs when the call originates from the SIP side and is
destined for a number on the PRI side. The PRI does the trunk setup
and then the SIP 183 is sent back to the originator before any further
call progress occurs on the PRI side. This results in the SIP
originator seeing a "ring" and then a "busy" if the called party is
actually busy. Not deadly (although the original poster seemed to
have some equipment that didn't like it) but certainly irritating.

Richard

Post by Johansson Olle E

Post by Richard Revels
You are probably running into the problem described below. Below
that is a link to the original document with the code patch. I put
it on a PRI box we use inhouse and it took care of the 183 before a
busy for me. However, this is a box we use inhouse. I've never put
it on anything in production. Your mileage may vary
gday guys (n'gals).
I have a third party SIP platform which generates outbound calls via
asterisk to ISDN (Australia - so thats ETSI ISDN). This platform
doesn't
really like inband signalling on outbound calls (ie getting 183's
with SDP
-- its fine with 180 Ringing etc...)
Having had a bit of a silly time with the sip.conf variable
progressinband=never,no,yes (arg!) I dug a little deeper into the
chan_sip
code.
It appears on a SIP->Zap call the ISDN channel is opened, and before
you can
say 'boo' sip_write() in chan_sip is called.... this appears to
occurs prior
to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)
sip_write doesn't seem to care at all what progressinband is set to,
and if
it gets a frame when the SIP channel is not in AST_STATE_UP it
generates a
183 with SDP (then sets SIP_PROGRESS_SENT)
Does this behaviour seem strange? I'm not really sure if this is a
bug, a
'its just like that' thing, or something strange with our ISDN that is
unusual?
In an ideal world (for me anyway... *grin*) I would think that
progressinband=never (or even progressinband=no) would mean that 180
Ringing, 486 Busy etc would be used and 183 Session Progress with
SDP would
not...

I don't think progressinband controls early media (audio to caller
before call setup)
but how indications should be sent (in audio=inband). If we get early
media from
the callee leg of the call, we have to relay it always.
If you get early media signalling in SIP and don't have early media on
the outbound
call leg, then there's a bug and you should open a bug in the bug
tracker so we
can resolve it. For license reasons, we can't handle patches on the
mailing list,
we have to get them through the bug tracker.
I really appreciate your help in resolving this issue, as you clearly
have a lot of
insight in the situation. Please open a bug on the bug tracker and
we'll meet
you there!
Thanks,
/Olle
---
* Asterisk Training http://edvina.net/training/
* The Asterisk SIP Masterclass - Stockholm, Sweden, January 2008
* Register today!
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users