Interworking between SIP and SGCP

When we started our effort, we tried to simply reuse SIP. However, we needed a master slave protocol, that could for example instruct the gateway to use exactly this encoding and that packetisation format. We also needed circuit control functions for continuity test. And we preferred to concentrate all intelligence in the call agent. SIP was not designed to that purpose. Basically, SIP is a peer-to-peer protocol, while SGCP is a master slave protocol. However, the use of SDP in both SGCP and SIP makes interworking between these protocols very easy.

(picture showing the roles of SGCP, ISUP and SIP)

In order to demonstrate this interworking, we provide here a step by step demonstration of 2 call set-up scenarios:

Call from an SGCP controlled residential gateway to a SIP agent,
Call from a SIP agent to an SGCP controlled residential gateway.

Call from a residential gateway (RGW) to a SIP user

RTT	Usr	RGW	CA	SIP	Usr
		<-	Notification Request
		Ack	->

0.5	Off-hook	Notify	->
1.0		<-	Ack
1.0	(Dial-tone)	<-	Notification Request
1.5		Ack	->

0.5	Digit	Notify	->
1.0		<-	Ack
1.0	(progress)	<-	Create Connection + Notification Request
1.5		Ack	->
			(call processing)
2.0			INVITE	->	ring
2.5			<-	response 180 (ringing)
3.0	(ringing)	<-	Notification Request
3.5		Ack	->

0.5			<-	response 200 (OK)	off hook
1.0			Ack	->
1.0		<-	Modify Connection + Notification Request
1.5		Ack	->
			(call established)
0.5	on hook	Notify	->
1.0		<-	Ack
1.0		<-	Delete Connection + Notification Request
1.5		perf data	->
1.0			BYE	->
1.5			<-	response 200 (OK)

				(local action)	On-hook

During these exchanges the SGCP is used by the call agent to control the residential gateways. The call will be routed to a SIP agent. The first command is a notification request, sent by the call agent to the residential gateway. The request will consist of the following lines:

   RQNT 1201 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   N: ca@ca1.whatever.net:5678
   X: 0123456789AB
   R: hd

The gateway, at that point, is instructed to look for an off-hook event, and to report it. It will first acknowledge the request, repeating in the acknowledgement message the transaction id that the call agent attached to the query.

   200 1201 OK

Note that this command is not actually simultaneous with the call. It can be issued long before the actual call, for example when the gateway is turned on, or after the end of a previous call.

When the off hook event is noticed, the gateway initiates a notification request to the call agent:

   NTFY 2001 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   N: ca@ca1.whatever.net:5678
   X: 0123456789AB
   O: hd

The call agent immediately acknowledges that notification.

   200 2001 OK

