[VoiceOps] Strange Call Flow

anorexicpoodle anorexicpoodle at gmail.com
Fri Oct 15 15:47:07 EDT 2010


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20101015/fbd3a703/attachment.html>


More information about the VoiceOps mailing list