Overview:
The IMG supports the media flow direction attributes sendrecv, recvonly, sendonly, and inactive. These attributes, which are interpreted from the senders perspective, set the direction of the media stream to be established in the SIP protocol. The flow attributes present in the SDP portion of the SIP messaging will be used to support the call hold/resume scenario which is explained in RFC 3264 section 6.1 and still be backwards compatible with the call hold feature of RFC 2543 section B5. Up until software version 10.5.2 the IMG supported the Call Hold scenario using the "c=0.0.0.0" line in the SDP message to put a call on hold. With the addition of the Media Flow direction Attributes a call can now be put on hold and then the call can be resumed by sending a Re-INVITE message with both the c=0.0.0.0 and one of the Flow attributes displayed above.
Call Flow Attributes:
The following attributes are supported on the IMG. These attributes are coded in the IMG and do not need to be configured. The attributes were added to support the call hold/resume feature and are supported in the Re-INVITE message only. Below is some background information on the Media Call Flow attributes added.
sendrecv - Used to establish a 2-way media stream.
recvonly - The SIP endpoint would only receive (listen mode) and not send media.
sendonly - The SIP endpoint would only send and not receive media.
inactive - The SIP endpoint would neither send nor receive media.
Table below shows the response the IMG will use when it receives a Media Flow Attribute on the incoming side.
Attribute in incoming Re-INVITE | Attribute in 200 OK response | IMG Connection Mode |
a=sendrecv | a=sendrecv | 2-Way Connection |
a=sendonly | a=recvonly | Listen Mode (recv) |
a=recvonly | a=sendonly | Transmit Mode (send) |
c=0.0.0.0 | c=0.0.0.0 | Hold |
a=inactive | a=inactive | Hold |
c=0.0.0.0 and a=inactive | c=0.0.0.0 and a=inactive | Hold |
Call Flow Information:
Call Flow: Call Hold/Resume
The Call flow diagram above explains the Call Hold/Resume feature implemented with the Call Flow Direction Attributes.
A 2-way call is established from GW-A to GW-B through the IMG using normal call messaging procedures.
GW-A wants to put the call on hold. GW-A sends a Re-INVITE message to the IMG with the a=sendonly line in the SDP. This tells the IMG that GW-A is in a send-only mode and will not receive RTP/RTCP data.
The IMG then sends a 200 OK response with the a=recvonly line indicating that it will only receive RTP/RTCP data and not transmit RTP/RTCP data packets to GW-A. At this point, GW-A can only transmit to IMG.
The IMG then sends a Re-INVITE message to GW-B with the c=0.0.0.0 and a=inactive in the SDP. By sending these two messages, the IMG effectively puts the call on hold.
GW-B responds with a 200 OK telling the IMG it is now on hold. There is no voice path between IMG and GW-B.
GW-A then wants to take the call off hold and resume the call. It sends a Re-INVITE to the IMG with the line a=sendrecv telling the IMG it is now in a send/receive mode and the call can resume.
The IMG responds with 200 OK message with the a=sendrecv line in its SDP.
The IMG then sends a Re-INVITE to GW-B with the same a=sendrecv message in its SDP. GW-A responds with 200 OK and a=sendrecv in the SDP.
At this point the call resumes and RTP/RTCP data begin flowing again.
Additional Information:
Support of the Media Call Flow Attributes is limited to the Re-INVITE method only. If a gateway sends a different method such as the UPDATE method with Media Call Flow attributes set for call hold or resume,IMG will honor the UPDATE method but not put call on hold or off hold/resume.
Absence of a Call Flow Attribute in the Re-INVITE shall default to sendrecv.
Call Flow attributes within an INVITE message will be ignored.
IMG by default will use c=0.0.0.0 and a=inactive in the Re-INVITE to propagate the call hold to outgoing SIP leg.
RTP as well as RTCP will be stopped when media is put "On Hold".
IMG honors 'recvonly' attribute in re-invite SDP, and responds with 'sendonly' in the 200 OK SDP.
Sample SDP messages shown below:
SDP with Flow Direction at session level:
v=0
o=Dialogic_SDP 0 1 IN IP4 10.10.1.253
s=Dialogic-SIP
c=IN IP4 10.10.1.100
t=0.0
a=sendonly
m=audio 8004 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off
SDP with flow direction attribute at media level:
v=0
o=Dialogic_SDP 0 1 IN IP4 10.10.1.253
s=Dialogic-SIP
c=IN IP4 10.10.1.100
t=0.0
m=audio 8004 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off
a=sendonly