Use Cases for SIP and SDP Offer/Answer

Use Cases for SIP and SDP Offer/Answer

This page contains a list of use cases or call scenarios for SIP and SDP Offer/Answer.

There are a few call scenarios that we expect to see when dealing with more telephone-like side of SIP:

  • calling to existing PSTN networks (early session)
  • doing resource reservations
  • calling to 3G IMS
  • call hunting
  • having external party setting up your call, etc.

Case #1: Basic Call

This is the basic SIP call model with the most simple offer-answer exchange.

	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|			|
	|< - - 180 Ringing - - -|
	|			|
	|			|
	|<----200 (answer)------|
	|----------ACK--------->|
	|			|
	|			|

Case #2: Early Media

Another case, slightly more complex. The SDP answer is sent with 180 Ringing in order to establish an "early session". B might not be a SIP phone, but a gateway to PSTN, for instance. Using this "early session" B can play tones like "burr-burr" or "thesubscriber you tried to reach is not in the coverage...":

	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|			|
	|<----180 (answer)------|
	|			|
	|			|
	|<----200 (answer')-----|
	|----------ACK--------->|
	|			|
	|			|

After receiving answer in 180 Ringing, A simply ignores SDP in subsequent responses.

Nothing special here, right? But SIP is not so simple, unfortunately. There are hairy cases because of "early sessions", "forking", "preconditions" and other reasons.

Now lets go through some hairy cases.

Case #3: Early Dialog, Early Media

This case is a call using 100rel, early dialog and early media. It is used when the session should be established before call alerts.

	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|<----183 (answer)------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|

Case #4: UPDATE with Offer

This is a call model with two rounds of offer/answer and 100rel. It can be used, for instance, when the endpoints have to make sure that there are enough network capacity for the call to succeed. They can establish a new radio bearer, for instance, before progressing with the call. The initial offer would contain SDP attribute "inactive", the second "sendrev":

	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|			|
	|<----183 (answer)------|
	|--------PRACK--------->|
	|<-----200/PRACK--------|
	|			|
	|			|
	|----UPDATE (offer2)--->|
	|<-200/UPDATE (answer2)-|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|

Case #5: 2nd Offer in PRACK

Alternative 1 to above, two rounds of offer/answer and 100rel, no UPDATE. It can used, for instance, when caller wants to make sure there is only one audio or video codec that is used during the call. The initial offer would contain SDP attribute "inactive"; the second "sendrev":

	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|<----183 (answer)------|
	|-----PRACK(offer2)---->|
	|<--200/PRACK(answer2)--|
	|			|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|

Case #6: Callee Making 2nd Offer

Alternative 2 to above: two rounds of offer/answer and 100rel, but now it is B who wants to do two rounds and initiates second Offer-Answer exchange:

	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|<----183 (answer)------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---UPDATE (offer2)----|
	|-200/UPDATE (answer2)->|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|

Case #7: 3GPP Call Model

Here is a third alternative, know as "3GPP call model", where there is not 2 but 3 offer-answer rounds, allowing A and B to do precise resource reservations after they have agreed on media, codecs and transport addresses used during the call:

        	A		        B
        	|			|
        	|----INVITE (offer)---->|
        	|			|
        	|			|
        	|<----183 (answer)------|
        	|-----PRACK(offer2)---->|
        	|<--200/PRACK(answer2)--|
        	|			|
        << resource reservations are done now >>
        	|			|
        	|----UPDATE (offer3)--->|
        	|<-200/UPDATE (answer3)-|
        	|			|
        	|<---------180----------|
        	|--------PRACK--------->|
        	|<-----200/PRACK------->|
        	|			|
        	|			|
        	|<---------200----------|
        	|----------ACK--------->|
        	|			|
        	|			|

Case #8: Forking

Now, another complication. Here B has two terminals, let say, fixed (B1) and mobile (B2) phone, both alert when B receives a call using procedure known as forking:

	A		   B's proxy		B1		B2
	|			|		|		|
	|----INVITE (offer)---->|		|		|
	|			|-INVITE (off)->|		|
	|			|-----------INVITE (off)------->|
	|			|		|		|
	|			|<--180 (ans1)--|		|
	|<------180 (ans1)------|		|		|
	|			|		|		|
	|			|<----------180 (ans2)----------|
	|<------180 (ans2)------|		|		|
	|			|		|		|
	|			|		|		|
	|			|<----------200 (ans2')---------|
	|<------200 (ans2')-----|		|		|
	|			|----CANCEL---->|		|
	|			|<--200/CANCEL--|		|
	|			|<-----487------|		|
	|			|		|		|
	|----------ACK----------------------------------------->|
	|			|		|		|
	|			|		|		|

Here we have two calls initially established, but the call to B1 along with "early session" is should be dropped when B2 picks up the call (and 200 OK is returned).

Case #9: 3rd Party Call Control

Now something different: 3rd party call model, where "C" establishes the call:

	A		        C		        B
	|			|			|
	|<-------INVITE---------|			|
	|			|			|
	|			|			|
	|------200 (offer)----->|  	  		|
	|			|----INVITE (offer)---->|
	|			|			|
	|			|			|
	|			|<-----200 (answer)-----|
	|<-----ACK (answer)-----|			|
	|			|     			|
	|			|----------ACK--------->|
	|			|			|

Case #10: Upgrade Session with Re-INVITE

The session is upgraded: a new media is added to the session.

	A		        B
	|			|
	|----INVITE (offer1)--->|
	|			|
	|			|
	|< - - 180 Ringing - - -|
	|			|
	|			|
	|<----200 (answer2)-----|
	|----------ACK--------->|
	|			|
	|			|
	|			|
	|			|
	|----INVITE (offer2)--->|
	|			|
	|<----200 (answer2)-----|
	|----------ACK--------->|
	|			|
	|			|

Case #10: Upgrade Session with Re-INVITE

The session upgraded is rejected.

	A		        B
	|			|
	|----INVITE (offer1)--->|
	|			|
	|			|
	|< - - 180 Ringing - - -|
	|			|
	|			|
	|<----200 (answer2)-----|
	|----------ACK--------->|
	|			|
	|			|
	|			|
	|			|
	|----INVITE (offer2)--->|
	|			|
	|<---------488----------|
	|----------ACK--------->|
	|			|
	|			|
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值