The call agent examines the services associated to an off hook action (it could take special actions in the case of a direct line). In most cases, it will send a notification request, asking for more digits. It will also, The current example provides the gateway with a digit map, and request the gateway to play a dialtone:

   RQNT 1202 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   N: ca@ca1.whatever.net:5678

   X: 0123456789AC
   R: hu, [0-9#*T](D)
   D: (0T | 00T | [1-7]xxx | 8xxxxxxx | #xxxxxxx | *xx | 91xxxxxxxxxx | 9011x.T)
   S: dt

The gateway immediately acknowledges that request.

   200 1202 OK

The gateway will start accumulating digits according to that digit map. When it has noticed a sufficient set of values, it will notify the observed string to the call agent:

   NTFY 2002 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   N: ca@ca1.whatever.net:5678
   X: 0123456789AC
   O: 912018294266

The call agent immediately acknowledges that notification.

   200 2002 OK

At this stage, the call agent seizes the incoming circuit, creating a connection. It will also send together with that creation request a notification request, to stop collecting digits yet continue watch for an on-hook transition:

   CRCX 1204 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   C: A3C47F21456789F0
   L: p:10, a:G.711;G.726-32
   M: recvonly
   X: 0123456789AD
   R: hu

The gateway immediately acknowledges the creation, sending back the identification of the newly created connection and the session description used to receive audio data:

   200 1204 OK
   I:FDE234C8

   v=0
   c=IN IP4 128.96.41.1
   m=audio 3456 RTP/AVP 0 96
   a=rtpmap:96 G726-32/8000

The SDP announcement, in our example, specifies the address at which the gateway is ready to receive audio data (128.96.41.1), the transport protocol (RTP), the RTP port (3456) and the audio profile (AVP). The audio profile refers to RFC 1890, which defines that the payload type 0 has been assigned for G.711 transmission. The gateway is also ready to use ADPCM encoding at 32 kbps (G.726 –4). There is no standard payload type associated to ADPCM, so the gateway mentions its readiness to use a non standard payload associated to the dynamic type 96. The "rtpmap" attribute entry associates the payload type 96 to G726-32/4.

The call agent, having seized the incoming trunk, proceeds with call routing. Using local databases, it determines that the dialed digits (912018294266) correspond to a SIP agent. It will send an invitation to that agent:

   INVITE huitema@sip-station.bellcore.com SIP/2.0
   Via: SIP/2.0/UDP 128.96.41.12
   From: 123456789@ca.whatever.net 
   To: huitema@sip-station.bellcore.com (Christian Huitema)
   Call-ID: 187602141351@ca.whatever.net
   Content-type: application/sdp
   Content-Length: ...

   v=0
   c=IN IP4 128.96.41.1
   m=audio 3456 RTP/AVP 0 96
   a=rtpmap:96 G726-32/8000

The SDP attachment, in the INVITE message, is directly copied from the acknowledgement of the Create Connection request.

The SIP agent alerts the user, and sends an immediate acknowledgement:

   SIP/2.0 180 OK 
   From: huitema@sip-station.bellcore.com (Christian Huitema)
   To: 123456789@ca.whatever.net 
   Call-ID: 187602141351@ca.whatever.net

The call agent will send a notification request that instruct the RGW to generate ringing tones:

   RQNT 1206 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   X: 0123456789AE
   R: hu
   S: rt

When the called user accepts the call, the SIP agent sends an acceptation message to the call agent:

   SIP/2.0 200 OK 
   From: huitema@sip-station.bellcore.com (Christian Huitema)
   To: 123456789@ca.whatever.net 
   Call-ID: 187602141351@ca.whatever.net

   v=0
   c=IN IP4 128.96.63.25
   m=audio 1297 RTP/AVP 0 96
   a=rtpmap:96 G726-32/8000

The gateway immediately acknowledges the call set up:

   ACK huitema@sip-station.bellcore.com SIP/2.0
   Via: SIP/2.0/UDP 128.96.41.12
   From: 123456789@ca.whatever.net 
   To: huitema@sip-station.bellcore.com (Christian Huitema)
   Call-ID: 187602141351@ca.whatever.net

Then, the call agent will send a modification request to the residential gateway, in order to establish a full duplex connection. The SDP payload, in that request, is copied from the SIP agent's response:

   MDCX 1209 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   C: A3C47F21456789F0
   I:FDE234C8
   M: sendrecv
   X: 0123456789AF
   R: hu

   v=0
   c=IN IP4 128.96.63.25
   m=audio 1297 RTP/AVP 0 96
   a=rtpmap:96 G726-32/8000

The gateway will acknowledge this request:

   200 1209 OK

At this point, the connection is established.

In our example, the call is terminated when the calling party hangs up. This triggers a notification message to the call agent:

   NTFY 2005 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   X: 0123456789AF
   O: hu

After this notification, the call agent should send an acknowledgement:

   200 2005 OK

The call agent will then clear the call, by sending a delete connection request to the calling gateway. This request is combined with a notification request, to be ready to detect the next call issued by the residential gateway:

   DLCX 1210 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   C: A3C47F21456789F0

   I:FDE234C8
   X: 0123456789B0
   R: hd

The gateway will respond with a message that should include a "call parameters" header field:

   250 1210 OK
   P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48

The call agent will in parallel sends a BYE request to the SIP agent:

   BYE huitema@sip-station.bellcore.com SIP/2.0
   Via: SIP/2.0/UDP 128.96.41.12
   From: 123456789@ca.whatever.net 
   To: huitema@sip-station.bellcore.com (Christian Huitema)
   Call-ID: 187602141351@ca.whatever.net

The SIP agent will acknowledge that request:

   SIP/2.0 200 OK 
   From: huitema@sip-station.bellcore.com (Christian Huitema)
   To: 123456789@ca.whatever.net 
   Call-ID: 187602141351@ca.whatever.net

The gateways, at this point, is ready for the next call. The SIP user will be ready as soon as the SIP agent notices that the phone is back on hook.

Back to the top of the page
Back to the SGCP FAQ
Back to the SGCP page

Basic call, SIP to RGW

RTT	User	SIP agent	CA	RGW	Usr
	call	->
0.5		INVITE	->
			(call processing)
1.0			Create Connection + Notification Request	->	ring
1.5			<-	Ack
2.0		<-	response code 180 (ringing)
		(ringing indication)
0.5			<-	Notify	off hook
1.0			Ack	->
1.0			Notification Request	->
1.5			<-	Ack
1.0		<-	response code 200 (OK)
1.5		ACK	->
			(call established)

0.5			<-	Notify	on hook
1.0			Ack	->
			(no suspension message)
1.0			Notification Request	->
1.5			<-	Ack

	hangup	hangup detected
0.5		BYE	->
1.0		<-	FIN ACK
1.0			Delete Connection + Notification Request	->
1.5			<-	perf data

This diagram shows the various exchange of messages during a call from a SIP user to a residential user. During these exchanges the SGCP is used by the call agent to control the residential gateway.

When the user initiates the call, the SIP agent will send an invitation to the call agent. (Our diagram assumes that the SIP agent sends that invitation directly; in fact, there could be several relays.) An example of invitation could be:

   INVITE watson@boston.bell-telephone.com SIP/2.0
   Via: SIP/2.0/UDP 169.130.12.5
   From: a.g.bell@bell-telephone.com (A. Bell)
   To: watson@bell-telephone.com (T. A. Watson)
   Call-ID: 187602141351@worcester.bell-telephone.com
   Subject: Mr. Watson, come here.
   Content-type: application/sdp
   Content-Length: ...

   v=0
   o=bell 53655765 2353687637 IN IP4 128.3.4.5
   c=IN IP4 135.180.144.94
   m=audio 3456 RTP/AVP 0 3 4 5

Upon reception of the set-up message, the call agent will perform call routing functions and determine the end point that correspond to the invited user. It will then reserve the outgoing circuit. It does so at the same time that is requests ringing, by sending to the residential gateway a connection request combined with a notification request:

   CRCX 1238 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   C: A3C47F21456789F0
   L: p:10, a:G.711
   M: sendrecv
   X: 0123456789B1
   R: hd
   S: rg

   v=0
   o=bell 53655765 2353687637 IN IP4 128.3.4.5
   c=IN IP4 135.180.144.94
   m=audio 3456 RTP/AVP 0 3 4 5

In this command, the SDP announcement is directly copied from the invitation. The gateway will acknowledge the connection request, sending in the session description its own parameters such as address, ports and RTP profile:

   200 1238 OK
   I:32F345E2

   v=0
   c=IN IP4 128.96.63.25
   m=audio 1297 RTP/AVP 0 3

The phone is ringing, and the gateway, is instructed to look for an off-hook event, and to report it. The call agent sends an alerting message to the calling SIP agent, which will generate ringing tones for the calling user:

   SIP/2.0 180 OK
   From: a.g.bell@bell-telephone.com (A. Bell)
   To: watson@bell-telephone.com
   Call-ID: 187602141351@worcester.bell-telephone.com

When the off hook event is noticed, the gateway initiates a notification request to the call agent:

   NTFY 2001 endpoint-1@rgw-2567.whatever.net SGCP 1.0X: 0123456789B0
   O: hd

The call agent immediately acknowledges that notification.

   200 2001 OK

The call agent must now ask the residential gateway to notify the occurrence of an on-hook event. It does so by sending a notification request to the residential gateway:

   RQNT 1241 endpoint-1@rgw-2567.whatever.net SGCP 1.0X: 0123456789B1
   R: hu

The gateway acknowledges that request:

   200 1241 OK

In parallel, the call agent will send a final answer to the SIP agent. The message, in its payload, copies the SDP announcement that was sent by the gateway:

   SIP/2.0 200 OK
   From: a.g.bell@bell-telephone.com (A. Bell)
   To: watson@bell-telephone.com
   Call-ID: 187602141351@worcester.bell-telephone.com
   Location: sip://watson@boston.bell-telephone.com
   Content-Length: ...

   v=0
   c=IN IP4 128.96.63.25
   m=audio 1297 RTP/AVP 0 3

The SIP agent acknowledges the set-up:

   ACK watson@boston.bell-telephone.com SIP/2.0
   Via: SIP/2.0/UDP 169.130.12.5
   From: a.g.bell@bell-telephone.com (A. Bell)
   To: watson@bell-telephone.com (T. A. Watson)
   Call-ID: 187602141351@worcester.bell-telephone.com

At this point, the call is established.

After some time, in our example, the residential user hangs up. The notify request is sent to the call agent:

   NTFY 2005 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   X: 0123456789B1
   O: hu

The call agent acknowledges the notification.

   200 2005 OK

Upon reception of that notification, the call agent should send a "suspend" message to the calling SIP agent, but there is no such message in SIP. In order to preserve the user experience, the call agent will simply initiate a timer, after which it would actually release the call. (In North-America, the call is not actually terminated if the called party hangs up. If it hangs down in a short interval, the call will be resumed.) The call agent, in any case, sends a notification request to the gateway, to look for an off-hook event.

   RQNT 1243 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   X: 0123456789B2
   R: hd

The gateway will acknowledge this request:

   200 1243 OK

In our example, the calling user releases the call immediately. The SIP agent sends a BYE message to the call agent:

   BYE watson@boston.bell-telephone.com SIP/2.0
   Via: SIP/2.0/UDP 169.130.12.5
   From: a.g.bell@bell-telephone.com (A. Bell)
   To: watson@bell-telephone.com (T. A. Watson)
   Call-ID: 187602141351@worcester.bell-telephone.com

The call agent acknowledges that message:

   SIP/2.0 200 OK
   From: a.g.bell@bell-telephone.com (A. Bell)
   To: watson@bell-telephone.com
   Call-ID: 187602141351@worcester.bell-telephone.com

The call agent then sends a delete connection request to the residential gateway. The request sent to the gateway is combined with a request to detect a off-hook event, which will be used to detect rare conditions where the user would have gone off hook simultaneously with the release on the other side:

   DLCX 1244 endpoint-1@rgw-2567.whatever.net SGCP 1.0
   C: A3C47F21456789F0
   X: 0123456789B3
   R: hd
   I:FDE234C8

The gateway will respond with a message that should include a "call parameters" header fields:

   200 1244 OK
   P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48

The gateway, at this point, is ready for the next call.

Back to the top of the page
Back to the SGCP FAQ
Back to the SGCP page