<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
The differences you have outlined for 180 and 183 aren't necessarily accurate.<BR>
<BR>
180 means the called party is being alerted. It is perfectly legal to send a 180 w/ SDP specifying the called party will provide ringback. Generally you will only see a single 180 message in a dialogue since the EP can only begin ringing once.<BR>
<BR>
183 messages just contain progress updates to the session, so they can happen both before and after the 180, if a 180 is sent at all (i often see 183 w/sdp, and ringback provided by the far end in lieu of a straight 180 or 180w/sdp). <BR>
<BR>
For example, if you send an invite to a B2BUA it could send the invite to EP 1, send back a 180, then have EP1 timeout, so it cancels the dialogue and invites EP2, so it could send a 183 back to the initiating party to indicate something changed (with or without media control).<BR>
<BR>
Yes there is a lot of ambiguity here. YMMV etc etc. <BR>
<BR>
<BR>
<BR>
On Fri, 2010-10-15 at 14:17 -0500, Hiers, David wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
As far as I can tell, that signaling is legal, but somewhat nonsensical.
The UAS can send as many 1xx responses as it wants, and 3261 contains no language that precludes sending 183 after 180.
The nonsense part comes from the meaning of 180 and 183. 180 means "play local alerting tone", and 183 means "play remote alerting tone", so you're changing a pretty basic structure on the fly.
The gestalt of draft-ietf-sip-183-00.txt seems to be that you'll provide either 180 or 183, not both, so I can see where a UAC would choke on it.
David Hiers
CCIE (R/S, V), CISSP
ADP Dealer Services
2525 SW 1st Ave.
Suite 300W
Portland, OR 97201
o: 503-205-4467
f: 503-402-3277
-----Original Message-----
From: <A HREF="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</A> [<A HREF="mailto:voiceops-bounces@voiceops.org">mailto:voiceops-bounces@voiceops.org</A>] On Behalf Of Tim Donahue
Sent: Friday, October 15, 2010 10:49 AM
To: <A HREF="mailto:voiceops@voiceops.org">voiceops@voiceops.org</A>
Subject: [VoiceOps] Strange Call Flow
I'm seeing a strange call flow from a client with a Cisco CUBE setup.
This is happening when they attempt to forward a call from their system
to a PSTN line.
SBC CUBE
| ----------INVITE---------> |
| <------100 Trying--------- |
| <------180 Trying--------- |
| <--183 Session Progress--- |
| <--------200 OK----------- |
I've never seen a call setup that switched from a 180 Ringing to a 183
Session Progress mid-setup before, and it seems to be doing funny things
to the media transport through our SBC (we see audio come in from one of
the call legs but it doesn't get forwarded to the other call leg). Is
this a legal call flow that we should add to our tests when evaluating
new hardware?
Has anyone seen problems like this before?
Tim
_______________________________________________
VoiceOps mailing list
<A HREF="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</A>
<A HREF="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</A>
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
_______________________________________________
VoiceOps mailing list
<A HREF="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</A>
<A HREF="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>