[VoiceOps] Strange Call Flow

Fri Oct 15 16:38:26 EDT 2010

You're quite right, it is perfectly legal to put SDP in 180.  It is also correct to state that any 1xx response can follow any other 1xx response.  

My spin on the difference between 180 and 183 came from the draft that brought us the current usage of 183 (http://tools.ietf.org/html/draft-ietf-sip-183-00).  It provides some rather loose guidance: 

   The introduction of the 183 informational response message would
   allow a called user agent to indicate to the calling user agent
   whether or not the calling user agent should apply local alerting for
   the session.  The existing 180 Ringing message would indicate that
   the calling user agent has the option of providing local alerting
   (and generally should).  The 183 Session Progress message would indi-
   cate that the calling user agent should not provide local alerting.

I pretty much see 180s used to carry (1) nothing at all or (2) an alert-info type parameter to tell the phone to play a particular locally stored sound, while I only see 183s used to carry SDP.  I can't recall seeing any exceptions, but we have a pretty tight selection of stacks around here.  

As you said, YMMV :)

If only we had some "standards" worthy of the name...

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: anorexicpoodle [mailto:anorexicpoodle at gmail.com] 
Sent: Friday, October 15, 2010 12:47 PM
To: Hiers, David
Cc: Tim Donahue; voiceops at voiceops.org
Subject: Re: [VoiceOps] Strange Call Flow

The differences you have outlined for 180 and 183 aren't necessarily accurate.

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.

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). 

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).

Yes there is a lot of ambiguity here. YMMV etc etc. 

On Fri, 2010-10-15 at 14:17 -0500, Hiers, David wrote: 

	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: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Tim Donahue
	Sent: Friday, October 15, 2010 10:49 AM
	To: voiceops at voiceops.org
	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
	VoiceOps at voiceops.org
	https://puck.nether.net/mailman/listinfo/voiceops

	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
	VoiceOps at voiceops.org
	https://puck.nether.net/mailman/listinfo/voiceops

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.