[Home]

Summary:ASTERISK-04880: [post 1.2] 183 handling
Reporter:Tomas Komarek (komoush)Labels:
Date Opened:2005-08-23 06:19:06Date Closed:2011-06-07 14:02:59
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a problem with managing the 180 and 183 SIP messages. Would it be possible to release a patch, that in the chan_sip.c on the line 6732, where the cause 180 lies would be:

case 180:
if (!strcasecmp(msg, "INVITE")) {
sip_cancel_destroy(p);
if (!ast_strlen_zero(get_header(req, "Content-Type"))) {
process_sdp(p, req);
if (p->owner) {
/* Queue a progress frame */
ast_queue_control(p->owner, AST_CONTROL_PROGRESS);
}

}
else {
if (p->owner) {
ast_queue_control(p->owner, AST_CONTROL_RINGING);
if (p->owner->_state != AST_STATE_UP)
ast_setstate(p->owner, AST_STATE_RINGING);
}
}
}
break;


INSTEAD OF:

case 180:
if (!strcasecmp(msg, "INVITE")) {
sip_cancel_destroy(p);
if (p->owner) {
ast_queue_control(p->owner, AST_CONTROL_RINGING);
if (p->owner->_state != AST_STATE_UP)
ast_setstate(p->owner, AST_STATE_RINGING);
}
}
break;

Thanks
Comments:By: Michael Jerris (mikej) 2005-08-23 06:48:35

are you able to create a patch for cvs head for this, and do you have a disclaimer?
By: Kevin P. Fleming (kpfleming) 2005-08-23 11:16:25

Please describe the actual problem, rather than providing a vague description and and an unexplained patch.
By: Tomas Komarek (komoush) 2005-08-24 05:07:51

This is the description. If Asterisk receives the 180 Ringing message with the SDP part and the RTP stream, than based on the code the state is changed to the RINGING and forwarded is the 180 Ringing message without the SDP part and also the  outgoing rtp stream contains ringing and not the payload, taht is contained in the incomming stream. This is for me unwanted operation.

What I want is to forward the 180 Ringing with the SDP part or even better would be to translete 180 to 183 with the SDP and also forward the incomming rtp stream.
By: Michael Jerris (mikej) 2005-08-24 07:39:47

Well, you have sucessfully reworded your original statement, but you have still not stated an actual problem?  Are we violating an rfc?  What makes what you are trying to do desireable.  We need an actual explanation.
By: Tomas Komarek (komoush) 2005-08-24 08:45:30

Well, you are not violating RFC because the RFC says, that if the UAS receives the 180 with SDP it SHOULD transmit it also with SDP.

Problem is, that in the RINGING state, Asterisk does not forward SDP and RTP.
By: Michael Jerris (mikej) 2005-08-24 08:51:13

Which brings us back to, why is what you are suggesting better, and does it fit within the rfc's.  What advantage do we get, and what are the potential issues with other devices compatability.
By: Tomas Komarek (komoush) 2005-08-24 09:25:54

Well I think these are the advantages. Sometimes when calling to an cell phone, the operator sends some announcements within the stream. If Asterisk just generates the ringing, this information is lost. Why not let the customers phone choose, whether will ring or replay the announcement.

Becase some phones generates ringing independently on the incoming 18x message.

And if Asterisk would send 183 with SDP it would be even better, becase most of the phones, when receiving this message, replay the announcement (included in the stream).

Well I think, it fits better to the RFC's, because it is closer to the SHOULD than to the NOT :-)
By: Michael Jerris (mikej) 2005-08-24 09:37:45

ok, so the next 2 questions, do you have a disclaimer, and are you willing to create a disclaimed patch for cvs head to implement this.
By: Olle Johansson (oej) 2005-08-24 09:40:29

Early media is 183 Session progress, not 180 Ringing. We *do* support early media in Asterisk.

180 Ringing with SDP is something I've never seen.
By: Michael Jerris (mikej) 2005-08-24 10:10:16

can we have some rfc references that show this suggestion is the preferred way, and why please.
By: Tomas Komarek (komoush) 2005-08-24 16:56:02

To oej: I know the difference between 180 and 183. But as stated in the RFC3261 both of these messages MAY contain message bodies:

21.1 Provisional 1xx

  Provisional responses, also known as informational responses,
  indicate that the server contacted is performing some further action
  and does not yet have a definitive response.  A server sends a 1xx
  response if it expects to take more than 200 ms to obtain a final
  response.  Note that 1xx responses are not transmitted reliably.
  They never cause the client to send an ACK.  Provisional (1xx)
  responses MAY contain message bodies, including session descriptions.

As I understood Asterisk, and please correct me, if I am wrong, there exists two states, that depends on the incoming message. One of them is AST_CONTROL_PROGRESS, if incomming message is "183 Session progress with SDP" and the other is AST_STATE_RINGING, if the incoming message is "180 Ringing". Asterisk chooses the state and further behavior depending upon the SDP part is present or not. I think this is not correct.

As you've mentioned, you have never seen 180 with SDP. That is probably the reason, that if Asterisk receives "180 Ringing with SDP", the state is changed to AST_STATE_RINGING, the message is forwarded as a "180 Ringing without SDP", and no rtp stream is forwarded, even if there is one incoming.

My opinion is, that eventhough this is allowed behaviour, better would be to transmit "180 Ringing with SDP" and also the rtp stream. This is also stated in the RFC's as a "SHOULD" behaviour. I will find it soon and write it down as well.

To mike: no, I do not have a disclaimer, is it somehow possible to get it? I am probably able to write the patch.

Why it is preferred way I've already wrote, the recomendations' parts I have to find, but I can do it.

Thanks
By: Olle Johansson (oej) 2005-08-25 00:48:11

Do we discuss theory or actually have a problem somewhere?

Any implementations out there that actually sends early media on 180?

Should we treat 180 with SDP as compatible with 183?
By: Tomas Komarek (komoush) 2005-08-25 03:53:21

We needn't discuss theory, the only way I wanted to say is, that 180 with SDP and with early media is possible.

For example Cirpack uses 180 this way.

That's what the patch solve without deeper check on the code.

So I would suggest to use 180 with SDP as a 183.
By: Olle Johansson (oej) 2005-08-25 06:59:46

A lot of things are possible, but so far we haven't had any problems with not supporting this. Is this something that Cirpack do not want to change in order to be compatible with the vast number of other devices out there?

Again, should I treat is as call progress? If not, I can't do anything with the audio at this point. It will end up nowhere.
By: Tomas Komarek (komoush) 2005-08-25 09:39:33

Yes, I do not want anything else. Just to treat "180 with SDP" as a 183. Imagine the situation, that during the ringing, the PSTN side generates some sort of customized ringing. Then without the early media possible with 180 with SDP this information is lost.

And this does the upper mentioned part of code.
By: Olle Johansson (oej) 2005-08-25 09:47:45

No, your code parses any attachment as an SDP...

Do you have a disclaimer filed with Digium? Without it, we can't use your patch at all.
By: Tomas Komarek (komoush) 2005-08-25 10:01:36

No, i do not have a disclaimer. May I get one somehow?
By: Michael Jerris (mikej) 2005-08-25 10:04:53

if you look in the bug guidelines and off the main page of bugs.digium.com, you will find the information about submitting a disclaimer.
By: Tomas Komarek (komoush) 2005-08-25 10:49:41

OK, I am organizing the disclaimer. When I will have it, would you agree with releasing of such a patch?
By: Michael Jerris (mikej) 2005-08-31 23:03:28

Bug suspended due to no activity.  Please re-open this bug once your disclaimer is filed with digium.  Thanks!